Visual Studio Debugger FAQ


Introduction


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:


 










"An authentication error occurred while communicating with the web server. Please see Help for assistance."


"Debugging failed because integrated Windows authentication is not enabled. Please see Help for assistance."


"An authentication error occurred while communicating with the web server. Try disabling 'Digest authentication'. Please see Help for further assistance."


 


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.


 


 


 

Skip to main content