I’ve worked with my teammates on VS Core to come up with this list of tips on writing good bug reports. Take it from me as a tester, the better the bug report, the easier it is to get the issue resolved quickly and adequately.
Tip #1 – Clear, but minimum Steps to Repro
Let us know what are the minimum steps needed to reproduce your issue, but be clear as possible what the steps are. When in doubt, include whatever information you think will be helpful. Better too much info than not enough. And if we can’t repro, we’ll be in touch =)
The fewer steps required to reproduce an issue, the clearer the root cause becomes for us. For example, make sure a project is required to reproduce the issue. If you are running into an issue docking a tool window to a certain location, an open project may not be needed to reproduce the issue.
Also, be as clear as possible when providing repro steps. Instead of saying, “now reset VS settings”, let us know exactly how you reset the settings, for example, did you use Tools – Import Export Settings, delete registry keys, run devenv /resetusersettings?
More information on providing solid bug report can be found at http://blogs.msdn.com/productfeedback/archive/2004/07/01/171229.aspx
Note: I’m just making up these examples. To the best of my knowledge, these do not exist on any blog, forum, or Product Feedback Center bug.
Not-so-clear bug report
Title: Tool Window Dragging Issue Body: Whenever I try to dock my Tool Window with another tool window, the docking targets never appear.
Clearer bug report
Title: Tool Window fails to dock with other Tool Windows Body: <version type, build #, general default settings, etc.> Whenever I try to dock any Tool Window with the Find and Replace tool window, the docking targets never appear. I can dock tool windows with other tool windows, but just not with this File and Replace tool window. I verified that I don’t need to have a project opened for this to occur.
In the case of the clearer bug report, I could quickly reset to the general default settings and open the Find and Replace tool window. Since the issue is specific to just the Find and Replace tool window, I can limit my investigation to just it. In the Default Settings, the Find and Replace tool window is set to “Floating” by default. In order to dock another tool window to it in this state, you need to first change the Find and Replace tool window to “Dockable” by either Right-Clicking on the title bar or going to the Window menu.
Tip #2 – Version Info
Let us know which version of Visual Studio you are using. For example, Visual Studio Team Suite, Professional Edition, Standard Edition, or an Express Edition?
Tip #3 – Default Settings Selection
Which default settings did you select on first launch or last reset to? Don’t remember? Go to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\Profile and look at the LastResetSettingsFile value.
For example, if you selected the General Development Settings, you’ll see “General.vssettings”.
Tip #4 – Build #
Are you using the official released version of Visual Studio 2005 (build 50727.42)? If you’re not sure, go to Help – About to check. You can also use the “Copy Info” button to paste in this info.
Also, let us know if you had a previous version of Visual Studio 2005 installed on your machine.
Tip #5 – Solution Configuration
The more details we know about your solution, the closer we can setup our machines to reproduce the issue. This information is imperative to reproducing your issue on our machines.
What sort of projects do you have in your solution?
What language is your project(s)?
What project template(s) are you using?
Are you using any Web projects?
For example, here’s what a solution could look like:
MySolution – WindowsApplication (C#) – ClassLibrary (C#) – <Solution Folder> — ClassLibrary (C#)
Tip #6 – Reporting Crashes
If you happen to encounter a crash, please send the report to Microsoft to help us investigate. Then let us know the crash ID number you sent in the report. To find this information, please do the following:
1. From Start – Run dialog, run "eventvwr.msc" 2. Open the "Application Log" node. 3. Look for the newest event with Source="Microsoft Development Environment" and Event="1–1" 4. Open that event and you’ll see "Bucket" followed by the crash ID number we’re looking for
Tip #7 – Consistent Repro
Let us know if you are consistently running into the issue or if it just happens once in a while.
Also, let us know if the issue reproduces using different projects, if you shut down and restart Visual Studio, etc.
Thanks again for your help making Visual Studio better than ever!
Happy Visual Studio’ing!