chết runtime ghi tag, log code Z350 kẹt khi tạo và ghi liên tục nên chết runtime giữa chừng

\\\\\\\\\\\\\\ Chat GPT phán đoán log để xử lý. nhờ AI phân tích và đưa . phải phân tích log thì mởi xử lý hoàn toàn chính xác được nguyên nhân chuẩn được

Do đó hoàn toàn xác định được chính xác hoàn toàn nguyên nhân chuẩn được . 

	Hosting ghi nhận bắt đầu shutdown
11:45:03	Ứng dụng khởi động lại

Các luồng bị ảnh hưởng gồm:

• PollDevice: đọc dữ liệu PLC.

• Schedule: lập lịch polling.

• EvalAlarm: đánh giá cảnh báo.

• AlarmSnapshot: lấy dữ liệu Alarm.

• RefreshTrendPens: cập nhật cấu hình Trend.

Điều này có thể khiến runtime ngừng cập nhật dữ liệu và mất kết nối.

scadaweb_20261102.log

2. Hai lỗi khác trong log

Lỗi JavaScript TagMapBox

Cannot read property '_tm' of null
scada.js?v=16:975
TagMapBox.razor:line 38

Đây là lỗi JS Interop khi cập nhật bản đồ với đối tượng đã null. Nó làm hỏng Blazor circuit tương ứng, nhưng chưa đủ bằng chứng để kết luận đây là nguyên nhân dừng toàn bộ tiến trình.

scadaweb_20261102.log

Lỗi Antiforgery

The antiforgery token could not be decrypted.
The key was not found in the key ring.

Có thể do cookie cũ không còn khớp với Data Protection key hiện tại. Đây không phải nguyên nhân trực tiếp gây kẹt runtime.

scadaweb_20261102.log

3. Kết luận quan trọng

Tôi nghi ngờ nhất là thao tác quản lý tag đang giữ engine.sync trong lúc thực hiện công việc quá nặng hoặc chờ một thao tác khác. Tuy nhiên, log hiện tại ghi RenameTag, không ghi AddTag, nên chưa thể khẳng định chính xác hàm thêm tag là thủ phạm.

Một điểm nữa: Application is shutting down... là thông báo shutdown có kiểm soát, không phải bằng chứng trực tiếp về crash. Cần kiểm tra thêm Windows Event Viewer hoặc log của dịch vụ chạy SCADA để xác định ai yêu cầu dừng.

4. Hướng sửa tôi đề xuất

Tôi muốn xử lý tận gốc thay vì tiếp tục tối ưu giao diện:

1. Rút ngắn thời gian giữ engine.sync.

2. Không thực hiện lưu JSON, quét toàn bộ tag hoặc thao tác I/O lâu bên trong lock.

3. Tách thao tác thêm, sửa, đổi tên tag khỏi luồng polling.

4. Bổ sung timeout và log thời gian giữ khóa, ghi rõ thao tác nào đang giữ khóa.

5. Bảo đảm thêm tag không làm dừng PollDevice, realtime, Trend và Alarm.

Tôi cần bạn gửi thêm một file: ZIP mã nguồn đang chạy đúng lúc xuất hiện lỗi (bản V18 hoặc bản bạn đang sử dụng).

Tôi sẽ kiểm tra trực tiếp AddTag, RenameTag, SaveNow và các vị trí lock(sync), sau đó sửa thành một bản hoàn chỉnh. Không sửa Trend và Alarm, không tiếp tục chia thành nhiều bản tối ưu nhỏ.

\\\\\\\\\\

 Các khối lock(sync) khác cũng gọi vào driver (Dispose, DriverRegistry.Create) ngay khi đang giữ sync, cùng kiểu rủi ro. Mình xem 4 chỗ này.

Log đã chỉ ra chỗ kẹt, và mình đã sửa trong z350_fix_renametag_deadlock.zip. Mình vẫn chưa build được vì máy mình không có dotnet.

Log nói gì

11:44:03.521  RenameTag:437 (thread 39) lấy khoá engine.sync
11:44:39 → 11:44:59  KẸT 36s … 54s: PollDevice, EvalAlarm, Idx, Schedule,
                     RefreshTrendPens, AlarmSnapshot … đều chờ; chủ khoá = RenameTag
11:45:02  bạn tắt/chạy lại ScadaWeb

Hàm RenameTag giữ khoá engine.sync hơn 56 giây mà không nhả. 14 luồng khác (đọc PLC, alarm, vẽ trend, giao diện) đều chờ khoá này, nên cả SCADA đứng. Trong log này không có dòng [ADDTAG] nào, nên lần treo mà log ghi lại xảy ra lúc đổi tên tag, không phải lúc bấm “+ Thêm Tag”. Nhiều khả năng đó là cùng một lỗi với lần bạn gặp trước đó, vì triệu chứng giống nhau.

