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,

Answer 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).

Answer 2

TestComplete 7 (including the latest update 7.52) supports .NET Framework 4 only up to version .NET 4 Beta 2. It does not support the release version of the Framework, so this may be the reason of the problem.

Try building the application targeting .NET 2.0. This should resolve the problem.

To test .NET 4 applications, you will need to use TestComplete 8.

Answer 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.

Answer 4

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.