While IIS Express support shipped in Visual Studio 2010 SP1, unfortunately profiling code running in IIS Express does not just work out of the box.  The issue is that the profiler does not “know” how to setup and launch the IIS Express process to enable the various profiling methods.  If this is a blocking issue for you, fortunately this can be manually worked around to profile IIS Express.

The instructions for how to do this, vary depending on the method of profiling you would like to use, and the target framework

CPU Sampling:

• If you’re profiling .NET 4.0 after you’ve launched your site in IIS Express, manually attach to the IISExpress.exe process (Analyze -> Profiler -> Attach/Detach…) and you will be collecting CPU sampling data
• · If you’re profiling .NET <= 3.5:
  • From a Visual Studio command prompt, type:
    • vsperfclrenv /sampleon
    • devenv
  • From the instance of Visual Studio that launches, launch your site in IIS Express and manually attach as in the step for profiling .NET 4.0

.NET Memory Profiling (Sampling)

• From a Visual Studio command prompt, type:
  • vsperfclrenv /<memory option you want—see vsperfclrenv documentation for options>
  • devenv
• From the instance of Visual Studio that launches, launch your site in IIS Express and manually attach as in the CPU sampling scenarios

Instrumentation (including .NET memory instrumentation)

• From a Visual Studio command prompt, type:
  • For method timing: vsperfclrenv /traceon
    if you want memory, see vsperfclrenv documentation for options
  • devenv
  • vsinstr <your binaries that will run inside IIS Express>
  • vsperfcmd /start:trace /output:<report name>
• From the instance of Visual Studio that launches, launch your website in IIS Express and run your scenario
• From the command prompt type: vsperfcmd /shutdown
• Close IIS Express
• Open the resulting .vsp file in Visual Studio

Resource Contention Profiling

• Launch your website in IIS Express
• From a Visual Studio Command Prompt:
  • vsperfcmd /start:concurrency,resourceonly /output:<report.vsp>
  • vsperfcmd /attach:<IISExpress.exe’s PID>
  • Run your scenario
  • vsperfcmd /shutdown
  • close IIS Express
• Open the resulting .vsp file in Visual Studio

Recently we have received several questions regarding Visual Studio Code Analysis integration with Team Foundation Server’s check-in policy and build server, so I thought it would be helpful to clarify the behavior and expose some relatively hidden functionality.

Source Control Check-in Policy

The first point of confusion that often arises is about the source control check-in policy.  A common question is “I have a check-in policy, so why does it let me check-in code that contains code analysis warnings?”, “I want a code analysis check-in policy, but I want to hold different projects (e.g. test and product code) to different standards, can I configure different check-in policies for different projects?”, or “How can I treat warnings as errors so I break the build on code analysis warnings?”

The important thing to note about the code analysis check-in policy is the rule set selected for the check-in policy sets the baseline for the minimum set of rules that must be run on the project before the code can be checked in.  All this does is enforce that the rules were run on the project before a check-in, it does not in fact enforce that the code checked-in be code analysis clean for the rule set that is specified in the check-in policy, nor does it actually require that exact rule set be run, as a superset of those rules can be run as long as each rule in the check-in policy rule set was run, the check-in will not be rejected.

The way to prevent checking in code with code analysis warnings is to modify the action for the rules from the default of “Warning” to “Error” for the rule set on the TFS server, setting the build definition trigger to be a “Gated Check-in”, and enabling Code Analysis as part of the build.  NOTE: taking this approach will also result in your builds breaking on code analysis warnings since you are treating them as errors.

Rule Sets

The first thing to do is pick the rule set(s) you want run for each project.  You can either use the built in rule sets, or create your own custom.   You will need to create at least one custom rule set if you want to use the same set of rules, but block check-ins for some projects, and with the same set of rules not block check-ins for other projects.  The easiest way to create a custom rule set is to start from an existing rule set:

• Open any project’s properties page
• Select the Code Analysis tab
• Choose the rule set you would like to make a copy of from the rule set drop down
• Click “Open”. 
  
• You will now be presented with the rule set editor, from the rule set editor change the action from “Warning” to “Error”
  
• When you save the modified rule set you will be presented with the “Save As…” dialogue since the built in rule sets are by default read only

