Visual Studio Debugger Team Blog

Visual Studio debugger fails to catch unhandled exception for a Windows Form or WPF Application?

2010-05-12T01:51:31Z

Ever begin debugging a Windows Form to have the form close suddenly without the debugger alerting you to the exception? Or have you ever been stepping through the Form_Load event handler (or a method called by the Form_Load event handler) in a WPF application only to have it unexpectedly bring up the form instead of stepping to the next line? If you have, chances are you were running an x64 version of Windows…“yes?”, keep reading to learn why; “no?” you are encountering a different issue and please let us know about it through Microsoft Connect.

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:

Navigate to the “Debug” menu, and select “Exceptions”
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")

Can’t hit breakpoints in a plug-in or can’t debug .NET 2.0/3.0/3.5 from a mixed mode .exe project with Visual Studio 2010?

2010-04-29T23:08:41Z

With Visual Studio 2010 came the release of Visual Studio .NET 4.0. .NET 4.0 adds a lot of great features and new capabilities; however with .NET 4.0 came a new 4.0 debug engine in Visual Studio 2010 (so there are now two managed debug engines, 2.0/3.0/3.5 and 4.0). Ordinarily if you are developing/debugging your managed application inside of Visual Studio and begin debugging (F5) Visual Studio knows which engine to use. Likewise if you are attaching to a process, Visual Studio is able to tell which version of the .NET Runtime you are running on and attaches with the appropriate managed engine.

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).

<?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.

Why don’t I see “Debug with Mixed” when debugging the dump of a managed process in Visual Studio 2010

2010-04-28T20:38:00Z

It has been well publicized that Visual Studio 2010 introduced the ability to debug dumps of managed processes in mixed mode (as opposed to the old days of native debugging + SOS in the Immediate Window). The one fact about this new feature that often gets overlooked or forgotten is that mixed mode debugging only works for dumps of processes that were running on CLR v4.0.

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:

Jinx: Visual Studio plug-in for debugging multi-threaded code

2010-04-27T00:56:00Z

Today I’m going to introduce a plug-in for Visual Studio (still in beta) that helps to speed up finding concurrency bugs in multi-threaded applications.

Example of a concurrency bug

Consider an application that has two threads (“Thread A” and “Thread B”) that share a common stack. Each thread reads (pops) one value off the stack and then writes (pushes) one value back onto the stack; and between pushes and pops these threads do other work. During testing the application almost always works correctly; however occasionally the application crashes. The test team records data inputs, machine configurations, and use of the application, unfortunately after hours of this they are still unable to reliably reproduce the crash. It turns out that this a concurrency bug (a bug that occurs only if the order of events that produce the crash occur with the exact “right” timing) in the following stack_push() function , which makes reproducing the bug very unreliable.

//Push the given node onto the stack
void stack_push (struct stack *stack, struct node *node){
         struct node * old_top;
         static int count = 0;

         while(1) {
                  old_top = stack->top;
                  node->next = old_top;

                  if (stack->top == old_top){
                           stack->top = node;
                           break;
                  }
         }

         // only valid if there are no concurrent pops
         assert_stack_contains(stack,node);
}

If the threads execute in the following order

Thread A	Thread B
Read stack->top
	Read stack->top
	Write stack->top
Write stack->top

Thread B’s push operation is overwritten by Thread A’s push operation resulting in the bug. During ordinary execution this exact sequence of events can take hundreds or thousands of runs to occur; this is where the Jinx concurrency debugger comes in.

Introduction to Jinx

Jinx works by making a copy of the application’s state while it is being executed, and then runs multiple "simulations" of the application in the background trying to force concurrency bugs to appear. Since concurrency bugs normally occur in or around code that accesses shared data, Jinx adds artificial wait states to the simulations so that shared memory accesses occur as close together as possible. In this way, it can potentially reproduce concurrency issues such as the one demonstrated above in far fewer runs than waiting for the correct order of events to naturally occur on the system.

Unfortunately once the bug is reproduced, locating the problem code can be much harder. One issue that can interfere in correctly locating the problem is called overshoot. Overshoot occurs when one thread causes another thread to crash, the problem thread then continues to execute for a short period of time before the processor halts all of the threads. The problem thread is now at location that is nowhere near where the bug occurred, making discovery of the faulty code difficult. To address overshoot, Jinx introduces a feature called SmartStop, which holds the problem thread on the last line of code to communicate with the shared data, making discovery of the offending code much easier. In the example above, SmartStop would stop thread A in the stack_push() function - since this was the last point of communication before the crash.

