Call to unmanaged dll kills process without raising exception

▲
1
▼

I have a WPF C# application targeting version 4.5 of the .Net framework. My application is calling an un-managed DLL, all but one method is working fine. When I call the problem method my process exits without raising any exceptions, the exit code is: 1073741855 (0x4000001f)

I've read about the <legacyCorruptedStateExceptionsPolicy> element and have added it to my app.config file. I've turned on ALL exceptions in the Exception Settings dialog (I'm using VS2015, BTW). At this point I've run out of techniques to determine what is causing the process to exit.

Update: I happened to try turning on Enable native code debugging in the project settings and now receive the following exception:

Exception thrown at 0x77CBED0B (ntdll.dll) in SK.UnmanagedDLLExceptionTest.exe: 0xC0000374: A heap has been corrupted (parameters: 0x77CF4270).

Given the above information, do any of you know any other techniques that can be used to bring additional details to the surface?

If you are interested (and willing) I have created a dead-simple console application that exhibits the problem, download here.

c#
interop
unmanaged
asked on Stack Overflow Sep 29, 2015 by scubasteve • edited Sep 29, 2015 by scubasteve

2 Answers

▲
2
▼

By turning on "Enable native code debugging" in the Project Settings I was able to have the following exception thrown up:

Exception thrown at 0x77CBED0B (ntdll.dll) in SK.UnmanagedDLLExceptionTest.exe: 0xC0000374: A heap has been corrupted (parameters: 0x77CF4270)

And while that certainly isn't good news, it DOES provide more details and steer me in the direction of a misbehaving dll.

answered on Stack Overflow Sep 29, 2015 by scubasteve
▲
1
▼

The catch legacy flag doesn't help if you don't actually catch anything.

The error seems to decode to DLL not found.

That's a 32 bit DLL and you compiled as Any CPU. If you have x64 (and you probably do), this is the problem. Compile specifically as x86.

If you put the catch in there, it still won't help as bindings are compiled at method entry (before the try is reached).

answered on Stack Overflow Sep 29, 2015 by Joshua

User contributions licensed under CC BY-SA 3.0