You will now need to either place your new custom rule set on a share and set the project to use that rule set by selecting “<Browse…>” from the rule set dropdown, or you can drop the new custom rule set into the rule set directory (“%VS_INSTALL_DIRECTORY%\Team Tools\Static Analysis Tools\Rule Sets”) on each developer’s machine and the build server machine, and it will automatically appear as an option in the rule set dropdown.

Configuring the Build Definition

Next we need to configure the build definition:

1. Set the “Trigger” to “Gated Check-in”
   
   
2. Under “Process”, expand “Basic” and set “Perform Code Analysis” to “Always”
    
   

That’s it, now check-ins with code analysis warnings will be blocked for projects using the new custom rule set(s).

To profile both Silverlight and ASP.NET at the same time:

1. Launch your CPU sampling session against your ASP.NET application from Visual Studio
2. In the Performance Explorer window click “Attach/Detach”
   
   
   
3. Select the Internet Explorer process that is running your Silverlight application—if you only have one instance of Internet Explorer open with a single tab, the process will be the “iexplore” process without a Window Title. 
   
   
   
   • If you have multiple instances of Internet Explorer open, or multiple tabs inside internet explorer, you can either:
     • Try looking at the CPU consumption of your iexplore.exe processes in Task Manager to see which one is most active
     • Use Process Explorer
       • Find –>  “Find Handle or DLL…” (ctrl + F)
       • Search for “coreclr.dll”
       • The “iexplore.exe” process with this dll loaded is the PID you want to attach to
         
         
         
4. You are now profiling ASP.NET and Silverlight at the same time

Why can’t the debugger catch/break on my unhandled exception on x64 versions of Windows?

The reason this happens on x64 versions of Windows is a design decision by the Windows operating system; x64 versions of Windows do not allow user mode exceptions to propagate post a kernel transition on the call stack.  What happens is when an exception is thrown in an application, it travels backward on the call stack until it either reaches an exception handler or the application’s “Main()” method.  If the exception reaches the application’s “Main()” method without being handled, the debugger recognizes that the exception went unhandled and breaks the application where the exception occurred.  As shown below, the Form_Load method causes a kernel transition, so when an exception thrown in a Form_Load method reaches the kernel frame on the callstack, the operating system catches the exception.  Since the exception is caught before it reaches the “Main()” method, from the debugger’s perspective the exception was caught—the debugger is unable to determine that the exception was caught by the operating system , not the user code.

How can I tell if this is my problem?

This problem can manifest itself in different ways depending on the type of exception.  Both Windows Forms, and WPF applications have exception handling code in the underlying framework that will catch certain types of exceptions (e.g. NullReferenceException), so in some cases your application will crash with an unhandled exception, in other cases the form will load and appear, however the Form_Load method (and all subsequent calls) will not have correctly run to completion.  There will however be a message in the “Output” window that “A first Chance exception of type ‘<exception type>’ occurred in <application’s name>”

Workaround

Unfortunately there isn’t a lot the debugger can do in this case since the operating system catches the exception (explained above).  The workaround in Visual Studio is to enable “First Chance” exceptions for the exception types that are being thrown in the Form_Load method.  To to this:

1. Navigate to the “Debug” menu, and select “Exceptions”
2. Check the “Thrown” box for the “Common Language Runtime Exceptions” row.  (Note:  You can expand the Exceptions using the “+” sign and only check the "Thrown” box for the desired exceptions")

There are two scenarios however that people have been encountering since Visual Studio 2010 released where Visual Studio cannot correctly determine which engine to attach with, and therefore uses the default of 4.0 leaving 2.0/3.0/3.5 applications “un-debuggable”; (1) developing a class library plug-in for a third party application (Excel, Work, AutoCAD, etc), and (2) interop debugging when launching a native .exe project.  In both cases the symptoms will be the same, you will be unable to hit breakpoints in your managed code (they will be hollow with a message that “No symbols have been loaded for this document”) as well as being unable to step into the managed code.

As I explained above, the cause of this is the managed application is 3.5 or previous, and the debugger is attached with the 4.0 engine.  The best workaround is to add a <supportedRuntime> tag to your application’s *.exe.config file.  For example, if I am debugging the application foo.exe I would edit (or create if necessary) the foo.exe.config file in the same directory as foo.exe.  I would then add the <supportedRuntime> tag with the correct version of the .NET runtime in the <startup> section as shown in the example below.  This will let Visual Studio know which version of the .NET runtime you will be running (so if you are developing a class library plug-in for Excel, you would add the <supportedRuntime> tag to the excel.exe.config file).

