What are the causes and solutions of exception code c0000005 in mscorwks.dll?

Question

The exception code C0000005 is thrown from mscorwks.dll when the application is run on Windows Server 2008 R2 launched using test complete. Other platforms (Windows XP, Server 2003 R2, Windows 7 32-bit and 64-bit) do not present this exception.

The event log from a single execution has many of the following event with event ID 1023 raised by the .NET Runtime:

.NET Runtime version 2.0.50727.4952 - Fatal Execution Engine Error (7383851A) (80131506)

The application itself makes use of a SOAP interface generated by Visual Studio from a WSDL file, a COM object with an embedded interop, and is targeting .NET 4.

sfc /scannow was run and found no problems with system files on the affected system.

What troubleshooting can be done to identify a solution?

Solution 1

This error is caused by flaws in the way that TestComplete 7 interacts with the heap in mixed managed/unmanaged applications. Instead of using the TestedApp.Run method using the following block of code, modified for you choice of scripting language, presented in VBScript:

Dim oScript, command
Set oScript = CreateObject("WScript.Shell")

command = "%comspec% /c " & PATH_TO_EXE & " " & Args
oScript.Run command, 10, True 

The relevant MSDN article is Run Method (Windows Script Host).

Solution 2

Fatal Engine Execution Error and an access violation are both symptoms of the same problem. FEEE is raised when the .NET garbage collector detects that the internal structure of the garbage collected heap is destroyed. An access violation is a hardware exception, raised by the processor when it is asked to access memory with an invalid address. A common cause of an AV is heap corruption.

These kind of mishaps are very commonly caused by unmanaged code. It is also quite common for unmanaged code to have latent memory management bugs that can go unnoticed for a long time. The kind of damage the bug can do tends to be quite random. Just running it on another operating system which has a different memory allocation pattern can be enough to trigger the bomb.

You have an excellent candidate for the source of the trouble. You'll need to work with the COM server vendor or author to chase the bug.

Solution 3

A 0xC0000005 is an exception code wrapping a Win32 error which means "Access Denied." Given that you are using COM interop and are getting an ExecutionEngineException (in COM, COR_E_EXECUTIONENGINE; 0x80131506), my guess is that either it's a NULL pointer in the COM component or a faulty ComImport directive in your .NET code.

Comments

[Logan Capaldo]

Exception codes are not win32 error codes are not HRESULTs are not NTSTATUSes. Sorry pet peeve of mine.

[codekaizen]

I knew someone would call this out. Ok, fine, the 0xC0000005 is a Win32 error. The corresponding HRESULT is 0x80070005.

[Logan Capaldo]

It's not a win32 error. It's an exception code. Feed 0xC0000005 into eg FormatMessage and you won't get a useful result.

[codekaizen]

Caught again. I changed it before your comment, however. Furthermore, it is a Win32 error, just wrapped in an SEH form (much like the HRESULT).

[Erick]

It is a problem in the com interop but not because of the component itself. It is actually a problem caused by the test harness product being used, test complete 7, that gets a little grabby and causes garbage collection to fail. I will create a more concise answer for those that run into the same problem using the product, but thanks for the help that led me down the right path.

[Erick]

We are aware of the .Net support limitations of TestComplete 7. We are currently in the process of moving to TestComplete 8, but the above is a work around for the .Net 4 compatibility issues.