10

I have a website running on a remote server, and want to get some information from an exception that is occurring. I can't install VS or use remote debugging, and have been trying to use various versions of WinDbg with little success. In my local tests, I can get WinDbg to break on a C++ exception, or a CLR exception that I threw, but can't get much more information than 'something was thrown'.

Is WinDbg the way to go, or is there another way, or am I screwed for not having adequate logging?

Improve this question
2
  • I'd say you need better logging, yes Commented Aug 3, 2012 at 21:15
  • I would setup adplus temporarily to create a minidump whenever an exception is thrown, then look at the minidump with WinDbg. Commented Aug 3, 2012 at 21:18

1 Answer 1

Reset to default
20

Attach WinDbg to the process, then enter these commands:

.symfix sxe clr sxd av .loadby sos clr g

The execution will continue (after go command) and will break whenever CLR exception is thrown (or any other unhandled exception). Whenever it breaks on CLR exception you see:

(xxxx.xxxx): CLR exception - code e0434352 (first chance)

Then you can use SOS commands like !pe to print out exception type, !ClrStack to dump stack, !dso to dump managed objects in the stack, etc.

EDIT: I had typos in sxe and sxd commands. Thanks to @MStodd for noticing that.

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

5 Comments

I'm going to try it on my messed up machine later, but it's looking good. It looks like for .NET 2.0, I need to .loadby sos mscorwks instead of .loadby sos clr. That sound right?
@MStodd, that should work too. In .Net 2.0 you can use mscorwks or mscorsrv (for server mode applications), while in .Net 4.0 you can use mscoreei. 'clr` is just a shortcut to the current execution engine. I noticed sometimes clr does not work, and in this case it is fine to use mscoreei or mscorwks or mscorsrv.
@SevaTitov May I ask why you are recommending disabling breaks on access violations? (sxd av) Quite often a managed NullReferenceException initially manifests itself as an AV, so I would think that it would be desirable to enable breaking on these.
@Dono, from what I understand, in some cases CLR causes AV as some sort of internal mechanism, probably related to memory probes. Each instance of that AV is internally handled by CLR itself, so there is no side-effects for application. Please note, that sdx av disables automatic break on first chance exception, not second. If there is actual problem with your code that causes AV, it would likely manifest itself with second chance exception, and windbg will break as usual and allow you investigate the problem.
I've got the new Windows Store version of WinDbg. I can't figure out how to execute these commands.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.