Microsoft has released updates for Microsoft Visual Studio 2008 SP1 debugger components. These updates mostly address issues that occur with stepping and with hitting breakpoints.
This update is for all versions of Visual Studio 2008 SP1 on both x86 and x64 computers. However, if you use Visual Studio 2008 Standard Edition on a 64-bit operating system, you must install the 64-bit Visual Studio 2008 SP1 Remote Debugger before you apply this update. For information about how to obtain the 64-bit Visual Studio 2008 SP1 Remote Debugger, visit the following Microsoft Web site:
Multi-process and multi-threaded debugger fixesNote
The following descriptions refer to a hypothetical set of processes that are being debugged by a single instance of Visual Studio. When functions are referred, it is assumed that the functions are recursive or that the functions contain loops. These scenarios are not meant to reproduce the problem. Instead, they are provided to help explain the problem.
Breakpoints in parallelized loops are eventually ignored after multiple hits
Breakpoints put in loops or in recursive functions are not hit in all processes at each iteration. Frequently, some processes may pass through many iterations of a loop, ignoring the breakpoint, before a process is stopped. Consider the following scenario:
- You start debugging multiple processes. One of the processes that you are debugging is in a tight loop or it is a recursive function.
- You stop the main thread of the current process (the last process to hit the breakpoint), and then you continue to debug. You repeat this action for each process.
- You restart the threads for each process.
You notice that after several iterations, breakpoints are no longer hit. This behavior is unexpected.
Stopping and starting threads causes breakpoints to be missed
Breakpoints are hit, but they are not visible when you debug multiple processes in the Visual Studio debugger. Consider the following scenario in which you are debugging two processes, Process A and Process B.
- You set a breakpoint on both processes and start debugging. Both breakpoints will be hit.
- You stop the main thread of Process A, you select Process B, and then you press F11 to step into the command one time.
- You restart the main thread of Process A, and then you stop the main thread of Process B. Then, you press F11 to step into the command.
You notice that both processes are at the same line.
You stop the main thread of Process A. No threads should be stopped at this point.
- Press F5 to continue.
The process should finish, and Visual Studio should return to Design mode. However, this does not occur. The processes break again later in the code. Note
If you remove the breakpoints after you press F5 to continue, the debugger runs until it is completed.
Visual Studio may crash when you debug multiple processes at the same time
Visual Studio Debugger may experience a deadlock when you start and then stop a thread and then run to the next breakpoint if multiple processes are being debugged. Consider the following scenario:
- You set breakpoints on three arbitrary variable declarations.
- You start debugging 16 processes.
- You break in to one of the processes, and then you stop its main thread.
- You press F5.
- You repeat steps 3 and 4 until all the processes have hit the breakpoint.
- You start the main threads of all the processes.
- For each process, you delete the first breakpoint, and then you press F5.
- For each process, you repeat steps 3 and 4. All processes should be at the second breakpoint.
- You press F5.
- For each process, you repeat steps 3 and 4.
All processes should reach the third breakpoint, but at least one process may be stuck in the running state.
Stepping over a disabled breakpoint when you debug a native application turns into a "go"
You debug a native application in Visual Studio that contains a disabled breakpoint. When you step the debugger past the disabled breakpoint, the remaining steps are lost, and the application continues to run.
Stepping when you debug a managed multithreaded application can randomly turn into a "go"
When you debug a multithreaded managed application, and you step into one thread while an event occurs with another thread, such as hitting a breakpoint, the step request is lost. And, the application continues to run.
Message Passing Interface (MPI) Debugger Fixes for Visual Studio Editions offering MPI-Plugin Support
Visual Studio crashes when you use the "Step Into" command to start an MPI program
When you use the Step into
command, or press F11, to debug multiple instances of an MPI process, Visual Studio crashes. Or, you receive the following error message:
Microsoft Visual Studio has encountered and internal error
Running the "Step Over" command while you are debugging multiple processes causes a deadlock
If you run the Step Over
command while you are debugging multiple processes, Visual Studio crashes. Consider the following scenario:
- You open a multithreaded application.
- You set a breakpoint on a recursive function call.
- You debug two processes.
- You start debugging. The breakpoint is hit in the first process.
- You press F5. The breakpoint is hit on the second process.
- You stop the main thread of the first process.
- You run the Step Over command on the second process, and then you click Pause.
The operation cannot be completed because it is waiting for the first process. You click Pause to re-enter break mode. The debugger uses a green arrow to indicate the next statement process that it will run when it returns from the function.
- You add a breakpoint in the second process.
- You stop the first process, and then you press F5.
At this point, you expect the debugger to reach the breakpoint in each process. However, both processes are deadlocked inside the function, and the breakpoint that was last added is never hit. In addition, the debugger cannot run to the end of the application.
Breakpoint UI Fix
Disabled breakpoints are not visible after you install Visual Studio 2008 Service Pack 1
If you disable a breakpoint, the breakpoint is no longer hit. Also, the breakpoint is hidden from the left-most editor channel. The disabled breakpoint still exists. It is displayed in the Breakpoints Tool window.
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.
To download this hotfix from the MSDN Code Gallery, visit the following Microsoft Web site:
The MSDN Code Gallery displays the languages for which the hotfix is available. If you do not see your language listed, it is because the Code Gallery resource page is not available for that language.
If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:
You must have Microsoft Visual Studio 2008 SP1 installed to apply this hotfix.
You do not have to restart the computer after you apply this hotfix.
Hotfix replacement information
This hotfix does not replace any other hotfixes.
The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the
tab in the
Date and Time
item in Control Panel.
Collapse this tableExpand this table
|File name||File version||File size||Date||Time||Platform|
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.