Hi, I am Vaishnavi Sannidhanam, test lead from the Visual C++ Compiler Backend team. I joined Visual C++ team 4 years  ago and helped ship VS2005 and VS2008. In this blog, I would like to introduce you to the most effective way of reporting actionable bugs to us.

Where to open the bug

 

When you find a bug, the best way for you to report it, is to reach us through Microsoft Connect. To report a bug through Microsoft Connect, open the Connect page (https://connect.microsoft.com/) and click on “Your Dashboard”. Select the project the bug pertains to and proceed with opening the bug.

Usage Scenario

 

Giving a description of why you are doing what you are doing, to help us understand and evaluate the importance of this bug fix for you.

Providing us with a repro

 

A repro is nothing but a series of steps that reproduce the behavior you are seeing. It is always useful to give us a repro and the smaller a repro the better it is for us. Sometimes you might not be able to attach a repro case through Microsoft Connect because of the size of the repro. If that is the case, please do make a note in the bug that you have a repro that you were not able to attach and we will make other arrangements to get that from you. It would also be great if you provide us with the expected and the actual behaviors. For UI/accessibility/localization related issues, it is very useful if you were to give us a screen shot of the broken behavior. It would also be very valuable if you let us know what version of the product you found the bug in.

 

Below are specific issues where special pieces of information pertaining to the bug would greatly help us

               

1.       Project conversion issues: It would be tremendously helpful for us when the opened bug contains the following information

1.1.    Original project file

1.2.    Conversion log (upgradelog*.xml which can be found in the solution or project directory depending on what is getting converted)

1.3.    Description of the problem you ran into

 

2.       Visual Studio Crashes: These are usually reported to us as Watson reports hence nothing further needs to be done. However, if for some reason you are not getting a Watson prompt, you can open a bug with the repro steps detailing the version of VS, the type of the project (you are more than welcome to share out the project with us as this improves our chances of reproducing the crash), the series of actions you performed that caused VS to crash, etc. If the crash is on Win7, then the usual JIT window to attach debugger after crash will not be shown, by default the settings hide it.  If you want to debug through the issue, here are steps to turn the debugger on:

2.1.    Go to Control Panel à System and Security à Action Center à  Change Action Center settings à Problem Reporting Settings

2.2.    Select “Each time a problem occurs, ask me before checking for solutions”

Alternatively if your group policy blocks this setting you can click on Select programs to exclude from reporting and add – %ProgramFiles%Microsoft Visual Studio 10.0Common7 IDEdevenv.exe and %ProgramFiles%Microsoft Visual Studio 10.0VCvcpackagesvcpkgsvr.exe

 

3.       Intellisense failures and browsing related issues: You can use the new dev10 feature that enables logging. To enable this feature you can go to Tools à Options à Text Editor à C++ à Advanced à Logging Level and set this to true and level to be 5. By default this is disabled. Once enabled, you can reproduce the problem and attach the resulting log. You can see this log through the output window by selecting “Visual C++ Log”.

 

4.       Memory Consumption Issues: It would be easier for us to track down memory issues if you let us know the amount of memory being used along with a detailed description of what type of actions is causing this to happen. Sharing out your project or a project that exhibits this problem as a repro case would greatly increase our ability to repro this bug on our end. You can also use the sysinternals tool vmmap (http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx) to look at various memory metrics such as virtual memory, working set, native heap, managed heap etc. You can create vmmap files by running vmmap.exe, attaching to devenv.exe when it is in the high-memory state, and selecting Save from the menu.  This saves some data about how the memory is being used in the system which allows us to more easily spot where to start looking for the problem. You can attach this file as part of the bug as well.

 

5.       Project Build issues:  Detailed build log will be very helpful when you hit project  build issues. You can enable detailed logging by going to Tools à Options àProjects and Solutions à Build and Run, set “MSBuild Project build output verbosity” to “Diagnostic” in IDE build or pass /v:diag switch to MSBuild for command line build. It will be helpful if you can also provide the build log from previous versions of Visual Studio.

 

6.       Compile Time Issues: You can produce a pre-processed file or a link repro depending on what kind of problem you are running into. The steps on how to generate these files are documented at  http://support.microsoft.com/kb/974229. Also it is always useful to gather all the switches you are using when doing a compile. By default the switches passed to the compiler will not be shown in the output window and you can turn this on by going to  Tools à Options àProjects and Solutions à Build and Run, set “MSBuild Project build output verbosity” to “Diagnostic”.

 

Pre-processed files:

The very best kind of repro is the small section of source that compiles all on its own without any dependencies and produces an executable that reproduces the problem. If you have this kind of a dependence free repro, please report it along with what wrong behavior you observe and what you think the right behavior is. However, it is very hard and time consuming to produce a dependence free repro. That’s why the next best kind of repro is the single, pre-processed file.

 

For managed code, it is more useful for us if you give us the preprocessed file (following the instructions above) along with all the assemblies referenced during compilation. You can find out what assemblies are referenced by adding /showIncludes to the command line or by clicking no project properties à Configuration Properties à C/C++ à Advanced à Show Includes à Yes

 

Reporting bugs in the pre-processor:

For bugs in the pre-processor (i.e. compiling something /P or /EP doesn’t yield what you think it should), a more elaborate repro helps us out. The elaborate repro is nothing but the main one source file where you noticed the problem along with all the others that the main one #includes.

 

The easiest way to obtain all the source files is to build your repro case with /showIncludes. This will list all the files that are brought in during compilation. If you copy all those files to a directory, you should be able to reproduce the problem in isolation from the rest of your sourcebase. For instance, you should be able to set INCLUDE=. and still be able to produce an object file.

 

Link Repros:

Link repros are used when bugs are occurring during link time for both LTCG and non-LTCG cases.

To generate repros for problems with Profile Guided Optimization (PGO): Problems with the Instrumented Build,  i.e. passing /PGI, simply follow the link repro instructions detailed at http://support.microsoft.com/kb/974229. All needed files will be copied over to the link repro directory.

To generate repros for problems with Profile Guided Optimization (PGO): Problems with the Optimized Build, i.e. passing /PGO, simply follow the link repro instructions detailed at http://support.microsoft.com/kb/974229. In addition, include the .PGC files from your scenario that is causing the problem you want to report.

 

7.       Application Runtime Issues:

 

            Floating point precision issues

After using the above described techniques to reduce your repro size, letting us know what your expected result is and what we are producing is very valuable for us. Also helping us understand what kind of an impact this precision error has on your product would be useful for us when we decide on when to fix the bug. You might also want to look into the various floating point options that the compiler provides that help you choose between precision and performance (http://msdn.microsoft.com/en-us/library/e7s85ffb(VS.100).aspx ).

 

            Application crashes

When your application crashes and you think it is a compiler issue because

you don’t find any fault in your code

you see that this crash happens with the new version after upgrade and does not happen with the old version

you see that the crash happens only in release mode and not in debug mode

In these cases you could provide us with the source code that exhibits this behavior. We would really appreciate it if it were a reduced repro case as this tremendously helps us in narrowing down the problem.

 

Thank you for reading through this blog. I hope this blog enables you to open actionable bugs which in turn will help us ship a higher quality product. Thank you for dogfooding our product.