alexg
alexg

Reputation: 683

MS VC++ Runtime Library Error Running Managed C# Application

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. enter image description here

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:

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

Answers (1)

alexg
alexg

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

Related Questions