Hi,Support:

Regarding the QuickOpc runtime exception previously reported, after further evaluation and taking into account the uncertainties and unknown runtime behavior in actual operation, we have reverted to the original version previously in use. We are hereby notifying you of this change.
We remain concerned about the stability of the original version in the disconnect-reconnect scenario. Relevant system logs and screenshots have been retained. Please feel free to contact us if there are any further developments or if further cooperation on troubleshooting is needed.

Simon.Yu
vskysoft.com
2026.11.02

Hello.

You will be contacted by email regarding this issue.

Modification and Execution
1) The data collection program has two different versions under .NET 7 and .NET 8, using QuickOpc versions 5.80.255 and 5.83.1043 respectively.
2) After years of actual operation, some bugs were found inside the driver. Among them, during disconnection & reconnection, excessively high thread count led to memory overflow, causing monitoring alarms on our application side and application exceptions.
3) Fix points: session management, disconnection/reconnection, retry limits, backoff/full-volume recovery management, etc. were modified; full-link encoding output to EasyUAClient.LogEntry (EasyUAClientOnLogEntry-Trace.log).
4) The script analyzes the runtime output log (EasyUAClientOnLogEntry-Trace.log).
5) Current status: a single server is responsible for real-time collection from 270 IPs with a total of 16,000 tags; client01~06, 6 instance endpoints; client05 in particular handles simultaneous subscription & collection for 122 IPs; CPU: 1~7%, RAM: 2~300 MB; the entire collection application uses CPU <10%, RAM around 1 GB.
- client05， 122 IPs,  EasyUAClientOnLogEntry-Trace.log is about 200 MB per day.
- client03， 40~50 IPs,  EasyUAClientOnLogEntry-Trace.log is about 20 MB per day.
6) Full AI analysis, full scan, logic chain establishment, flowchart analysis, code modification and debugging; approximately 10~15 iterations in total.
7）Given our application and customer environments, we are unable to upgrade at any time. As a temporary fix, we hereby report this to the OpcLabs official team and continue to use our authorization certificate. Kindly be advised~

Current status: overall stable operation; the previous daily crash phenomenon of client03 and client05 has been resolved (threadCount>1100).

The above only represents the local operation situation and is for reference only.

vskysoft.com

Simon.Yu
2026-10-28 18:07

1）Regarding OpcLabs drivers, our company's versions ultimately remain at .NET 8.0 (QuickOpc-Code-5.83.1043) and .NET 7.0 (5.80.255).
2）Regarding the crash issue, we have reported it multiple times but it has never been fundamentally resolved. We have now turned to decompiling and modifying the source code to attempt to solve it ourselves. If we achieve a fundamental fix, we will provide feedback.
3）We have now initially released it to production and are monitoring it. Attached is the record of modifications.

Simon.Yu
vsksoft.com 
2026.10.23

Hello.
This is going to be difficult to address without having a reproducible scenario. Do you have it?

I have some questions:

1) Are you running in 32-bit or 64-bit process?
2) Do you know whether memory is actually exhausted in the process?
3) Do you know how many threads are in th eprocess?
4) Does it only happen with large number of client connections? How many connections do you have?
5) Does it only happen after long time? Or, long does it take before the problem appears?
6) I do not understand what you mean by "about 3~5 opc server maybe Communication exception". Please explain.

Note that we will investigate only on the recent build of the current version, i.e. 5.84.374.

Regards
 

about 3~5 opc server maybe Communication exception
There is a crash in the underlying driver layer

OpcLabs.QuickOpc 5.83.1043
windows server2022
c# + .NET8.0 

Simon.Yu
vskysoft.com
2026.9.9