Original: http://msdn.microsoft.com/en-us/library/aa291845(VS.71).aspx

VS2005: http://msdn.microsoft.com/en-us/library/envdte80.debugger2(VS.80).aspx

VS2008: http://msdn.microsoft.com/en-us/library/envdte90.debugger3.aspx

VS2008 SP1: http://msdn.microsoft.com/en-us/library/envdte90a.debugger4.aspx

I'll leave perusing the docs as an exercise to the reader for right now.  But suffice it to say, there is a lot of stuff to play with here, including the ability to setup exception handling, change debugger options, know when processes start or end (that are already being debugged), change symbol settings, and more!

Please note that writing a debug engine is a complex undertaking.  If you have a language that's targetting the .NET runtime and the platforms it supports, then you probably don't need to go this route (a new Expression Evaluator, Language Service and project system are more appropriate targets).  But if you have a new platform (CPU, runtime, etc) that needs debugging support, this sample should provide good guidance.

This FAQ can be used to narrow down the problems associated with debugging any type of solution using any version of Visual Studio from 7.0 to 2008.

Please be aware that this is very much a work-in progress.  Please continue to refer to it as it is updated.

Prerequisites

·         What steps can I take to better allow other forum members to help me efficiently address my debugging issue?

Performance

·         Why is running or stepping through my solution really slow?

·         What are some steps I can take to alleviate or temporarily work-around the performance problem?

·         I have found that a PInvokeStackImbalance is the cause of my performance troubles.  However, the workaround of setting the COMPLUS_MDA environment variable only seems to work once.  What's wrong?

·         Why does Visual Studio and the system hang when a breakpoint is hit?

·         Why is VS crashing when starting a debug session or when first opening a managed project?

Data Inspection

·         Why can’t I see the values of some of my variables even when I have symbols loaded?

·         Why can't I see see values for some of my object's properties?  I get "Function evaluation timed out." or "Property evaluation failed". 

Breakpoints and other Execution Control

·         Why does my breakpoint appears as with a warning triangle and/or hollow circle and never get hit?

·         Why is stepping jumping all over the place rather than following the execution flow of the source file?

·         When I have multiple threads executing the same code, sometimes breakpoints don't get hit.  Why is that?

·         Sometimes as I'm stepping through my code, I suddenly find that my debuggee has hung, crashed, or some threads have terminated unexpectedly.  I don't think it's my code that's the problem, so what's wrong with the debugger?

Errors and Messages

·         Why am I getting the error “The Binding Handle Is Invalid?”

·         Why am I getting the error “The debugger is not properly installed?”

·         After installing Visual Studio I will sometimes get a Visual Studio dialog box stating that an unhandled exception occurred.  What is that?

·         How do I restore Window’s original exception handling behavior (Dr Watson) or change to a different handler?

Web Project Debugging

·         Why Can't I debug an IIS web project on Windows Vista Home Premium?

Remote Debugging

·         How to do I setup for remote debugging?

·         How do I remote debug from my workgroup to my domain machine? 

·         How do I remote debug between two domains without two-way trust?

·         How do I remote debug on workgroup machines?

ASP and ASP.NET Debugging

·         What do I need to know when debugging an ASP.NET application?

·         Is it possible to debug classic ASP with Visual Studio 2005?

·         I receive the following error when debugging my ASP.NET Web Application.  What do I do to fix it?

·         My multi-threaded console application makes use of a Web Service.  When I launch it under the debugger it doesn't work, and simply hangs on the call into the Web Service.  When I launch it outside of the debugger everything is fine.  What's going on?

·         When debugging an ASP.NET and I'm stopped at a breakpoint after about two minutes something happens and I'm no longer debugging the application. I can continue clicking things in IE and the application responds, however, it never stops at any breakpoints. It's like the debugger has been disconnected from the process it was debugging. What's the problem?

SQL Debugging

·         Why can't I debug SQL stored procedures?

Debugging on 64-bit Operating Systems

·         Why doesn't the debugger detect exceptions that were thrown but not explicitly handled by my program?

Useful Information

·         Other than the forums is there a way to inform the Visual Studio team about bugs and provide suggestions for the debugger?

·         What is a minidump and how do I create one?

·         What are symbols?

·         Where should symbol files be stored and accessed?

·         How can I know if symbols are loaded for my program, dll or other module?

·         What is function-evaluation in the context of debugging and how does it affect me?

Prerequisites

What steps can I take to better allow other forum members to help me efficiently address my debugging issue?

When posting a question to the forum please provide as much relevant detail as possible.  In particular, please always ensure to provide the following information:

