21

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!

Improve this question

3 Answers 3

Reset to default
14

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

10

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.

Improve this answer

2 Comments

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.
No problem. WinDbg takes some getting used to, but once you get past that it is really powerful for certain types of problems.
2

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

Improve this answer

1 Comment

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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.