I have a multithreading server application which runs fine for the first ca. 40 seconds (in this time the application is pretty much only waiting for incoming packets). After these 40 seconds it suddenly crashes although nothing changed, no clients connected, no data got send etc.
The crash-report I receive from windows is this:
Problem signature:
Problem Event Name: APPCRASH
Application Name: myapplicationname.exe
Application Version: 0.0.0.0
Application Timestamp: 508d2a0b
Fault Module Name: StackHash_58df
Fault Module Version: 6.1.7600.16385
Fault Module Timestamp: 4a5bdb3b
Exception Code: c0000374
Exception Offset: 000cdcbb
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1031
Additional Information 1: 58df
Additional Information 2: 58df710f17985997dec7b600103e4fd6
Additional Information 3: bc2b
Additional Information 4: bc2b581ed6e84cb4442c19134e8081d3
I checked for possible buffer overflows, memory leaks but that’s not the case (at least I didn’t notice any).
Apart from that, what confused me even more is that, if I compile it and run it in Visual Studio (Local Windows Debugger) this error doesn’t happen, no crash, everything is working as it’s supposed to. I don’t know where to start in order to fix this since I’ve never had such a problem.
I know it is difficult to diagnose something without having the code but there is just too much code and I can’t limit it since I don’t know what this error even means and what it is related to. I’m just hoping someone has encountered something similar or knows what this error means. So far I only found how to fix similar problems for other programs (re-install the application was the answer).
Wild guess:
I have a poll loop which is putting a lot of stress on one of my threads since I didn’t get to the point to implement the whole code. Is it possible that DEP is getting invoked and stops my application in order to protect one of my cpus? -Added a Sleep but didn’t change anything.
You’ll find these exception codes documented in the ntstatus.h SDK header file:
Heap corruption is of course a very common C++ programming hazard. Use the debug allocator available in crtdbg.h if you cannot locate the bug.