Debugging a .exe file that crashes immediately

Question

I work with a managed EXE file that fires immediately upon startup. Usually I expect a dialog that allows you to enable the debugger to start, but in this case there is no such luck. Also, the program runs too fast for me to use the processing application in Visual Studio.

What solution?

Answer 1

If you have installed WinDbg, use the menu File → Open Executable to open the application directly under the debugger and automatically debug it immediately.

Then you can use the commands under Debug (i.e. Go) for its normal operation and debugging. Also download SOS extensions . Not as good as Visual Studio, but useful if you only have EXE (and hopefully PDB, although this is optional) and no source.

Example. This is my source code, which we assume is not available:

static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); int x = 10 - 10; int i = 2000/x; Application.Run(new Form1()); } 

This will work immediately and you will not be able to attach the debugger on time. This is WinDbg output after clicking "Run":

ImageShack Dead Link Removed - Free Circles Me

After loading SOS.dll you can use! DumpStack to see where the exception was thrown:

ImageShack dead link removed - no Freehand Circles, sorry!

Please note that optimizing the JIT or compiler can lead to methods being built in, which may make StackTrace not 100% reliable, but it works for a quick overview.

WinDbg is a bit cryptic, but as soon as you got some basics, made it terrific and at least helped find the root of the problem.

Answer 2

One additional parameter not mentioned above is to insert

 Debugger.Break(); 

at the very beginning of the program - perhaps wrapped in DEIFUG #ifdef, to make it easier to skip when its build time was released. I used this technique to debug Windows services that were knocked down from an early time.

Answer 3

Immediate accident?

I would use ildasm just to make sure that I have a valid (looking) managed executable.

In addition, I was bitten several times, having .exe on a network drive and not having the correct permissions.

Answer 4

A common reason for this is that in the constructor any object is created that is created by calling Application.Run ... as in:

 Application.Run(new MyForm()); 

If the MyForm constructor throws an exception, it usually just crashes.

Also consider using the Assembly Binding Log Viewer to determine if you are missing the required assembly or version problem.

Answer 5

Run it in the debugger ( F5 or Ctrl + Shift + B ). You should be able to set an arbitrary breakpoint (for example, in the main function) and one step in your path.