1.    What version of Visual Studio are you running?

a.    Visual Studio .NET (7.0)

b.    Visual Studio 2003 (7.1)

c.    Visual Studio 2003 SP1

d.    Visual Studio 2005 (8.0)

e.    Visual Studio 2005 SP1

f.     Visual Studio 2008 Beta 2

g.    Visual Studio 2008 RTM

2.    Are you running Visual Studio on the same machine as your debuggee?

In other words, are you debugging remotely?  If debugging remotely please indicate some basic network details, such as whether both computers are on the same or a different domain or workgroup.

3.    What version of what Operating System are you running? If different for Visual Studio and your application please specify.  Are you running on a 64-bit machine?

4.    What type of project are you debugging?

a.    Windows Forms application

b.    ASP.NET Web-Application

c.    Web Service

d.    Console Application

e.    Client-side script

f.     Other, please specify

5.    What language are you trying to debug?

a.    C#

b.    VB

c.    C++

d.    J#

e.    Script

f.     A mix of any of the above

6.    A set of detailed steps or a sample project that demonstrates the issue.

Performance

Why is running or stepping through my solution really slow?

There are a multitude of reasons why this behavior can happen.  The reason can be as simple as slow performance of the program being debugged, to possible bugs within Visual Studio.  Here are some resources you can use to help narrow down the problem.

·         First read through the question at the bottom of this FAQ entitled “What is function-evaluation in the context of debugging and how can it affect me?”