<!-- sample foo.exe.config -->
<?xml version ="1.0"?>
<configuration>
    <startup>
        <supportedRuntime version="v2.0.[version on your machine]" />
    </startup>
</configuration>

To determine the correct [version on your machine] look in the “C:\Windows\Microsoft.NET\Framework” directory for the most recent “v2.0.xxxxx” folder.

You might ask, “why only do the feature halfway?”.  The answer to this, is that the ability to debug dumps of managed processes in mixed mode required an architectural change by the CLR team that was made in v4.  So dumps of processes that were running .NET 3.5 and previous will still need to be debugged using SOS. 

Can’t remember or not sure which version of the CLR the process was running on?  The new Visual Studio 2010 Minidump Summary page tells you:

We have received numerous reports of Visual Studio 2010 Beta2 hanging while debugging. The two most common causes identified for this were a bug in IntelliTrace and an Internet Explorer 8 bug when debugging web applications.

IntelliTrace Hang

You can determine if your hang is caused by the IntelliTrace issue by disabling IntelliTrace. To do this:

• Navigate to “Tools -> Options -> IntelliTrace”
• Uncheck “Enable IntelliTrace”
  

Internet Explorer 8

If you are debugging a web application with Internet Explorer 8, and occasionally IE hangs indefinitely after you begin debugging you may be encountering a known bug in IE8 that the IE servicing team is currently working on releasing a fix for (the fix will be available in a future IE patch). You can determine if the IE8 bug is affecting you if:

• Internet Explorer is frozen, but the Visual Studio UI is responsive. Visual Studio will either:
  • Be back in “Design Mode” with a message in the Output window along the lines of “The program ‘[xxxx] Foo.exe’ has exited…”
  • Be in “Run Mode” mode because it is attached to the wrong process (you can verify this if you are not using an express version of Visual Studio by opening the Processes window [Debug -> Windows –> Processes] and you will see that you are attached to a process that is not “iexplore.exe”). Click “Stop Debugging” (or “Detach Process” in the Processes Window) to detach Visual Studio from the incorrect process
    
• You will need to manually terminate Internet Explorer from the Windows Task Manager

IntelliTrace Hang Fixed

We believe that we have identified the cause of the IntelliTrace hang and fixed it. So if disabling IntelliTrace solves your problem and you are interested in evaluating a build with the fix before the public Release Candidate we’d love to hear from you. Note: In order to get this build you will be required to sign a Microsoft Non-Disclosure Agreement (NDA). To participate please contact me (Andrew Hall) at andrehal@microsoft.com

If disabling IntelliTrace does not solve your problem, we’d like to know about that too so we can determine the cause of your hang. Please contact me at andrehal@microsoft.com as well and I will provide instructions to help us diagnose your issue.

A dump is a snapshot of an application at the point in time the dump is taken. It shows what was executing, what modules are loaded, and if saved with heap contains a snapshot of what was in the application’s memory at that point in time making a dump with heap potentially more useful for diagnosing an issue (dumps with heap do however have the disadvantage of being much larger files making them harder to upload/email). Dumps are primarily used for debugging issues that occur only machines the developer does not have access to (e.g. a crash occurs when running on a customer’s computer, but does not occur on the developer’s computer). Dumps are not only useful for crashes, another common example is capturing a dump of an application that is hung.

How to create a dump

There are many tools for creating dumps, the easiest method is using the Task Manager on Windows Vista and up (this has significant drawbacks in many cases however as I will explain below), followed by Windows Systinternals ProcDump (free from Microsoft) but since this is a Visual Studio Debugger blog, I will also show how to use Visual Studio to collect a dump.

A dump is ultimately created by Windows regardless of the tool used to create it, so “a dump is a dump” regardless of what tool is used (there is one exception to this when using Task Manger on a 64bit operating system to create a dump of a 32bit process--explained in the “Creating a dump using Task Manager” section).

Since ProcDump is the most configurable tool for collecting dumps, and is relatively easy to obtain and use, I will explain how to collect dumps with ProcDump first.

Creating a dump using ProcDump

