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