·         For managed code (C#, VB, J#) see this blog article for many possible explanations and workarounds. 

·         If your managed application is a Windows Form application and creates threads, you’re most likely running into the one of the difficulties of supporting debug-time function evaluation.   See this blog article for more details.

·         For native code (C++) you may be running into Symbol Loading hangups, or lots of exceptions or an excessive amount of debug output. 

·         Native code debugging performance can also be a result of the problem documented here.  

What are some steps I can take to alleviate or temporarily work-around the performance problem?

·         Close certain debugger toolwindows, especially the callstack window, the autos, locals, and watch windows.

·         VS2005: Turn off source file checksum support by disabling "Tools->Options->Debugging->Require source files to exactly match the original version."

·         VS2005: If debugging managed code, turn off MDAs.

·         VS2005: If debugging managed C# code, uncheck the following option: “Tools->Options->Debugging->General->Call ToString() on objects in variables windows”

·         VS2005: If debugging managed code, uncheck the following option: “Tools->Options->Debugging->General->Enable property evaluation and other implicit function calls”

·         Review your symbol path settings.  These can be found under “Tools->Options->Debugging->Symbols”.  Symbol paths to remote computers can cause delays depending on network traffic and availability.

·         Delete your user-options (.suo) file. This is a hidden file that is stored next to your solution file (.sln file). It contains several pieces of debugging information for a solution including breakpoints, source & symbol file paths, watch window items, exception settings, and memory window expressions. To delete the file you will have to unhide it first. Please note that there are other pieces of non-debugger information stored in the SUO that you may or may not be willing to lose. In that case, rename the file temporarily rather than deleting it.

Why does Visual Studio and the system hang when a breakpoint is hit?

A hang of Visual Studio that also appears to affect the system is can be caused by the use of the Microsoft Language toolbar that is part of Advanced Text Services. This is a known issue that is being addressed by the Windows team.

To workaround the problem, the language toolbar can be disabled.

·         Go to the Control Panel

·         Choose Regional and Language Options

·         Go to Languages tab & click Details

·         Go to the Advanced tab and uncheck Advanced Text Services.

·         See Nachum Kanovsky’s excellent post about this problem at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=784282&SiteID=1. An additional resource for this problem is located here at http://www.virtualdub.org/blog/pivot/entry.php?id=118

I have found that a PInvokeStackImbalance is the cause of my performance troubles.  However, the workaround of setting the COMPLUS_MDA environment variable only seems to work once.  What's wrong?

This is the result of a bug in Visual Studio that will be fixed in a future release.  In the meantime, you can work around the issue by:

·         Disabling the Visual Studio hosting process.  This can be done by unchecking the "Enable the Visual Studio hosting process" on the Debug tab of your project's properties.

·         Restart Visual Studio ensuring that the COMPLUS_MDA environment variable is set to 0.

Why is VS crashing when starting a debug session or when first opening a managed project?

There are a set of registry keys that are used by the support team to obtain verbose logging for several debugging components.  Deleting them can stop VS from crashing. 

VS2008: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Support\Trace

VS2005: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\Support\Trace

Data Inspection

Why can’t I see the values of some of my variables even when I have symbols loaded?

This can typically occur if the debuggee you are inspecting has been optimized by the compiler.  You can typically ensure that you are debugging an unoptimized version of your program by setting your configuration to “Debug” when building a Visual Studio solution. 

Debugging optimized code is possible but can be quite tricky.  See these blog articles for some helpful hints:

 http://blogs.msdn.com/greggm/archive/2004/12/15/315673.aspx

 http://blogs.msdn.com/greggm/archive/2006/01/23/516447.aspx

Why can't I see see values for some of my object's properties?  I get "Function evaluation timed out." or "Property evaluation failed". 

See the question at the bottom of this FAQ entitled “What is function-evaluation in the context of debugging and how can it affect me?”

Breakpoints and other Execution Control

Why does my breakpoint appears as with a warning triangle and/or hollow circle and never get hit?

There are several reasons why this can happen:

1.    Matching symbols may not have been able to be found that allows the debugger to match your source file to the machine code being executed (See below for a short explanation of symbols).  Without symbols breakpoints cannot be mapped from source code to machine code.

2.    The source code you have opened inside Visual Studio 2005 does not match the executable code you’re trying to debug.  This may indicate that you have made changes to your source file but did not rebuild your solution to match it.  If you are aware of this but want the debugger to make an attempt to set the breakpoint anyway, you can do one of two things:

a.    Right click on the breakpoint and choose “Location…” Then check the “Allow the source code to be different from the original version” checkbox.

b.    Turn off source code verification altogether.  Go to Tools->Options->Debugging->General and uncheck “Require source files to exactly match the original version”. 

3.    The component or program you have set the breakpoint in has not been loaded into memory yet.   When a DLL or component is loaded for your program, the debugger is notified and then will attempt to “bind” the breakpoint so that it can be hit.

Why is stepping jumping all over the place rather than following the execution flow of the source file?

There are at least a couple possible explanations for why stepping through code sometimes doesn’t necessarily follow the flow of the source.

1.    The code you are debugging is optimized by the compiler .  You can typically ensure that you are debugging an unoptimized version of your program by setting your configuration to “Debug” when building a Visual Studio solution. 

Debugging optimized code is possible but can be quite tricky.  See these blog articles for some helpful hints:

 http://blogs.msdn.com/greggm/archive/2004/12/15/315673.aspx

 http://blogs.msdn.com/greggm/archive/2006/01/23/516447.aspx

2.    The source file you are viewing doesn’t match the code you are debugging.  Visual Studio 2005 attempts to ensure that this cannot happen without you knowing about it, but that functionality can be disabled.  To ensure that is enabled check the following debugger option:

·         Tools->Options->Debugging->General: “Require source files to exactly match the original version”.

·         In versions of Visual Studio previous to 2005, the only way to be sure that the source file matches the debugee is to rebuild your solution.

When I have multiple threads executing the same code, sometimes breakpoints don't get hit.  Why is that?

As with other strange behavior that can occur while debugging (see the Performance section above), this is the result of supporting property evaluation while debugging.  This problem can be worked-around by adjusting implicit function evaluation in Tools->Options->Debugging.  Uncheck the option "Enable property evaluation and other implicit function calls".

Errors and Messages

Why am I getting the error “The Binding Handle Is Invalid?”

See http://blogs.msdn.com/habibh/archive/2005/11/10/491572.aspx.

Why am I getting the error “The debugger is not properly installed?”

See: http://blogs.msdn.com/greggm/archive/2004/04/16/114828.aspx and http://blogs.msdn.com/greggm/archive/2006/10/18/one-cause-for-the-debugger-is-not-properly-installed-in-visual-studio-2002-3.aspx

After installing Visual Studio I will sometimes get a Visual Studio dialog box stating that an unhandled exception occurred.  What is that?

When you install Visual Studio, it installs feature called Just-In-Time (JIT) debugging.  JIT debugging is a feature of Visual Studio that allows a developer the ability to debug a program that crashed right at the point it crashed even if Visual Studio was not previously running.  If this behavior is not useful to you, which can be the case if the crashing program isn’t something you’re working on, it can be disabled or modified following the instructions at http://msdn2.microsoft.com/en-us/library/5hs4b7a6.aspx.

How do I restore Window’s original exception handling behavior (Dr Watson) or change to a different handler?

See http://support.microsoft.com/default.aspx/kb/923827.

The program '[1234] w3wp.exe: Managed' has exited with code -3 (0xfffffffd)

In IIS 7 go to the Application Pools and select the Advanced Settings for the pool which you process runs in. In the Process Model section you can do one of two things;

·         Set the Ping Enabled property to False. This will stop IIS checking to see if the worker process is still running and keep your process alive permanently (or until you stop your debugged process)

·         If you prefer to allow IIS to continue the monitoring process then change the Ping Maximum Response Timeout value to something larger than 90 seconds (default value).

Web Project Debugging

Why Can't I debug an IIS web project on Windows Vista Home Premium?

See https://connect.microsoft.com/content/content.aspx?ContentID=3705&wa=wsignin1.0&siteid=210, and download the fix that corresponds to ‘KB 937523’.

If you are running into an authentication issue (HTTP 401) while trying to F5 an IIS web project on Vista, then this fix will help. In these scenarios, F5 will fail with one of the following error messages:

If F5 is failing in any other way, then this fix will not help.  Please submit a bug at https://connect.microsoft.com/site/sitehome.aspx?SiteID=210&wa=wsignin1.0

Remote Debugging

How do I setup for remote debugging? 

Though this site specifically refers to setting up for ASP.NET remote debugging, it contains much useful remote debugging information:

http://support.microsoft.com/default.aspx/kb/910448/en-us

How do I remote debug from my workgroup to my domain machine?

See http://blogs.msdn.com/greggm/archive/2004/10/04/237519.aspx

How do I remote debug between two domains without two-way trust?

See http://blogs.msdn.com/greggm/archive/2004/10/04/237519.aspx

How do I remote debug on workgroup machines?

See http://blogs.msdn.com/greggm/archive/2004/10/04/237519.aspx

ASP and ASP.NET Debugging

What do I need to know when debugging an ASP.NET application?

See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vxtskDebuggingASPWebApplication.asp.

Is it possible to debug classic ASP with Visual Studio 2005?

Yes it is.  Please see http://blogs.msdn.com/greggm/archive/2006/03/15/552108.aspx.

I receive the following error when debugging my ASP.NET Web Application.  What do I do to fix it?

Error while trying to run project: Unable to start dbugging on the Web server.  You do not have permissions to debug the server.  Please see http://support.microsoft .com/default.aspx/kb/319842/en-us

My multi-threaded console application makes use of a Web Service.  When I launch it under the debugger it doesn't work, and simply hangs on the call into the Web Service.  When I launch it outside of the debugger everything is fine.  What's going on?

If your application is blocked in Console.ReadKey/ReadLine then they are running into a known a debugger problem.  Fortunately, there is an easy work-around.  Remove the ‘[STAThread]’ attribute from the main method.  From a technical standpoint, doing this is the right thing to do anyway since STA threads must pump messages, otherwise resource leaks can occur.  This is due to the way COM interop works.

When debugging an ASP.NET and I'm stopped at a breakpoint after about two minutes something happens and I'm no longer debugging the application. I can continue clicking things in IE and the application responds, however, it never stops at any breakpoints. It's like the debugger has been disconnected from the process it was debugging. What's the problem?

The worker process that runs your managed application has exited due to a timeout in IIS.  To fix this proble, in IIS 7 go to the Application Pools and select the Advanced Settings for the pool which you process runs in. In the Process Model section you can do one of two things;

·         Set the Ping Enabled property to False. This will stop IIS checking to see if the worker process is still running and keep your process alive permanently (or until you stop your debugged process)

·         If you prefer to allow IIS to continue the monitoring process then change the Ping Maximum Response Timeout value to something larger than 90 seconds (default value).

Debugging on 64-bit Operating Systems

Why doesn't the debugger detect and notify me of exceptions that were thrown but not explicitly handled by my program?

Due to the architecture of 64-bit operating systems and how exceptions are propagated to 32-bit applications through the WOW64 layer, the Visual Studio debugger is not notified when a 64-bit debuggee does not handle a thrown exception.    The result is that when an unhandled exception occurs, the debugger appears to ignore it. 

There are two possible workarounds for this issue. You can either enable the debugger to break when an exception is first thrown via the Debug->Exceptions Dialog.  Or you can add an exception handler to your code.

SQL Debugging

Why can't I debug SQL stored procedures?

·         Most likely you're trying to debug on a version of VS that doesn't support SQL debugging. You need Visual Studio Professional Edition or higher.

·         Credentials used to run VS and to make connection to SQL Server must have SA role e.g. part of Administrators group on SQL Server box.

·         There is a connection to a server in Server Explorer that doesn't exist anymore.

Useful Information

Other than the forums is there a way to inform the Visual Studio team about bugs and provide suggestions for the debugger?

Go to https://connect.microsoft.com/site/sitehome.aspx?SiteID=210&wa=wsignin1.0 and click on Submit Feedback and follow steps to file a bug/suggestion against VS debugger.

What is a minidump and how do I create one?

A minidump basically a snapshot of the state of a program taken at a moment in time and is most often used to diagnose the reason a program has crashed or hung. If you are experiencing a crash of Visual Studio itself, you will often be asked to provide a minidump of devenv.exe at the time of the crash.

There are several ways of creating minidump files.  If you have Visual Studio Standard or greater installed, you can do it as follows:

1.    Open a new instance of Visual Studio.

2.    Choose Tools->Attach To Process…

3.    Click the “Select…” button and on the Select Code Type dialog, choose “Debug these code types” and ensure that only “Native” is checked.  Click OK.

4.    In the Available Processes list, select the process for which you want to create a minidump.

5.    Click the Attach button.

6.    If the program you’re attaching to was in a crashed state, then the debugger will automatically display information regarding the exception that occurred and allow you to choose “Break” or “Continue”.  Choose “Break”.

7.    If the program you’re attaching to was hung or running, then choose Debug->Break All.

8.    Now choose Debug->Save Dump As…

9.    You will be prompted to choose a filename and location for the minidump file (stored with a .dmp extension).  If you were asked to provide heap information with your minidump, please be sure to choose “Minidump with Heap” option in the Save as type dropdown.

If you do not have an appropriate version of Visual Studio installed, like Visual Basic Express or Visual C# Express and the Tools->Attach To Process… menu item isn’t available, a minidump can be created using other available free tools such as: 

http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3. 

What are symbols?

“Symbols”, “symbol files” or “PDB files” all refer to debugging information for a program or other executable component.  They usually take the form of a file with a .pdb extension.  They represent a mapping of executable machine code to human-readable source code that you create in Visual Studio.

When you build a Visual Studio solution, symbol files are typically created in the same folder as your other solution outputs.  Your solution’s build system is responsible for creating these symbol files and managing their updates as you make changes to your solution.

Program execution is not affected by the existence or non-existence of symbol files.  However, in order to efficiently debug a program, symbols must be available and must be found by the debugger.  If symbols cannot be found, the debugger will typically warn you in some manner. 

Debugging programs or components without symbols is possible but can be very difficult, since the debugger has no way of matching up executable code to the source files that were used to create it.

For more information also see http://support.microsoft.com/default.aspx?scid=kb;en-us;Q121366. 

Where should symbol files be stored and accessed?

By far, the most common place for symbol files to reside is next to the component they were generated for.  For example, if you have a program called HelloWorld.exe, you will typically have a HelloWorld.pdb file residing in the same folder.  The debugger can and will automatically load these symbol files when debugging.

Symbol files can also be archived to folders other than next to their component.  When this occurs, the debugger has to be told where to find them.  In Visual Studio this is typically done by specifying a set of paths.  This setting can be found in Tools->Options->Debugging->Symbols.  If your symbol files are being archived on a machine that is on a network, then be sure to consider setting a local symbol cache.  The debugger will use this local folder to copy the symbol files it needs and will ultimately result in much better performance of your debugging sessions.

How can I know if symbols are loaded for my program, dll or other module?

If matching symbols can be found or loaded for your component, a message to that effect will be shown in Visual Studio’s output window.  If you didn’t happen to see that message fly by, you can use the Modules window (Debug->Windows->Modules) to determine which components in your debugee have loaded symbols and which haven’t. 

See the column labeled “Symbol Status”.  To get further details about where symbols were loaded from, or why they weren’t loaded, right click on a module and choose “Symbol Load Information…”

What is function-evaluation in the context of debugging and how does it affect me?

When the debugger attempts to evaluate the properties for the objects in VB, C# or J# it has to run code in the program you’re debugging. Depending on how the property is coded it’s possible that it will not be able to finish running before an answer is expected to be received by Visual Studio. When this happens, the VS Debugger essentially tells the debuggee to abort the evaluation. This abort can sometimes be done safely, but oftentimes it cannot. In those cases, the debugger has to forcibly cause the debuggee to finish whatever it is trying to do.

If you’re having trouble visualizing such a situation, take a peek at this implementation of a class with two really obviously bad properties:

class MyClass

{

int x = 0;

public int MyBadProperty1

{

get

{

MessageBox.Show("Hi there.");

return 10;

}

}

public int MyBadProperty2

{

get

{

while(true)

x++;

return x;

}

}

}

Hopefully, it’s obvious that both properties are really bad and can potentially cause a huge amount of grief while debugging (Let alone running your application). Yes, these are blatantly obvious, but they can be duplicated in far more subtle ways. The point is, is that the debugger has to try to deal with situations like this.

When a rogue property evaluation like this comes around, the debugger waits for some period of time before deciding that it’s not going to get the information it’s expecting. At that point it attempts to safely abort the evaluation. Unfortunately, this is frequently not possible. If that’s the case then there is no choice but to force the evaluation to complete by simply stopping it in its tracks.

While this makes the Visual Studio debugger able to continue, it has some potentially really bad side-effects on the state of the program being debugged:

a.    At an abstract level, implicit function evaluations like this change program behavior; aborts are even worse. A func-eval is supposed to execute an entire function atomically. Abort executes a random subset of the function, and can thus have very significant and unpredictable behavior changing affects.

b.    Rude aborts may not always be possible. For example, if the thread is in native code. This can be a very common scenario for winforms properties that do a SendMessage.

c.    Rude aborts can leave the managed debuggee in an undefined state. For example, if you abort a thread in the middle of updating some user data structure (eg,a hash), that structure may then be left in an inconsistent state.

d.    Rude aborts don’t run cleanup code, and will likely leave the thread in an undefined state. For example, it may leave locks orphaned leading to subsequent hangs. It could even cause other downstream affects that result in threads to being “mysteriously” terminated.

e.    Ultimately rude aborts are intended as a mitigation for stray func-evals, not a mainline scenario.

For debugging scenarios like this, Visual Studio 2008 has provided some mitigation for the most common form of these scenarios, but not all of them by any means. So for all versions of VS, the best recommendation when running into problems is to turn off implicit function evaluation: "Tools->Options->Debugging->Enable property evaluation and other implicit function calls." Yes, this is heavy handed, but in many instances it's the only way.

Once automatic evaluations of properties is turned off, it's still possible to get values for them, but you will have to pick and choose which ones you'd like to see. Of course, if you pick one that ends up requiring a rude abort, you're going to potentially be left in a bad state again.

The moral of the story is that while debug-time function-evaluation is powerful and even necessary, it doesn't come without its share of very problematic behavior. We are continually trying to find ways to make this less painful for our users, but it's quite a hairy problem.

For even more on this subject, please see: http://blogs.msdn.com/jmstall/archive/2005/11/23/496135.aspx and the related links.

"Is there any way to step into a function without having to bother stepping into all the properties that might have to be executed as parameters before getting to what I'm really interested in?"

The standard answer for Visual Studio 2005 and Visual Studio 2008 has been "well, you probably want to get familiar with the DebuggerStepThrough or DebuggerNonUserCode attributes and use them it in your code."  However, if it's not your code that you're debugging through, or you don't have the option or would rather not modify it, then this solution isn't sufficient.

C++ users have had an alternate solution for awhile now.  It's called Step Into Specific.  The basic idea is that while in the editor the user can right click on a function call to choose from a list of additional function calls that will ultimately be made.  The function call chosen becomes the next stepping point.

Why don't we have this for managed code debugging?  The short answer is that this type of solution requires support from the .NET runtime. This support is not in .NET 2.0, nor is it in the runtime that will ship with VS 2008 (which is basically mainly an extension of the core 2.0 runtime).

What's a managed programmer to do then?  Curse and swear.  Or perhaps try to find a workaround.  That's where this article comes in. I've created a macro called StepIntoHere().  It analyzes the code on which the editor caret is currently positioned and then attempts to simulate a "step-into" exactly the code that implements that function, bypassing any other function calls or properties that have to be made along the way.

For example, say you have this code: 

           CoolClass c = new CoolClass();

           c.DoSomething(new UnCoolClass().MyProp);

This macro allows you to place the caret on "DoSomething" and then do a step into the "DoSomething" function directly rather than having to first step into the constructor for "UnCoolClass" and then it's "MyProp" property. 

Sounds great, and it seems to work quite well for trivial applications I've tried it with.  I'm not too sure how well it works for much larger apps, but I'm hoping this blog will help me find out.

(See my Idiot's Guide for creating and using VS Macros for quick and easy steps on how to add this macro to VS.  To make it more like the C++ version, add it to the Editor's context menu. For extra credit, add an image for it by copying and pasting the existing step-into icon and modifying it slightly.  This can be done while customizing your context menu... hint: right click :) )

