How to Debug .net applications without Visual Studio

Question

Please let me know if this has been asked before, I wasn't able to find any questions on this subject:-

I need to determine the inner exception of an exception thrown on a computer with the .net framework installed but not Visual Studio (nor is it possible to install Visual Studio on the computer). How can I examine this inner exception?

Note a few points:

• It's no good running Visual Studio from another computer as the problem lies actually on the box; it's a heisenbug of the first order.
• I know WinDbg is an option, however I need this done quickly and unfortunately I imagine the time taken to learn WinDbg sufficiently to get this done will outweigh the time I have - however if anybody has step-by-step instructions on this I would be interested.
• I have full admin permissions and can install anything that isn't too big (the problem with installing VS is that there is insufficient hard drive space).

Thanks!

Solution 1

Have you had a look at MDBG? It may take you a while to get around but is fairly straight forward.

Also DbgClr may be an option, I think its still supposed to be in the SDK somewhere.

Solution 2

It is actually fairly simple to do this with WinDbg if you have a crash dump. Load the dump into WinDbg, load sos, and run the printexception command.

>.load sos
>!printexception

This will tell you the exception as well as point you to the inner exception. Output will be something like:

0:000> !printexception
Exception object: 0135b340
Exception type: System.ApplicationException
Message: GetAverage failed
InnerException: System.IndexOutOfRangeException, use !PrintException 01358394 to see more
<stack trace follows>

If you don't have a memory dump already, you can create one using adplus (which comes with WinDbg).

>adplus -crash -o<dump location> -quiet -pn<name of process>

If you prefer to use PID use the -p option instead.

Solution 3

you can use remote debugging: http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx

Comments

[ljs]

Turned out the exception was caught so I needed to catch a first-chance exception, which I wasn't able to get working using remote debugging.

[Brian Rasmussen]

No problem. WinDbg takes some getting used to, but once you get past that it is really powerful for certain types of problems.