Application won't crash when profiling with Dependency Walker

Question

I have a console application running in an Azure cloud service, it crashes randomly and therefore I started profiling it with dependency walker to see if I could get more information out.

It's a managed code console app but it loads 3rd party unmanaged code which is the part that is crashing and it just closes the console without any information why.

When I run it with dependency walker I can't get it to crash, what could the differences be for the console application in the context of it running as a profiled app in dependency walker and just running it?

Update

I was able to find a little info in the event viewer.

Faulting application name: runner.exe, version: 1.0.0.0, time stamp: 0x539fe538
Faulting module name: ntdll.dll, version: 6.3.9600.17114, time stamp: 0x53649e73
Exception code: 0xc0000374
Fault offset: 0x00000000000f87a8
Faulting process id: 0xdf8
Faulting application start time: 0x01cf8a16e42e087f
Faulting application path: D:\Users\pksorensen\Desktop\Release\runner.exe
Faulting module path: D:\Windows\SYSTEM32\ntdll.dll
Report Id: 3a46b49a-f60a-11e3-80bb-00155d871170
Faulting package full name: 
Faulting package-relative application ID: 

Answer 1

The 0xc000374 error code means heap corruption which is a particularly difficult problem to try to debug. Typically it is caused when managed code passing objects or memory addresses into unmanaged code and either the managed code not pinning the memory or the unmanaged code having a bug that overwrites memory that it doesn't own. You should review your code for all of the managed to unmanaged transitions and make sure you are handling memory and object references correctly. For troubleshooting you can start with Application Verifier at Why is ntdll.dll crashing my c++ executable? .

If that doesn't help then you will need to enable Pageheap and then attach a debugger to look for first chance exceptions. There are a couple blogs that can help with this step, but as you can see the troubleshooting is not trivial.

• http://blogs.msdn.com/b/jiangyue/archive/2010/03/16/windows-heap-overrun-monitoring.aspx
• http://blogs.msdn.com/b/webdav_101/archive/2010/06/22/detecting-heap-corruption-using-gflags-and-dumps.aspx