Sub StepIntoHere()

        If DTE.Debugger Is Nothing Or DTE.Debugger.CurrentMode <> dbgDebugMode.dbgBreakMode Then

            Beep()

        Else

            Dim textSelection As EnvDTE.TextSelection = DTE.ActiveWindow.Selection

            If textSelection.IsEmpty Then

                textSelection.WordLeft(False)

                textSelection.WordRight(True)

            End If

            textSelection = DTE.ActiveWindow.Selection

            Dim bp As EnvDTE.Breakpoint

            Dim bps As EnvDTE.Breakpoints

            bps = DTE.Debugger.Breakpoints.Add(textSelection.Text)

            'If we have at least one bound breakpoint, go, otherwise just do a step-into.

            If bps.Count > 0 And bps.Item(1).Children.Count > 0 Then

                DTE.Debugger.Go()

            Else

                DTE.Debugger.StepInto()

            End If

            ' Unselect what we selected.

            textSelection = Nothing

            ' Delete the breakpoints we created.

            For Each bp In bps

                bp.Delete()

            Next

        End If

    End Sub

"Why is it that Visual Studio cannot load a symbol file for a binary that was built with the exact same set of source files?" 

Before I answer that, I'll take the question a step further:

"Surely if I build a component twice, consecutively, with no changes to source in-between, I certainly will end up with two identical copies of that component, right?"

