Debugger Stepping in mixed mode application is very very slow - by jschroedl

Status : 

  Duplicate<br /><br />
		This item appears to be a duplicate of another existing Connect or internal item.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 751327 Comments
Status Closed Workarounds
Type Bug Repros 14
Opened 6/28/2012 8:31:27 AM
Access Restriction Public


The debugger is painfully slow stepping through mixed mode code in VS2012 RC.

We have a large mixed mode application which is a combination of Native C++, C++/CLI and C# code. When I single-step in a .cpp file built with /clr it takes 5-10 seconds to step over each line.

I do not have any watch variables and only one breakpoint set. My machine is a very capable i5 quad core, 4GB RAM desktop machine.

Sign in to post a comment.
Posted by Microsoft on 4/19/2013 at 12:39 PM

This bug has been identified as a duplicate of the following bug:

The other bug is currently being used to track the issue.

Visual Studio Team
Posted by Marc [MSFT] on 4/17/2013 at 11:50 AM
For Grys73 and Andre Poffo, your issue with update 2 is known and being tracked by this connect bug:

For others, the performance problem appears related to code containing classes with static data members. Closing the watch/locals windows and not hovering any variables should alleviate the problem as it is an issue when trying to evaluate certain expressions. We have a fix that will be included in a future release.

Thanks again for all of the feedback.
Posted by jschroedl on 4/17/2013 at 5:40 AM
@Martin Hammerschmied: Just saw your comment. I don't have #using in any of my /clr files. All the references come through project-level assembly references (only standard CLR assemblies and two Telerik assemblies)
Posted by Grys73 on 4/10/2013 at 4:56 PM
I use mixed debugger to debug sevral projects compiled with /cli option. After Update 2 debugger became unusable. I can't see any class member values, adding this pointer to watch window gets me "error: identifier 'this' out of scope'. Tried with and without Managed C++ compatibility.

In general I only can see simple types variable values from the local stack. Any pointer to struct/class returns 0xsomeaddress {StructName} which cannot be expanded.

Help please..
Posted by André Poffo on 3/12/2013 at 1:27 PM I have exactly the same problem, VS 2012 Update 2 CTP and "Children cannot be evaluated" for all the local variables on C++/CLI Dll.
Posted by Martin Hammerschmied on 2/22/2013 at 3:10 AM
@jschroedl: I'm experiencing the same issues. I have a very large project and compile some of the files with /clr. My observation was that debugging is only slow in clr-files where I use external libraries (#using <blabla.dll>). Do you by any chance use libraries in your clr-code?
Posted by on 2/14/2013 at 12:24 AM
Using Visual Studio 2012 Update 2 CTP it seems that the performance of mixed debugging is much better. I created an "MFC Application" project and enabled C++/CLI.

Debugging performed fine (with the Autos window), although in InitInstance I got "Children cannot be evaluated" for all the local variables.
Posted by RocketRob on 1/22/2013 at 6:14 AM
I have found just this moment that removing the "Autos" panel seems to make a world of difference in the performance issues with debugging my application in VS2012. With this panel closed, performance is *similar* to that which I saw in VS 2010 before I upgraded to 2012 this week. your mileage may vary, of course, but in my one or two tests this morning, the moment I open the Autos panel, everything slows to a crawl in the debugger.

I think it is awfully poor that this isn't being addressed in the short term. All the things that have been done to in many ways force us to use mixed mode code should make this a priority to resolve or at least improve. This issue alone may force me to go back to VS2010.
Posted by jschroedl on 1/21/2013 at 7:54 AM
For future visitors: I followed up with Marc in email and collected etl traces. The slowness in my situation seems to be coming from a large delay while loading symbol information for each expression being evaluated. Simply moving the mouse over a function name can trigger an expression evaluation (even with Locals, Autos, Watch, Call Stack, etc. windows closed).

As of 1/21/2013, there's still no solution offered but MS is on the trail of the issue. Since this is marked Duplicate I suspect they have a possible solution in hand for a future update. I am currenly using VS 2012 RTM with Update 1 so this problem survived the RC phase.
Posted by Marc [MSFT] on 1/3/2013 at 4:39 PM
I think we are out of different things to try to improve perf. At this point, I'd like you to collect a trace of VS so we can try to determine what is so slow. Please email me at so I can provide you the instructions and so you can send the etl trace back.

Posted by jschroedl on 1/2/2013 at 1:20 PM
Deleting the .suo file did not fix the problem.

I did notice a more reproducable step. As soon as I move the mouse pointer over a function name in the editor, the cursor will stop blinking and things are frozen. After a while, it'll start blinking again. In the Output window, I see that a thread stops just before the blinking starts up again...
Posted by Marc [MSFT] on 1/2/2013 at 11:08 AM
Hmm, if you're seeing slow downs in selecting text and opening menus, that may not be the debugger. Do the non-debugger slowdowns occur only when in debug mode and only when doing mixed mode debugging?

Can you try deleting the hidden .suo file? It should be in the same directory as the .sln file and it stores a bunch of user settings about your solution (including pinned variables and old breakpoints that might be causing problems). See if that fixes the problem.

