Why Microsoft Support Should Be Contacted In Many Scenarios


Since I subscribed to Phil’s blog after using his amazing Krypton Toolkit free controls, I could not avoid his recent posts on VS2010 failures on his machine.

He, as a good .NET component vendor, fired a bug report to our Microsoft Connect portal. But I suggested he contact Microsoft support immediately. Why?


He is almost the very first one I noticed that experienced such an issue. So I cannot reproduce it and involve Visual Studio developers whenever necessary.

Here if Microsoft Support is involved, we are able to collect all relevant information and perform step-by-step troubleshooting on your machine to better understand the symptoms. Usually solutions can be found accordingly.

If you worked with Microsoft support team in the past, please keep a record of what diagnostics tools/methods we share with you. Next time if a similar issue appears, please collect all necessary data and provide them when you open a new case.

*Bug Report Quality*

If you have ever worked as support engineer, you know better how a good bug report is valuable. But it is very hard to achieve a good bug report.

I still keep this list as it was suggested by Borland once,

Can you write a good bug report after reading them? Almost not. Hi Phil, I have to confess your report to our Microsoft Connect is one of the not-so-good bug reports.

It is not your fault to author a not-so-good bug report, as you are already frustrated by the issue, and sometimes you don’t even know the products in details as the task was assigned to you by others.

Here if Microsoft Support is involved, our support professionals can help you refine the words and sentences. While capturing relevant data, we may even provide you quick workarounds.

Microsoft product teams work seamlessly with Microsoft Support. So if you open a support case and provide necessary data, you can expect a closer conversation with Microsoft (compared to Microsoft Connect).

*One Sidenote*

When I was a student and something went wrong with Visual Studio, I kept suspecting that was caused by a product bug. However, the more I learned about the product, the easy I could tell if this was my fault. Of course, now I can even locate product bugs and further investigate them. This is a common learning curve.

Similarly many issues we helped resolve for Microsoft customers are not product bugs. So if you are capable of troubleshooting like Phil, you may do initial investigation on your own, and involve Microsoft Support when necessary. But if you are not that familiar with the specific product and Microsoft common troubleshooting skills, open a support case via http://support.microsoft.com is highly recommended.

Skip to main content