Random crash on ntdll.dll 0xc0000374 using either libplctag.NativeImport or libplctag packages

[U11Leung]

We are using this .NET wrapper to drive a tool which only job is to download values of hundreds of tags of various types to compactlogix PLC, all in row, and everything's fine except that it crashes randomly during download process. Switching between libplctag and libplctag.NativeImport did not help.

Basic Info:
PLC: Compactlogix 5069-L310ERM 1 MB, E/IP, wired connection
VS ver: 2019 w/ NuGet
.NET ver: Framework 4.7.2
OS: Win 10 21H1 Eng

Overall logic:

1. A list of tags was hard-coded inside main thread, when triggered it looped each tags one by one, and for each tag ran into a function [SetPlcTag].
2. Function [SetPlcTag] gathered connection info regarding PLC from global external config, and went through swtich-case against tag data type, and then instantiated instance [myTagDint].
3. For current instance, called [myTagDint.Initialize();]. After that set up a for loop, did the following for 6 time until read result matched what was written: called [myTagDint.Write();], and then right away called [myTagDint.Read();].
4. Ater the loop finished, exited back to logic # 1 and did the same for next tag in line. Basically it will write more than 50 tags all in a row once, with no sleep() on thread.

Crash situation:
Program launches, stays alive if downloading is not triggered. Once downloading triggered, it may finish the whole process, and go back to idle (awaits next trigger), while in other situation, it crashes during writing any tags to PLC. It is found that crash may happen during any call against the tag instance (any of Initialize() and write() and read()), as we placed nLog in to catch the moment crash happened. We also tried calling Dispose() after instance write complete, but it crashed no metter Dispose() was called or not.

Fault Info:
(At the time the tool was compiled, we were using libplctag stable 1.0.13 from NuGet, but libplctag.NativeImport also crashes)
Faulting application name: Test.exe, version: 1.0.0.0, time stamp: 0xbef66d9a
Faulting module name: ntdll.dll, version: 10.0.19041.1288, time stamp: 0x027db076
Exception code: 0xc0000374
Fault offset: 0x000e6c43
Faulting process id: 0x5bdc
Faulting application start time: 0x01d80477ab21b397

According to Internet 0xc0000374 is a heap corruption exception, but we don't have more clues about what is happening then. Has anyone ever run into this situation? Any advice is appreciated!

[kyle-github]

Are these strings you are reading/writing? If so are they standard sizes?

[U11Leung]

It happens both when reading and writing, and it happens to almost any data types, crashes seen on bools and dints and standard strings, non-standard strings as well.

[kyle-github]

Is there a mix of data types on each run. If it is the string bug in the core DLL, that might overwrite something that is only noticed later. Can you try the test without any string tags?

[U11Leung]

Answer for "Is there a mix of data types on each run" is yes, and as I replied in another issue tracker, we are using (aka. r&w) non-standard user-defined string (to save PLC logic memory space) in each run. We can try without any string r/w ASAP.
Anyway, regarding that issue in C DLL, is there any move effective to avoid, for example treating all strings as UDT and r&w-ing them all via .LEN and .DATA[]?

[kyle-github]

If you can wait for about 24 hours, I hope to have another release out to fix the C DLL issue. I believe I have a repro test.

[U11Leung]

That would be hugely appreciated, we can wait. I am just wondering why only few developers run into this situation.

[kyle-github]

Not many people use their own definitions for strings, or they only read them. At least that is my guess.

[kyle-github]

I just released the core C DLL version 2.4.10 with fixes for this.