Nguyên nhân

RenameTag đang giữ sync mà lại lấy thêm các khoá khác bên trong: lock (dv) của thiết bị, khoá chương trình Ladder, và thư viện widget. Trong khi đó luồng Ladder hoặc driver giữ chính khoá đó rồi gọi vào engine (như Idx, FindTag) và phải chờ sync. Hai bên giữ khoá của nhau và chờ nhau mãi (deadlock). Log không cho biết chính xác khoá nào, vì lock (dv) và khoá Ladder chưa được theo dõi. Vì vậy đây là suy luận chắc nhưng chưa phải xác nhận 100%.

Đã sửa

• RenameTag: chỉ phần dữ liệu của engine (đổi tên, xu hướng, alarm đang báo) nằm trong lock(sync). Phần cập nhật widget, ThingsBoard, mail, AdvanLink, Ladder, script chạy ngoài khoá. Có try/catch ghi log [RENAME] nếu lỗi.
• RemoveDevice: gọi Dispose driver ngoài lock(sync), cùng kiểu rủi ro.
• Giữ nguyên các sửa trước (chỉ mục tăng dần, thứ tự khoá Idx/Save, bộ theo dõi khoá).

Khoá khác còn nằm trong sync

Còn hai chỗ gọi code driver khi đang giữ sync: tạo driver trong PollDevice và DeviceEdit/UpsertDevice (gọi DriverRegistry). Mình chưa đổi vì thường chỉ khởi tạo. Nếu log lần sau vẫn có chủ khoá = ... ở các hàm này, mình sẽ sửa tiếp.

Bạn làm giúp

1. Chép đè 10 file trong zip lên project, build, chạy (x64 như đã nói).
2. Thử đổi tên một tag, và thử thêm tag bằng tay, khi runtime đang chạy với hơn 2000 tag.
3. Nếu còn kẹt, gửi mình các dòng [LOCK], [RENAME], [ADDTAG].

4. Tôi đã tìm thấy nguyên nhân đáng chú ý trong log ngày 02/11/2026: khi thao tác đổi tên tag, SCADA bị giữ khóa engine.sync rất lâu. Đây có thể là nguyên nhân làm runtime đứng rồi mất kết nối.

   Cụ thể, log ghi nhận RenameTag giữ khóa từ 11:44:03.521, sau đó nhiều luồng PollDevice, Schedule, EvalAlarm, AlarmSnapshot và RefreshTrendPens phải chờ khóa. Có luồng đã chờ tới 54 giây. Đây là dấu hiệu nghiêm trọng hơn một lỗi giao diện thông thường.

   1. Nguyên nhân chính: khóa engine.sync bị giữ quá lâu

   Nghiêm trọng

   Thời điểm	Sự kiện
   11:44:03.521	RenameTag giữ khóa engine.sync
   11:44:06	Các luồng bắt đầu bị kẹt
   11:44:30	Nhiều luồng đã chờ 30 giây
   11:44:57	Có luồng chờ tới 54 giây
   11:44:34	Hosting ghi nhận bắt đầu shutdown
   11:45:03	Ứng dụng khởi động lại

   Các luồng bị ảnh hưởng gồm:

   • PollDevice: đọc dữ liệu PLC.

   • Schedule: lập lịch polling.

   • EvalAlarm: đánh giá cảnh báo.

   • AlarmSnapshot: lấy dữ liệu Alarm.

   • RefreshTrendPens: cập nhật cấu hình Trend.

   Điều này có thể khiến runtime ngừng cập nhật dữ liệu và mất kết nối.

   scadaweb_20261102.log

   2. Hai lỗi khác trong log

   Lỗi JavaScript TagMapBox

   Cannot read property '_tm' of null
   scada.js?v=16:975
   TagMapBox.razor:line 38

   Đây là lỗi JS Interop khi cập nhật bản đồ với đối tượng đã null. Nó làm hỏng Blazor circuit tương ứng, nhưng chưa đủ bằng chứng để kết luận đây là nguyên nhân dừng toàn bộ tiến trình.

   scadaweb_20261102.log

   Lỗi Antiforgery

   The antiforgery token could not be decrypted.
   The key was not found in the key ring.

   Có thể do cookie cũ không còn khớp với Data Protection key hiện tại. Đây không phải nguyên nhân trực tiếp gây kẹt runtime.

   scadaweb_20261102.log

   3. Kết luận quan trọng

   Tôi nghi ngờ nhất là thao tác quản lý tag đang giữ engine.sync trong lúc thực hiện công việc quá nặng hoặc chờ một thao tác khác. Tuy nhiên, log hiện tại ghi RenameTag, không ghi AddTag, nên chưa thể khẳng định chính xác hàm thêm tag là thủ phạm.

   Một điểm nữa: Application is shutting down... là thông báo shutdown có kiểm soát, không phải bằng chứng trực tiếp về crash. Cần kiểm tra thêm Windows Event Viewer hoặc log của dịch vụ chạy SCADA để xác định ai yêu cầu dừng.

   4. Hướng sửa tôi đề xuất

   Tôi muốn xử lý tận gốc thay vì tiếp tục tối ưu giao diện:

   1. Rút ngắn thời gian giữ engine.sync.

   2. Không thực hiện lưu JSON, quét toàn bộ tag hoặc thao tác I/O lâu bên trong lock.

   3. Tách thao tác thêm, sửa, đổi tên tag khỏi luồng polling.

   4. Bổ sung timeout và log thời gian giữ khóa, ghi rõ thao tác nào đang giữ khóa.

   5. Bảo đảm thêm tag không làm dừng PollDevice, realtime, Trend và Alarm.

   Tôi cần bạn gửi thêm một file: ZIP mã nguồn đang chạy đúng lúc xuất hiện lỗi (bản V18 hoặc bản bạn đang sử dụng).

   Tôi sẽ kiểm tra trực tiếp AddTag, RenameTag, SaveNow và các vị trí lock(sync), sau đó sửa thành một bản hoàn chỉnh. Không sửa Trend và Alarm, không tiếp tục chia thành nhiều bản tối ưu nhỏ.

