views:

852

answers:

3

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!

+1  A: 

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

pomarc
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.
kronoz
+2  A: 

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.

Sam Saffron
MDBG did the job! Thanks.
kronoz
+3  A: 

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.

Brian Rasmussen
I really want to learn windbg so I'm sure I'll get onto this at some point; however for the moment mdbg did the job nicely.
kronoz
No problem. WinDbg takes some getting used to, but once you get past that it is really powerful for certain types of problems.
Brian Rasmussen