ProcDump is a command line tool for collecting dumps that is freely available from Microsoft.  Applications can either be launched with ProcDump (very useful if the application is crashing on startup), or attached to with ProcDump.  Additionally ProcDump can immediately collect a dump in the case of attaching to a process, or be configured to collect a dump when a variety of conditions are met (the application crashes, hangs, uses too much CPU/memory, etc).  The full description and functionality are documented on the Systinternals ProcDump page

Collecting a dump with ProcDump

1. Download procdump.zip from http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
    
2. Unzip procdump.zip
3. From a command prompt, navigate to the folder where you unzipped procdump
4. Launch procdump.exe with the appropriate arguments for your scenario.  Below I list a few of the most common arguments, however a full list is available on the ProcDump page):
   
-e     Write a dump when the process encounters an unhandled exception.
-h     Write dump if process has a hung window (does not respond to window messages for at least 5 seconds).
-ma  Write a dump file with all process memory. The default dump format includes thread and handle information.
-x     Launch the specified application

Examples of collecting a dump with ProcDump

Launch an application with ProcDump and collect a dump with heap when the process crashes:

C:\>procdump –e –ma –x “C:\My Applications\CrashingApp.exe” crash.dmp

Attach to an application that is hung and collect a dump with heap immediately:

C:\>procdump –ma HangingApplication.exe hang.dmp

Launch an application with ProcDump and collect a dump with heap when process either crashes or hangs

C:\procdump –e –h –ma –x “C:\My Applications\Application1.exe”

Example of attaching to Visual Studio using ProcDump to collect a dump on an unhandled exception

Creating a dump using Visual Studio

1. Open Visual Studio
2. Select “Tools->Attach to Process”
   
3. Click the “Select…” button for “Attach to:”
   
4. Select “Debug these code types:”
5. Select “Native” (Note: Native is used because in versions of Visual Studio prior to 2010 the option to save a dump is not available with the managed engine. Since the dump is created by windows, it does not matter which debug engine is attached to the application)
6. Click OK on the “Select Code Type” dialogue
   
7. Click “Attach”
8. Depending on if you want to create:
   • A crash dump:
     • Reproduce the crash in the application that you are attached to.
     • The instance of Visual Studio attached to the application will display a dialogue asking if you would like to “Break” or “Continue”
     • Click “Break”
       
   • A non-crash dump (e.g. a hung process)
     • Click “Break All” (click the “pause” icon, or select “Debug -> Break All”)
       
9. On the Debug menu, select “Save Dump As…”
   
10. Choose where to save the dump file, and whether you want a dump “with heap” or “without heap” (In Visual Studio 2008 the default is “without heap”, in Visual Studio 2010 the default is “with heap”)
    

Creating a dump using Task Manager

Beginning in Windows Vista, the Windows Task Manager includes support for creating dump files. This can be very useful, and is slightly quicker and less complicated than creating a dump using ProcDump or Visual Studio; there are however a few things to note when using Task Manager to create dumps.

• Task Manager always creates a dump with heap
• If the application has crashed, Task Manager does not include the exception information in the dump
• On a 64bit operating system, dumps taken with Task Manager of 32bit processes cannot be debugged with Visual Studio because Task Manager saves the dump as a 64bit dump of the 32bit process. In the case of a 64bit OS and a 32bit process dumps should be taken using ProcDump or Visual Studio as described above (for a 64bit dump of a 32bit process windbg must be used)

To create a dump using Task Manager:

1. Open the “Windows Task Manager”
2. Select the “Processes” tab
3. Right click the process you wish to take a dump of
4. Select “Create Dump File”
   
5. A dialogue will appear with the location of the saved dump (The file location can be selected and then copied and pasted).
   

Frequently Asked Questions Regarding Dumps:

Q: Can Visual Studio debug dumps of applications written in managed code?
A: Yes (kind of), support was added to Visual Studio 2010 to debug dumps of managed applications using CLR version 4, Visual Studio cannot debug dumps of managed applications running on versions of the CLR prior to v4

Q: Can Visual Studio debug dumps of 64bit processes?
A: Yes, Visual Studio can debug dumps of both 64 and 32 bit processes

Q: Do I have to debug a 64bit dump on a 64bit operating system?
A: Yes, you must be running on a 64bit operating system to debug a 64bit dump