Getting starting with Jinx

To get started with Jinx, download and install the beta from http://petravm.com/beta/jinx.msi

Review the Jinx documentation and code samples (comes with samples in C and C#), and work through the short C tutorial in the documentation.

NOTE: Jinx gives three debugging options, including the ability to debug the running operating system. The default mode is to debug the most recently registered program, which is the recommended setting for application debugging.

Help! My console windows won't go away

2010-03-11T21:27:00Z

Many of you may be seeing an issue where your console windows won't close after you stop debugging. The symptoms of this issue include:

· The console application does not terminate as expected after you stop debugging

· The console windows can be moved, minimized and maximized, but cannot be closed

· The corresponding process does not appear in task manager

· You are unable to properly shut down or restart Windows

We have recently seen this issue impacting many Visual Studio users. The bug that is causing this issue is in csrss, which manages console windows for the Win32 subsystem (among many other things). The bug was introduced by a recent security update to Windows, KB978037.

The Windows team is currently working on a fix for this, and we will post it here as soon as it is ready. Unfortunately, we don’t yet have any timelines that we can share at this time, but we will share any information we can as we get it.

As we would like to like to make sure that Microsoft is able to test this fix as thoroughly as possible, please feel free to share your scenarios below (even if they do not include the use of Visual Studio). Which version of Windows are you using (and what architecture)? Besides stop debugging, can you provide details of other scenarios in which you are running into this same problem?

Introducing IntelliTrace

2010-01-29T17:10:00Z

In the upcoming release of Visual Studio 2010 we’re going to be rolling out a very cool new feature called IntelliTrace to enhance and expand the Visual Studio debugger experience. In a nutshell, IntelliTrace is a black box for your debugging experience. As your programs run IntelliTrace can be running as well, collecting lots of debugging data at various checkpoints and saving it off either to browse back to during debugging or to reopen on another machine to examine at a later time. This tool gives developers more control and information during their local debugging runs as well as providing an excellent way for testers to provide much better repro information along with their bugs, as they can use IntelliTrace to attach a log of debugging data leading up to a test failure that a developer can then open later for analysis.

That is the gist of IntelliTrace, but for a more fully featured introduction I can recommend either my take, John Robbins’ Blog or the MSDN documents on the subject. Since IntelliTrace and debugging features go hand in hand (we’re all part of one big team here along with the Profiler) I’ll keep up with some rollup posts on IntelliTrace from time to time here on the debugger blog. Below I’ve linked in some of my most recent post with general information about IntelliTrace, information on the IntelliTrace log files (.iTrace) and the integration of IntelliTrace with the new Microsoft Test Manager. If you have any feedback or questions on IntelliTrace please feel free to drop me a line at my blog and I’ll do my best to answer.

[Ian Huff]

IntelliTrace Events

IntelliTrace iTrace Files

IntelliTrace and Microsoft Test Manager

IntelliTrace in Visual Studio 2010 Ultimate

Visual Studio 2010 Beta2 hang while debugging?

2010-01-06T21:01:49Z

Causes

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.

What is a dump, and how do I create one?

2009-12-30T21:14:00Z

What is a dump and how is it useful?

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

Download procdump.zip from http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
Unzip procdump.zip
From a command prompt, navigate to the folder where you unzipped procdump
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):

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

Open Visual Studio
Select “Tools->Attach to Process”
Click the “Select…” button for “Attach to:”
Select “Debug these code types:”
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)
Click OK on the “Select Code Type” dialogue
Click “Attach”
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”)
On the Debug menu, select “Save Dump As…”
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:

Open the “Windows Task Manager”
Select the “Processes” tab
Right click the process you wish to take a dump of
Select “Create Dump File”
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

Remote debugging on Win7 error: Unable to start debugging ...

2009-11-04T21:05:00Z

If you are running msvsmon on a Win7 machine and are seeing the following error message when attempting to remote debug:

---------------------------
Microsoft Visual Studio
---------------------------
Error while trying to run project: Unable to start debugging.
This operation returned because the timeout period expired.
---------------------------
OK

The issue is that the firewall is not setup properly on the Win7 machine for remote debugging. When msvsmon first launches, it will prompt the user to configure the firewall. But because of the firewall security API changes since Vista, the prompt may not come up.

So if you are seeing the above error message, use this workaround:

Control Panel->System and Security->Windows Firewall: Change notification settings -> enable Notify me when Windows Firewall blocks a new program ->Ok

Try remote debugging again, this time msvsmon should pop up a windows security alert dialog box that prompt you to grant access permission to msvsmon.