If that doens't work, I can send you the instructions for collecting an etl trace on VS to find out what's causing the slownes (that's assuming VS is busy doing CPU actions).

Posted by jschroedl on 1/2/2013 at 10:43 AM
* Is there a way to find (and clear) any old pinned variables from previous debug sessions?
* Is there a way to disable the popup expression evaluation in the text editor during debugging?

Note that I love and use both these features and turning them off will only increase the frustration but it would help in troubleshooting.
Posted by jschroedl on 1/2/2013 at 10:38 AM
I am also wondering if it's perhaps attempting to evaluate symbols under the mouse pointer as it moves around (to show debug tip with current value). As the mouse passes by it might fall into a pit of slow evaluation.
Posted by jschroedl on 1/2/2013 at 10:34 AM
Having use VS for the day, simply turning off all the tools (including the Call Stack) is not sufficient. I still frequenty have the IDE hang for a few seconds. Ex. I attempt to pull down a top-level menu while I'm at a breakpoint and the IDE is unresponsive for six seconds before the menu open. Same delay can occur in the editor if I try to select some text... very frustruating. My coworkers also run into this. We don't see the problems when debugging Native only.

For example, I'm stopped at a bkpt and just clicked from the browser back to VS to try to find the option you mentioned. Clicking on TOOLS, the IDE hung for about 5 seconds before the menu opened. All I have open is the code editor, Output and Solution. argh.

Disabling the property evaludation and other implicit function evaluation didn't make a difference. IDE still freezes a lot.

Posted by Marc [MSFT] on 1/2/2013 at 10:25 AM
Thanks for the quick reply. It sounds like there is some expression in the autos window that's the culprit. We can't know which expressions might trigger long function evaluation and this appears to be more of a problem in mixed than anywhere else. You can try disabling the setting "Enable property evaluation and other implicit function evaluation" from the tools->options->debugger settings and see if that helps the autos window be faster

If you don't use the autos window, is the experience good enough that you're unblocked and can you use the watch window? While it's not a great solution if you're used to the autos window, it's probably the only workaround available.

Posted by jschroedl on 1/2/2013 at 8:24 AM
After we hit breakpoints in certain managed (C++/CLI) parts of our code we see the busy cursor for 8-15 seconds between each step. I see this for both x86 and x64 (local) debugging -- Mixed mode of course.

The busy cursor will also show periodically for the same 8-15 seconds just by navigating the source code when we're at a break point.

I closed code definition, locals, auto and watch, breakpoints and this helped quite a bit. Note: I only had one simple breakpoint set (no expressions) and I no variables listed in the watch window.

Attempting to pinpoint blame, it looks like the Autos window is clearly one of the culprits.

With only Call Stack, Output and Solution explorer open I do see a delay when the breakpoint is hit but nothing as severe as with the Auto, Watch and Locals present.

Posted by Marc [MSFT] on 12/26/2012 at 1:19 PM

How slow are the steps that you're seeing and is it consistent? Are you stopped in managed or native code at the time of the step (or trying to step across the boundary)? Are you doing x86 or x64 (and are you doing remote) debugging?

We think this is likely the case of some expression taking a long time to evaluate rather than an issue with stepping (interop stepping is slow but not unusably slow). Can you try closing all of the EE windows (locals, watch, autos) and see if that helps? If not, then try closing the callstack window. Please try to isolate down the problem to a paritcular window that's open at the time of the step that causes the slowdown as that can help pinpoint out to workaround this.

Let me know what you find out. Thanks.

Visual Studio Debugger QA Lead
Posted by on 12/2/2012 at 2:12 PM
I have this problem as well, the C++/CLI debugger is effectively useless.
Posted by jschroedl on 7/6/2012 at 5:16 AM
That's correct, we see the problems when debugging in mixed mode (which we do most of the time). Debugging Native-only is faster but obviously not useful in much of our code. Debugging Managed-only was faster than Mixed but again not very useful by itself.

That is very unfortunate that this slowness will not be addressed in the upcoming release as it's quite difficult to debug parts of our application now.
Posted by Marc [MSFT] on 7/5/2012 at 11:05 AM
Hello jschroedl,

Thanks for reporting this problem. You are debugging both managed and native code (ie "mixed"), correct? Do you still see performance problems when the debugger is configured to debug only managed or only native code?

We are aware that the current mixed mode debugging experience has some less than desirable drawbacks. Unfortunately, we have no plans for the VS 2012 release to improve upon this experience. We are working on redesigning the mixed mode experience entirely as we want to fix most of the known issues at one time rather than trying to patch specific problems one at a time. We will have this available in a future release.

If you're seeing issues in pure native and pure managed debugging of a mixed mode application, please reactivate as that experience should be better.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Microsoft on 7/3/2012 at 6:11 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 6/29/2012 at 2:31 AM
Thanks for your feedback. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.
Could you please give us a demo project so that we can conduct further research?

And visual Studio now has an extension called Microsoft Visual Studio 2012 Feedback Tool, available on the VS gallery(
The extension allows you to
1. upload files,
2. collect trace and dump files
3. collect steps while you're repro'ing the issue, as well as
4. SQM logs about VS extensions installed
5. System details (in DxDiag output)
More information on how to use the tool to provide feedback is published here(

Please submit this information to us within 4 business days. We look forward to hearing from you with this information.

Microsoft Visual Studio Connect Support Team
Posted by jschroedl on 6/28/2012 at 8:52 AM
More info. Stepping in Native C++ in the same executable steps very fast. So this looks like a bad bug debugging code built with /clr.
Posted by Microsoft on 6/28/2012 at 8:49 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(