5. ác khối lock(sync) khác cũng gọi vào driver (Dispose, DriverRegistry.Create) ngay khi đang giữ sync, cùng kiểu rủi ro. Mình xem 4 chỗ này.

   Log đã chỉ ra chỗ kẹt, và mình đã sửa trong z350_fix_renametag_deadlock.zip. Mình vẫn chưa build được vì máy mình không có dotnet.

   Log nói gì

   11:44:03.521  RenameTag:437 (thread 39) lấy khoá engine.sync
   11:44:39 → 11:44:59  KẸT 36s … 54s: PollDevice, EvalAlarm, Idx, Schedule,
                        RefreshTrendPens, AlarmSnapshot … đều chờ; chủ khoá = RenameTag
   11:45:02  bạn tắt/chạy lại ScadaWeb

   Hàm RenameTag giữ khoá engine.sync hơn 56 giây mà không nhả. 14 luồng khác (đọc PLC, alarm, vẽ trend, giao diện) đều chờ khoá này, nên cả SCADA đứng. Trong log này không có dòng [ADDTAG] nào, nên lần treo mà log ghi lại xảy ra lúc đổi tên tag, không phải lúc bấm “+ Thêm Tag”. Nhiều khả năng đó là cùng một lỗi với lần bạn gặp trước đó, vì triệu chứng giống nhau.

   Nguyên nhân

   RenameTag đang giữ sync mà lại lấy thêm các khoá khác bên trong: lock (dv) của thiết bị, khoá chương trình Ladder, và thư viện widget. Trong khi đó luồng Ladder hoặc driver giữ chính khoá đó rồi gọi vào engine (như Idx, FindTag) và phải chờ sync. Hai bên giữ khoá của nhau và chờ nhau mãi (deadlock). Log không cho biết chính xác khoá nào, vì lock (dv) và khoá Ladder chưa được theo dõi. Vì vậy đây là suy luận chắc nhưng chưa phải xác nhận 100%.

   Đã sửa

   • RenameTag: chỉ phần dữ liệu của engine (đổi tên, xu hướng, alarm đang báo) nằm trong lock(sync). Phần cập nhật widget, ThingsBoard, mail, AdvanLink, Ladder, script chạy ngoài khoá. Có try/catch ghi log [RENAME] nếu lỗi.
   • RemoveDevice: gọi Dispose driver ngoài lock(sync), cùng kiểu rủi ro.
   • Giữ nguyên các sửa trước (chỉ mục tăng dần, thứ tự khoá Idx/Save, bộ theo dõi khoá).

   Khoá khác còn nằm trong sync

   Còn hai chỗ gọi code driver khi đang giữ sync: tạo driver trong PollDevice và DeviceEdit/UpsertDevice (gọi DriverRegistry). Mình chưa đổi vì thường chỉ khởi tạo. Nếu log lần sau vẫn có chủ khoá = ... ở các hàm này, mình sẽ sửa tiếp.

   Bạn làm giúp

   1. Chép đè 10 file trong zip lên project, build, chạy (x64 như đã nói).
   2. Thử đổi tên một tag, và thử thêm tag bằng tay, khi runtime đang chạy với hơn 2000 tag.
   3. Nếu còn kẹt, gửi mình các dòng [LOCK], [RENAME], [ADDTAG].

   Z350 fix renametag deadlock

Nội dung chính