I am blogging this reminder because I also need it. If you have an MSDN subscription, one of the subscription benefits is a number of *free* PSS incidents. These can be an invaluable benefit if you are really stuck on something that you either can't find a resolution to or just don't have the time to waste in finding the solution.

The area of PSS for developers is not generalized support. Support engineers are divided up into very specific areas, so anyone that you talk to is an expert in that area. Often the first level of support you reach can help you resolve your problem, but as often, you have probably already done enough digging to go even beyond the level of assistance that these first tier PSS folks can provide. They will not waste a lot of time on a problem that they know they can't solve handily and you will get escalated to engineers with deeper and deeper knowledge of the features you are having trouble with. This is when you get to people at the level of ASP.NET Escalation Engineer, Tess Ferrandez, who blogs at If Broken it Is, Fix it you Should.

If you are an MSDN Subscriber, you can get to PSS easily from the msdn.microsoft.com/subscriptions home page. Look for the "Support Incidents" link on the right. For non-subscribers, a support incident costs $259.

I wrote a blog post in 2006 about my first experience with PSS. It is a good look at how determined the support engineers are to help you. They will keep going until the problem is solved or until you say "Uncle!".

So what triggered these thoughts about PSS? I attended a very deep debugging session by Ingo Rammer at the C2C conference in Poland last week. I haven't seen Ingo in a few years and hadn't realized that he has turned into a debugging guru. Ingo is the type of guy who says "don't send me your log files, just send me the crash dump report" when trying to debug issues in applications. Ingo says that he can learn everything about an application from the crash dump info. He spent a lot of time in the session showing off the power of WinDebug. It is not a tool to take lightly and requires some investment to learn well enough to leverage it's power. In fact, Ingo highly recommends Tess' blog as a place to learn everything you'll need to know about WinDebug. You can use that blog, not just as a reference, but as a manual. John Robbin's debugging books are also high on Ingo's list of must-have resources for learning about debugging.

Later during the conference, I was invited to participate in an interview of Ingo by some of the organizers who are well-versed in debugging techniques. I mostly sat there absorbing the conversation since it is far from my area of expertise. But there was one piece of advice from Ingo that stood out from all of the techniques he discussed. This was about debugging problems with the .NET Execution Engine. Although we do have access to the .NET source for debugging now (in case that's a news flash, check out this post), we don't have access to the Execution Engine. If you receive an ExecutionEngineException, Ingo's advice is not to waste one minute trying to debug these problems, but just to contact PSS right away. They are the only one's that have access to that source code and therefore the capability to dig into the root of the problem.

I will definitely remember that golden nugget and hope that you will too.