Crash course in windbg: start app
windbg.exe - Attach to Process (menu) (the rest are commands in the small command line at the bottom): .loadby sos mscorwks (there is a . dot at the start) sxe clr g It will automatically stop at _every_ .Net exception. You might find lots and be scared of your own code or few and be happy but you will find your exception :) !pe - to print the current exception !clrstack - to print the callstack g - to continue execution until the next issue Alternatively you can execute: bp ntdll!zwterminateprocess to setup a breakpoint when the app exits which should have on the callstack the exception that tears down the process. Happy Debugging, Corneliu. On Wed, Jul 21, 2010 at 8:39 PM, Nick Wienholt <li...@dotnetperformance.com>wrote: > Check out ADPlus - http://support.microsoft.com/kb/286350 > > > > > > *From:* ozdotnet-boun...@ozdotnet.com [mailto: > ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Keogh > *Sent:* Wednesday, 21 July 2010 4:44 PM > *To:* 'ozDotNet' > *Subject:* Unable to diagnose a crash > > > > Folks, we have a random crash in our new release of a “server” class. The > class is actually a wrapper around a database that exposes functionality > over Remoting. The server class can be hosted in a Forms App or in a Windows > Service. > > > > The server is randomly crashing and leaving no diagnostic information we > can use. In the Forms App the window immediately vanishes ona crash. In the > Windows Service it just dies leaves a useless message in the event log. > > > > We found one cause of the crash a few days ago by sheer luck, it turned out > a Reflection method had a spelling mistake and the unhandled exception > caused the immediate crash I describe. Now we have another crash and we have > no clues at all what’s causing it. I’m betting the new error is just another > stupid coding error, but where? > > > > Can anyone suggest some way of getting a stack trace or something else > useful in this situation? > > > > Cheers, > > Greg >
