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).
So lets say you create a new site based on the Team template and you would like to create a search center site under that same site collection. So you navigate to Site Actions – New Site and maybe you choose the Enterprise Search Center template and provide a name for your new site and hit “Create”. Well you may be presented with an error like this one…The dreaded unexpected error has occurred error, yuk (failure #1).