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”
As a follow up to my previous post When Page Output Caching Does Not Output I have recorded a video which actually walks you through the steps and issues which I documented in this previous post. So for those of you whom don’t like to read all that much you may watch this video and/or refer back to my previous post on the same subject.
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).
SharePoint’s Page Output Caching can offer a massive performance boost to publishing sites but only when its working and working correctly. One of the problems I have seen is when some administrators turn on Page Output Caching they just assume it works. While this may be the desire and in most cases it may just work for you I would suggest you verify; and I don’t mean hit the site with the browser to see if it speeds up.
This post is about troubleshooting SharePoint’s Page Output Caching. Now if you don’t use Page Output Caching or yours is working just fine you are the ‘Master of your Page Output Caching’ as for the rest of us we will likely need to put on our troubleshooting hat and dig a bit deeper. I find troubleshooting anything is allot easier if you know a little about how the component you are troubleshooting operates and how it is suppose to work.