Greg, If you don't feel like pressing go execute this:
sxi av sxe -c "!pe;!clrstack;gc" g Just sit next to it in case it does break but otherwise it should just print all exceptions, their call stacks and then immediately continue. Corneliu. On Thu, Jul 22, 2010 at 8:10 AM, Greg Keogh <g...@mira.net> wrote: > Corneliu, Nick, I use windbg a few times a year to find elusive problems. > I was hesitant to attach windbg to a live server process that gets a fair > bit of traffic. The crash only occurs at daily intervals, so it’s not > feasible for someone to sit 24x7 and keep typing ‘g’ and watching for the > guilty exception. However, I didn’t know about the break at > zwterminateprocess, which could be VERY useful in future and I’ll file that > in mental storage. > > > > I ran some experiments in trapping the error. I deliberately put a null > crash deep in the thread process where I found a crash last weekend, then I > hosted the server class in a Form and Windows Service to simulate the crash > and find a way of trapping it. > > > > Strangely enough, I tried to globally trap the error in the Form host by > listening to Application.ThreadException, but it was never called. I’m sure > I’ve used that okay in previous Frameworks, but perhaps the scenario was > subtly different. > > > > In the end I gave up and took an easy but crude way out ... I put a catch > all around a high-level call to deliberately log and swallow any errors. It > works in simulation, so it’s running live now with that catch activated and > we just sit an wait. > > > > I also hotted-up the app to use SmtpClient to send emails to us when an > error is logged. This is a snazzy technique that requires little code. > > > > Greg >
