Reputation: 683
We have a managed C# application (MS Visual Studio 2010, target framework: .Net 4 Client Profile) that uses unmanaged COM objects via Interop and also utilizes P/Invoke to call functions in our own DLL (C++). P/Invoke calls are made from System.Threading.Task
procedures and can therefore take place concurrently. We limit the total number of simultaneous tasks to 10.
The application can run for quite some time, continuously creating tasks and invoking unmanaged functions. At some point a dialog box pops up - Microsoft Visual C++ Runtime Library / Runtime Error! / The application has requested the Runtime to terminate it in an unusual way...
There are no event log entries created as a result of the dialog box.
While the dialog box is displayed, the application continues to run, though its memory utilization continues to climb. As monitored in TaskManager and VMMap (Sysinternals), the memory use increases for another 5-10 minutes and then the application crashes.
The question is - why does the application continue to run even after the error dialog box comes up?
Right before the crash, i.e., as the memory is exhausted, System.OutOfMemoryException
's are thrown by any code that tries to allocate memory, and are caught by C#.
So at this point the application event log has a new entry indicates the following:
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18798
Exception code: 0xe0434352
Fault offset: 0x0000c42d
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
No further information is available; dump files are not generated. Our unmanaged components (COM DLL, DLL) do not appear as the faulting modules.
Here's a list of tools we utilized so far:
DbgView to view ATL traces from components involved.
VMMap to investigate fragmentation, heap, etc.
DebugDiag to check for memory leaks, analyze managed and unmanaged memory, call stack, etc.
If there are any other techniques or methods that can be used to determine the actual sequence of invocations that result in MS C++ Runtime error, any constructive suggestion would be appreciated.
Upvotes: 0
Views: 1095
Reputation: 683
After extensive attempts to isolate the reason of the crash, Debug Diagnostic Tool (v2 Update 1) from Microsoft provided the needed information.
We used Debug Diag's Crash/Hang Analyzer for the process we were dealing with. Under Tools / Options & Settings / Symbol Search Path For Analaysis we specified the locations of the .PDB files for all of our components (.Net application, C++ DLLs, etc.)
Once crashed, Debug Diag's resulting call stack pinpointed exactly to the call to the unmanaged 3rd party DLL we're utilizing that resulted in access violation exception / crash.
Upvotes: 1