One of the really cool things about working on and having the community use your tools is sometimes you get really great feedback and suggestions. Recently Heiko Hatzfeld from Microsoft PFE suggested we include method parameter or argument details into the output details produced by SNAP when it takes a snap of a process.
So have you ever heard this “There is Nothing in the ULS Logs” or better (worse) yet you have experienced it. Yea me too, it’s a real bummer and your next step is to typically crank up the ULS logging verbosity and crossing your fingers. Sometimes you get lucky and sometimes you don’t, so where next? I have found myself attaching a debugger and looking at the managed exception messages that trail across the debugger window while I reproduce the problem and sometimes these are enough to either provide a line of investigation or possibly the answer to my issue.
As a follow up to my earlier post Making Debugging a SNAP I would like to share with you a new feature I added recently which allows you to monitor exceptions within your managed processes. The exceptions we are talking about here are managed exceptions. Typically you want to see exceptions treated as exceptional, that is, you don’t want to throw exceptions to determine flow control within a normal execution path. You really want exceptions to be exceptional, that is, something which has occurred and you did not expect and most likely do not desire. For .Net processes entering a try/catch is relatively cheap when it comes to performance but throwing an exception can be expensive. A process which throws a large number of exceptions during a normal run will have degraded performance. As each exception is thrown the exception record must be built which includes a walk of the stack and all the frames within a thread which can be relatively expensive, especially if you have very large stacks.
Continue reading “Monitoring Exceptions is a SNAP”
Recently I left Microsoft where I worked for almost 15 years and where about 10 of those years were spent in Escalation Services where my daily routine was debugging failing or faulting applications. This all began with user and kernel mode Windows processes and then once the .Net Framework shipped I move to the ASP.Net and CLR teams and began debugging more managed processes. Normally customers would send my team crash dumps or memory dumps of the offending process(s) and we would use tools such as WinDbg or CDB to dig deeper into the process to determine what was happening. There are several challenges when doing this type of work and one of the most painful is locating and referencing the correct symbols files (*.pdb).
I have a 16GB Lenovo laptop which I use in my daily work. It runs Windows 7 and while you can install SharePoint 2010 on Windows 7 I choose never to do that (you can read more here about why I don’t use Windows 7 as my SharePoint development platform). I am not a big fan of dual, triple, quad, (or whatever comes next) booting, because as soon as I boot into one OS I will likely need to send email or do something which is setup in another OS. I also don’t like running a server OS on my laptop because I use Bluetooth every once in a while and I like the hibernate and sleep functionality Windows 7 provides. So until Windows 8 hits mainstream with its virtualization platform I must resort to running a 3rd party virtualization solution so I chose VMWare Workstation and currently I am running their latest version 8.0.