Surprisingly, the answer to this question is: "no, that is not necessarily true".  The most obvious reason for this is the fact that an internal time-stamp will be different.  But even disregarding that, the answer is still the same, the actual layout of the code could be different.

The reason is that compiler writers are far more interested in generating correctly functioning code and generating it quickly than ensuring that whatever is generated is laid out identically on your hard drive.  Due to the numerous and varied methods and implementations for optimizing code, it is always possible that one build ended up with a little more time to do something extra or different than another build did.  Thus, the final result could be a different set of bits for what is the same functionality.

Here's a very simple example to demonstrate.  Imagine that the component you're building consists of a function and a variable.

Does it matter whether the resulting file contents looks like this?

0000: MyFunc()
0020: gGlobalVariable

0000: gGlobalVariable
0004: MyFunc()

Functionally, it doesn't matter at all, but for the debugger it's HUGELY important. In fact, getting it wrong can wreak havoc on your debugging session.  In this example, what if you used the symbol file from build #1 to try and determine the value of the global variable when running with the component built by build #2?  The debugger would consult the symbol file and return the value referenced by address 0020.  Unfortunately, the global variable isn't at that address in component build #2.  Rather some some value that makes up the instruction stream for MyFunc() is there.

A debugger depends on knowing what the internal layout of the component is.  So, I can now answer my colleague's original question:

"Because both the Visual Studio and your sanity depends on it."

 

 

PS: In practice, you are not likely to see a difference in compiler/linker output from build to build.  So in theory, it is possible to make use of mismatched symbols.  However, compiler/linker determinism is not guaranteed, our debugger cannot depend on it.  Furthermore, we would much rather not take the support cost of allowing some sort of override.  Therefore, if you find that you absolutely, positively, have to try and use a symbol file that doesn't match you can use WinDbg.  I'll leave getting it to work as an exercise for the reader, since you really, really don't want to do this. :)

Back in my first Debugger tips post I provided some macros that allow you to tag a set of breakpoints with a string so that they can easily be enabled or disabled from the command window.  Well, just for kicks, I decided to expand on that notion a bit and made a set of new macros that can not only do that, but also support multiple labels (the new name for tags) for breakpoints and tracepoints.

Following this description you'll find the source for these macros.  Basically, you can use the instructions provided Idiot's Guide to Creating and Using VS Macros to add these macros to your installation.  After you do that, just run the SetupBPLabels macro, and you'll be able to use the following commands in the command window:

• labelbps - Allows you to add a new label to the current set of enabled breakpoints or tracepoints.  If a label is not provided "label" is used by default.
• enablebps - Allows you to enable all breakpoints that are associated with the supplied label.  If * is provided as the target label or then all breakpoints are enabled regardless of their label.  If no label is provided then any breakpoint without a label will be enabled.
• disablebps - Allows you to disable all breakpoints that are associated with the supplied label.  If * is provided as the target label then all breakpoints are disabled regardless of their label.  If no label is provided then any breakpoint without a label will be disabled.
• clearlabel - Allows you to remove a label from your set of breakpoints.  If * is provided as the target label, then all labels are cleared.  When a label is cleared, it no longer exists, so be careful here.
• listbps - Lists the breakpoints associated with the supplied label.  If no label is supplied, then all breakpoints are listed along with their labels.

