Semicolon is a new monthly column from Microsoft's Visual C++ .NET Product Manager - our very own Nick Hodapp. The column is intended to be a direct line to Microsoft for you to ask those questions that no-one else can answer. If you've ever wondered about the internal machinations of the VC++ compiler, or ever wanted to know why a particular design decision was made, or want the inside story on a curly Visual C++ question that has been stumping you then post your questions here. Each installment will cover the best or the most interesting question. The rules are simple: Make it interesting, make it about Visual C++, and don't ever mention Visual Basic.
Back in my home state of Wisconsin, deer hunting season has begun in earnest. Starting in September the bow-hunters head for the hills, followed in November by gun hunters and then by the hard-core muzzleloaders in December. Each season hunters dramatically trim the fat off of Wisconsin’s burgeoning deer herd, which in 2001 was pushing 1.5 million head. This large-scale pursuit is analogous to the hundreds of Microsoft developers, who in product pre-release season comb the issue database (somewhat appropriately known internally as “RAID”) looking for the sickliest bugs to take-out. I keep submitting “VB” as a Priority-1 bug, but apparently no one here knows how to fix it.
Understanding Your Prey
As a developer, you understand that all software invariably ships with bugs. Customers are likely to encounter bugs and be pestered by them. Like their live counterparts, software bugs range in severity from annoying to deadly. As a developer of a product, you enjoy the ability to hunt and kill as many bugs as you’re able. But as a customer, you unfortunately don’t have license to fix the bugs you encounter on your own. Rather, you have to contract an exterminator to do so on your behalf. This column is dedicated to providing you with a host of exterminator options for problems relating to Microsoft developer tools, and how to make best use of them. For whatever reason the topic “how to get support” isn’t one that we routinely advertise or offer at your local Microsoft conference. I intend to change that.
Those of you who are more cynical than the rest are likely to jeer at this topic. I know, I know, it’s often amusing to make fun of seemingly oxymoron phrases like “Visual Basic Developer”, “Microsoft Technical Support”, and even “Visual C++”. The reality is that Microsoft has one of the best support organizations in the world, and you just may not know how to use it effectively.
Or, perhaps you’ve had a bad experience with Microsoft support. This absolutely does happen, but it doesn’t have to be the end of the road, nor should it be.
In fact, it’s very easy to make the world stop turning – just ask Maximillien or Paul Selormey – who caused fire drills in Redmond a few weeks ago when I forwarded their CodeProject Lounge posts about their less-than-positive product-support experiences. We want to help you – if you have a bad experience with support, cry foul and let me or some other Microsoft employee know about it.
I chose this topic based on the large amount of feedback generated by last month’s column. A related topic, which I will discuss in a future column, concerns Product Lifecycle. Except where noted, the support options I discuss herein currently apply equally to Visual C++ 6.0 and Visual C++ .NET 2002.
My Home Hunting Ground
There is a caveat I unfortunately need to make. The description I’m about to give of Microsoft’s support policies and options applies specifically to customers in the U.S. International support policies and options do vary and are beyond the scope of this article. I wholeheartedly understand that the Visual C++ audience on CodeProject extends beyond the geography of North America. For those of you outside the US, please use this document as a starting point, then further research the specific policy and options that are available to you. For information on Microsoft’s International support policies, please click here.
Choose Your Weapon
As a developer for Microsoft platforms, you have arguably the largest support group in the known universe. Even if you ignore the official Microsoft support options, there are boundless forums and caches of information available across the Internet.
The one stop-shop for obtaining support for any of the hundreds of Microsoft products is Microsoft Help and Support (at http://support.microsoft.com), which is the public home page of the Product Support Services (PSS) team at Microsoft. This is the place to go whether you’re in danger of becoming a Charles Bronson-esq vigilante, or are simply irritated by a misbehaving feature. At the site you will find several options, ranging from totally free self-help to expensive hire-your-own-militia offerings.
The site offers specialized Support Center pages for particular products. Support Center pages pool together information on top issues processed by PSS, shortcut links to popular Knowledge Base queries, links to downloadable service items (service packs), code samples, and Frequently Asked Questions. Here are links to Support Centers that are of particular interest to VC++ developers:
Add these to your browser favorites.
Knowledge is Power
Microsoft Help and Support also provides an interface to search the Microsoft Knowledge Base, which I’m positive most of you have used before. If you use the Advanced Search and Help option, you can specify a product name to narrow your search. Unless you are sure your issue is localized to Visual C++, try searching the Visual Studio-indexed KB articles as well.
KB articles are largely authored by PSS, and encapsulate the knowledge learned by their staff when investigating an issue. The idea is to create a searchable database that records issues and resolutions so that it will be easier to help the next customer experiencing a given problem. KB articles are typically categorized as “BUG:” (a confirmed bug), “PRB:” (a problem, likely due to how the software was designed), “HOW TO:” (how to do something that is not evident), or “INFO:” (high level basic information).
KB articles that describe bugs or problems will offer a status and (hopefully!) a resolution. The status is often “This is recorded as a bug”, and the resolution is often a set of workaround steps. Obviously a workaround is non optimal, but unless the bug is particularly offensive, it will be assigned a priority that determines if and when it will be scheduled for a fix sometime in the future.
Quick, Fix Me!
Some bugs have no workarounds, or affect enough customers badly enough that Microsoft will fix the bug immediately when it is reported. This results in a Quick Fix Engineering patch, or “QFE”. Security-related bugs will usually receive this treatment. A KB article describing a bug for which a QFE is available will say something along the lines of “A supported fix is now available from Microsoft.”
Now, before you get too excited at the prospect of dialing up Microsoft and demanding we fix your bug with a QFE, let me explain a few things.
A given bug may actually meet the QFE bar, but not enough customers have reported it – yet. If you report a bug and we help you to work-around it, by all means keep checking back to see if the status has changed. If thousands of customers begin reporting the same crashing bug, we’re likely to take note.
The average QFE is very expensive to produce – around $30,000. But Microsoft will never opt away from creating a QFE because of the incurred cost. The primary reasons we might not issue a QFE for a given bug are: a) there exists an “acceptable” workaround; or b) a simple patch would likely destabilize the product in other ways. Bugs that aren’t fixed with a QFE are still tracked, and placed in the queue with an assigned priority.
Once a QFE patch is produced it becomes freely available to anyone who is experiencing the problem it addresses -- but you have to ask to obtain it. We limit QFE accessibility because the likelihood that a QFE will cause other problems is relatively high – QFE hot fixes do not receive the same level of testing as a released product, or a service pack. To obtain a QFE you have to contact support services directly and create a Support Incident.
Periodically we will round up all of the QFE’s and package them together as a publicly available Service Pack. At this point each fix receives additional testing, and perhaps additional tweaking.
The support options available to you are somewhat complicated. They vary by the product SKU version you purchase. Similar to how hunting licenses in Wisconsin grant you a quota on the number of deer you can harvest, Professional, Enterprise, and certain MSDN-subscription level software licenses grant you a set quota of “free” Support Incidents. (The cost for these is built into the purchase price of the product.)
First and foremost, let me say that for all developer-related products you will receive unlimited free online and telephone support for installation issues. The definition and caveats for “installation issues” are here. If you are having trouble installing Visual C++ or Visual Studio, visit this web page and call the toll-free number that applies to you, or click on the online-support button.
For issues not involving installation, you are allocated two free telephone or online support incidents if you bought the “compound-bow” Visual Studio .NET Professional, three if you purchased the “30-30” Visual Studio .NET Enterprise Developer, and a whopping four incidents if you paid for the big-boy “muzzleloader” Visual Studio .NET Enterprise Architect edition. Most levels of MSDN subscriptions also include allocations of support incidents: four for Universal and Full Academic Alliance, three for Enterprise, and two for Professional and High School Academic Alliance.
Use these incidents wisely; after they’re gone it will cost you $245 per incident for phone support and $195 for online support. If you want, you can purchase the stocking-stuffer option, starting at $975 for 5 online incidents and $1225 for 5 telephone incidents. I was going to get some of these for my developer friends (so they would stop bugging me…), but for some reason (and like the XBOX), these are not available at the Microsoft Company Store at an employee rate.
To access online or telephone support for a Visual Studio-product, follow these steps (you can begin at step 2 if desired, by clicking on the link provided):
- Visit http://support.microsoft.com
- In the Support navigation-menu, select Contact Microsoft, then select Phone Numbers, Support Options, and Pricing
- Select your product from the drop-down list, then Continue.
The page you are brought to is specific to the product you selected, and lists the available support options including phone numbers to call, and links to online support services.
Note that if you own the Standard edition of a developer tool which has a lower purchase price set for the developer-enthusiast, you aren’t allocated any free phone or online support options, save for those involving installation issues. Also, if your copy of Visual Studio was obtained through a volume licensing agreement then you may not be allocated the default support incidents – the support you’re eligible to receive should be defined as part of your particular purchase agreement.
Now that you know about the Support Incidents at your disposal, let me give you a brief description of the support call process.
For customers who purchased a boxed version of Visual C++ or Visual Studio (non-MSDN subscribers, and non-volume licensees), you will be asked to supply your Product ID, or PID. This 20 digit number is found in the About dialog in Visual Studio – it will be the same for each “sub-product” installed – that is, Visual Basic and Visual C++ will share the same PID. It is not necessary for you to have registered your boxed copy of the product in order to receive support.
If your support call is covered by your MSDN subscription, and this is your first call, you will need to provide the name of the primary MSDN subscriber, your MSDN subscriber ID, and an email address. You will be provided with a support contract number, which you will then provide for subsequent calls.
Once you have provided the requisite information, you will need to describe your issue to a Tech Router (TR). It is important to be as concise as possible. What product, specifically? What feature of the product? Is the issue related to the IDE? To the compiler? To the linker? Is the issue reproducible by following a series of steps? The more exacting you are in describing the problem, the better the chance that the Tech Router will connect you to an engineer who will be able to diagnose and help resolve the problem in a timely manner.
The support incident will not be ‘closed’ until the customer receives a workable resolution. This does not imply that Microsoft will necessarily issue a QFE – the likelihood is we wont – but it does mean we will work with you until a workaround is found so that you aren’t blocked by the issue.
I’m told that hold times are generally low – typically 80% of calls are answered by a human being in less than a minute. But call during the week if possible – weekend calls historically involve more delays to a resolution.
So far I’ve been discussing the admittedly expensive fee-based telephone and online Product-related support options. There are actually a couple additional fee based options to be aware of: Professional “Advisory” phone-support costs $210/hr, and this will get you the equivalent of a developer consultant on the phone with you, happy to talk about anything as long as you give up your credit-card number beforehand. The phone number to call is (800) 936-5200.
A similar service is available through HP and Unisys, two of Microsoft’s partners who have attained “Gold Certified Partners for Support Services” status. Partner Services is generally cheaper ($24.95/incident for application and desktop products, and $99/incident for Business Systems products). This support option is also available internationally. The caveat with these services is that they are generally only available for non-developer technologies. That is to say, they will support Windows XP but not the Visual Studio.
Why is support so expensive? ‘For crying out loud’, I can hear you shouting, ‘I just want Microsoft to take responsibility when the darn thing doesn’t work’. And we should – we should absolutely take it upon ourselves to fix broken product and get you a fix for free. In fact, we do. If your paid support call results in a QFE hot-fix, you are not charged (nor is the incident counted against your allotment of ‘free’ support calls). But consider for a moment the volume of support calls your own company receives that are the result of user-error as opposed to program-error. Developer-tool products are a hundred times worse because the majority of issues, which developer’s typically believe are related to the tool, are actually related to their code. Not to mention the amount of time spent researching any given problem. It is expensive to debug someone else’s code – especially over the phone.
A final reason for why developer support is expensive (when compared to non-developer-product support) is that we staff the support team with experienced developers who have years of industry experience. They of course command (deservedly) a higher salary than the typical support robot.
Microsoft also offers several support options for enterprise customers, who typically purchase Microsoft products in volume quantities. Again, options abound including Alliance, Premier, and Authorized Premier; I could write an entire column on these alone. Check out this web page for a good synopsis. What it amounts to is that of course we’ll be more than happy sell you whatever level of hand-holding you need or want.
Make that “Free Support Zone” – support options that won’t cost you a penny. Arguably, these are the best options as well, especially when it comes to Visual C++. I’m happy to tell you why.
Free support options abound: MSDN Online Support, MSDN Communities, Developer Newsgroups, the Knowledge Base, the Microsoft Support Center, and officially sanctioned 3rd-party communities (including CodeProject). The sheer volume of searchable data from these resources is enormous. The likelihood that you are the first developer to experience a given problem is small, and assuming this is the case you will likely be able to find at least one reference to the same problem somewhere on the Web.
Online forums and Microsoft Developer Newsgroups are a great way to obtain support from your peers, and from Microsoft – free of charge. Historically the newsgroups were monitored primarily by MVPs (Most Valuable Professionals) (people hand-picked by Microsoft for their activity and contribution to a given product’s online community), and informally by Microsoft personnel who in their spare time enjoy helping out customers.
This fall the Visual Studio product teams at Microsoft are embarking on a new program dubbed ‘Community Room’, that mandates each team member spend a couple of hours per month answering questions posed by customers in online forums. The Visual C++ Community Room is lead by team members Herb Sutter and Edward Dudenhoefer, and is underway as of a couple of weeks ago. Thus far the effort has been a resounding success – we’ve answered hundreds of customer questions, recorded dozens of bugs into the tracking system, and perhaps most importantly, put the people responsible for creating the VC product in front of the people who use the product: YOU. Your feedback will directly influence the people who design and implement Visual C++.
A couple of hints about engaging the Community Room: we’re primarily monitoring newsgroup questions that go unanswered for 24 hours, and that are related to Visual C++ .NET. This means we are answering the most difficult questions, and questions that may have an affect on prioritize fixes for problems with the currently shipping product (and how we design features for the next release). The newsgroups we’re monitoring are the microsoft.public.vc.* forums; we hope to expand the watch to community forums like CodeProject in the near future.
If you happen to be a MSDN Universal, Enterprise, Professional, Operating System or Academic edition subscriber, you have one additional newsgroup option to be aware of. The MSDN team recently committed to respond to customer questions on over 200 managed newsgroups with 72 hours of the original posting. Read more about this program here: http://msdn.microsoft.com/newsgroups/managed.
Perhaps one of the most Frequently Asked Questions by Visual C++ developers is “How do I report a bug?” Thus far I’ve focused primarily on how to get help for a problem you’re experiencing, but sometimes this is overkill. Sometimes you simply want to be a good citizen and report a misbehaving feature of an application.
To report a bug in Visual C++, simply visit the Microsoft Visual C++ Bug Report page and fill out the form. You are not guaranteed a follow up response using this mechanism.
Author’s Update, 7/10/2003. I’ve spent the last several months having discussions with the teams who own the bug reporting page I referenced above. It turns out that there is not a good process in place for us to analyze and triage the bug-reports submitted here. On top of that, the page itself is outdated and collects a lot of spurious non-relevant information, which adds a lot of noise to the data. We’ve decided to pull this page down and replace it with a more sensible one, on a schedule likely to coincide with our next product cycle. In the mean time, please continue to use the other avenues of reporting bugs discussed in this article – including online forums and newsgroups.
Another great way to report a bug is to get the attention of a Microsoft employee in a newsgroup or forum (ala Community Room). As I already pointed out, we’ve already recorded several unknown bugs in VC.NET just by interacting with customers online. If you’re lucky enough to track down the feature owner affected by your bug, you can bet you’ll receive major hand-holding.
Of course, Visual Studio will also attempt to report its own problems back to Microsoft. If the IDE abends, the Minidump exception handling mechanism will save out information about the crash and will prompt you to okay sending this information back to Microsoft. Please click OK! Known crashing bugs will in most cases keep a product from shipping (that is, prior to release. Pressing OK is particularly important if you are using a beta copy of a Microsoft application). Minidump data is automatically processed and tracked – we know whether a given crash is affecting a large or small percentage of customers (and this will affect the priority for a fix, which accounts for why some known crashing bugs in a released application are low priority. In general, crashing bugs are considered evil and will not be tolerated.) Bugs reported via Minidump are often easy to fix – if only because we may not have to replicate the problem.
Steve Balmer recently discussed the successes of Minidump technology in an open letter to customers titled Connecting with Customers. Check it out, Steve calls out some amazing statistics about bugs.
Often times you might have a complaint or suggestion regarding product documentation. The majority of documentation topics – in both online and offline documents – include a link to “Send feedback on this topic to Microsoft”. Clicking the link launches your email program and inserts a reference to the topic. When you hit send your comments will be saved and queued for review by an engineer in charge of that topic. Alternatively, for strictly Visual C++ documentation issues, you can also send email to firstname.lastname@example.org.
I’ll admit that before I came to Microsoft I knew very little about the support options to me – in fact, Microsoft seemed very non-approachable. My goal is to make at least the Visual Studio corner of Microsoft Support approachable to you all.
This is the second installment of Semicolon – I hope you guys are enjoying it. Please feel free to post or send me feedback! What do you want me to write about in the future? Do you want more technical content? More VB wisecracks? Inside information on Chris Maunder? I can deliver!