This week a college ask me to help him out tracking some strange behavior on one of the production servers of one of our clients. Having found no hints himself in log files and event logs he started to think that Microsoft commerce server was swallowing exceptions (because it has happened in the past).
After I verified the where no abnormalities in the eventsviewer and logs I started following my colleges instincts and started my very first WinDbg session hoping to get back a MS commerce server stacktrace to pinpoint where stuff went wrong.
Having heard of WinDbg at teched two years earlier I was kind of excited to use it for the very first time. I remembered that you had to do something to get .Net stacktraces and yes google is your friend. You need to load in the proper SOS.dll but I was still getting:
CLR exception – code e0434f4d (first chance)
turns out I forgot to ENABLE the CLR exception which you can do by going into the debug menu and enabling it.
And there was a nice trace which I could get with the !clrtrace command. Turns out there was no commerce server problem but the businessvalidationexception that was thrown wasn’t handled properly.
Lesson learned WinDbg is kewl! and validate the chain of events (and investigate the exception handling strategy ) before you go and install serious debugging tools on a production environment.
Hans
Azure in my cloud 