I'm not really sure how useful this set of macros will be for you, but it was fun writing them!  Let me know what you think, or if you think there's some improvements that could be made to make them even more useful!  Please note that I am not much of a VB programmer, so if you have suggestions as to how to improve the code, I'm all ears!

Create a one-step operation to attach to a process

If you find your debugging session typically involves attaching to a specific process you can save yourself some time in VS 2005 by creating a macro to do it for you.

1. Choose Tools->Macros->Record Temporary Macro
2. Choose Tools->Attach to Process and choose the process you want to attach to.  You can choose any combination of process, transport, qualifier and code-type.
3. Click the Stop Recording macro toolbar button, or press Ctrl-Shift-R.
4. Choose Tools->Macros->Save Temporary Macro.  The caret will be moved to the Macro Explorer and you'll be prompted to change the name of TemporaryMacro to the name of your choosing. 

Here's an example macro that was generated when I attached to calc.exe with the native engine:

Sub AttachToCalc()
           Try

                  Dim dbg2 As EnvDTE80.Debugger2 = DTE.Debugger

                  Dim trans As EnvDTE80.Transport = dbg2.Transports.Item("Default")

                  Dim dbgeng(1) As EnvDTE80.Engine

                  dbgeng(0) = trans.Engines.Item("Native")

                  Dim proc2 As EnvDTE80.Process2 = dbg2.GetProcesses(trans, "JIMSMACHINE").Item("calc.exe")

                  proc2.Attach2(dbgeng)

           Catch ex As System.Exception

                  MsgBox(ex.Message)

           End Try

