Minidebugger工具可在引发异常时捕获异常

Question

We have a program that fails with cryptic (exception -sourced text) message. It's really generic and doesn't tell squat. I could solve this in a minute if I had VS installed on that machine and could run that program with "Catch exceptions as they're being thrown".

Alas, we can't have that on the limited system (remote debugger is no-go as well because firewalls), but a small tool would be ok.

So is there a tool that can catch exceptions of CLR (C# origin here) programs as they're thrown, write them down (with all asociated introspected properties with stacktrace) and let the program die it's merry way? Notice that generic "handle not handled" exceptions is not acceptable because this exception is handled, albeit badly.

Answer 1

Download WinDbg. After installing it, you can just copy the entire folder to the target machine. No installation or registry changes are necessary. Make sure to use the same bit version as your application. Attach it to your application. Load SOS with .loadby sos clr . (Use .loadby sos mscorwks if it is a prior to .NET 4.) Then enable breaking on all CLR exceptions with sxe clr . This will catch both first and second chance exceptions. When it breaks, type !sos.clrstack to get the stack trace. You may also type .dump /ma c:\\app.dmp to write a dump file for further analysis; this could be on another PC at your own pace. Then type qd to detach and quit.

Note that if you just take the dump when the exception occurs you can omit loading SOS and dumping the stack until later moving the dump to another machine for offline analysis. You can delete the WinDbg folder from the target PC after you're done.

Answer 2

procdump is a great tool for that purpose. Use the following command line to start ( -x ) the managed executable ( -g ) and write minidump ( -ma ) each time the first and second chance exception occured ( -e 1 ):

procdump.exe -accepteula -e 1 -ma -g -n 100 -x <path to directory to place dumps> <path to executable being monitored>

-n option specifies the limit of number of dumps to be written before procdump detach (without terminating target process). There is a bunch of other options available. See procdump site for details.