End Sub

Now, invoking this macro through the Macro Explorer will cause the exact same attach to whatever program you originally chose!  If you want to make your life even easier you could add this macro to a toolbar by:

1. Choose Tools->Customize
2. Activate the Commands Tab.
3. Scroll down to "Macros" in the Categories list.
4. Drag Macros.MyMacros.RecordingModule.AttachToCalc to a toolbar

You could also create an alias for the macro that you can invoke from the command window as follows:

   alias attcalc Macros.MyMacros.RecordingModule.AttachToCalc

Now to attach to calc, all you have to do is type "attcalc" in the command window.

Of course, the macro that is created for you is a very simple skeleton.  If you'd like you could modify it to do all sorts of other things, like attach to additional processes, or set a breakpoint or whatever! 

You might also want to peruse my Idiot's Guide to Creating and Using VS Macros for more helpful hints.

I'm back from vacation, and have a new found respect for people (mostly US wives/women, I presume) that slave all day over preparing a Thanksgiving meal and then cleaning it all up.  Yep, I did the whole turkey, potatoes, yams, corn, etc. thing this year for me and my kids.  By the end of the day I was completely exhausted.  But it all turned out great!

Anyway onto a new debugging trick.  This one is geared directly at users of native C/C++ debugger in Visual Studio 2005.  It revolves around a little registry tweak you can do to make viewing arrays of objects a little easier using Enhanced DataTips if all you have is pointer to one of the items.  This is not a supported behavior and cannot be adjusted outside of doing this registry change.  As is per usual with any registry tweaking, please be careful -- if you mess up (significantly) you can destroy your entire OS installation.

First, shut down Visual Studio.  Since VS writes a new set of option values to the registry everytime you shut it down, any changes you make to the registry prior to doing so will be lost. 

Now open the registry and navigate to:

HKCU\Software\Microsoft\VisualStudio\8.0\Debugger

You'll see a boatload of debugger options, most of which are addressable under the Tools->Options functionality of VS.  However there is one, OfferArrayExpansion, that is not exposed.  Change it from 0 to 1 and reopen VS.

Now when you activate a DataTip over any pointer to any type and you expand it once, you'll see a message allowing you to expand it as an array.  If you do so, you'll see the first 100 items as if the pointer was really pointing to an array of 100.

Ok this feature has been around for a long time, but it's really almost impossible to discover on your own.  Scott Nonnenberg asked me to remind him out to do this yesterday and I thought HEY good idea for a tip!  Here's what you do:

1. Open the Windows Control Panel
2. If you are in Category View choose "Sounds, Speech, and Audio Devices", then "Change the sound scheme"
3. If you are in Classic View choose "Sounds and Audio Devices", then choose the "Sounds" tab.
4. In the "Program events" listbox scroll down to "Microsoft Development Environment"
5. Change the "Breakpoint Hit" event to the sound of your choice.