Debugger hangs in managed code in mixed-mode C++ app - by small_mountain_0705

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<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 774026 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 12/11/2012 7:07:01 AM
Access Restriction Public


Ours is a very large, mixed mode (managed/native) C++ application.  Debugging with VS 2012, we've noticed some places in our managed code where, when our breakpoint in that code is hit, VS 2012 basically hangs for one minute or more.  When control actually does come back to the debugger, and I step again, the 1-minute-plus hang occurs again.  Looking in Task Manager, devenv.exe has one of my four cores locked up at 25%.  Tried it on my co-worker's machine, same exact problem.  Tried moving the function to a different .cpp file, made no difference.

This is a regression because VS 2010 can step through this code with no hesitation whatsoever.

Note that we have a lot of managed code in which we can set breakpoints, and VS still stop and step just fine, no hang.  It's not at all clear what the difference is, but all the cases I've seen have occurred in the context of InitInstance().

My co-worker had the brilliant idea of attaching another instance of Visual Studio to the Visual Studio instance that was hung, breaking, and trying to get some call stacks.  Oddly, on his machine, the process that was locked up was msvsmon.exe, as though he was remote debugging, which he was not.  For me, the process is devenv.exe.  We grabbed one call stack from his machine and I grabbed several from my machine (let it run for awhile, break, get a call stack, go for a while, break and get another call stack, etc.).  I will attach those after submitting this.  I will also attach the C++ code for the function where stepping is performing so badly in case it helps.

We do have update 1 of VS 2012.
Sign in to post a comment.
Posted by Deon [MSFT] on 4/29/2014 at 12:31 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from:
Posted by Marc [MSFT] on 6/26/2013 at 2:53 PM
Please try the final release of VS Update 3 to see if this fixes the stepping performance issue you were seeing. The original fix in CTP 1 only fixed native debugging but the final release should fix mixed mode debuggging as well.

Update 3 download:

Visual Studio Team
Posted by Shane Powser on 5/9/2013 at 10:29 AM
I too am trying to submit recorded replication steps and the feedback tool is not able to upload it. Please advise on how to proceed.
Posted by ShanePowser on 5/9/2013 at 9:55 AM
Just installed and tested with Update 3 RC and it does not appear to be fixed for us. Still seeing up to 5 second delays between steps with Locals/Watch turned off and not hovering on variables.
Posted by Microsoft on 4/19/2013 at 12:52 PM
The fix for this is included in Visual Studio Update 3 CTP 1, which is now available for testing:

Visual Studio Team
Posted by RocketRob on 4/11/2013 at 8:01 AM
It would definitely be a nice thing if this were fixed in the short term rather than taking a long time. This issue is seriously impacting developer productivity.
Posted by YongKang [MSFT] on 1/17/2013 at 3:04 PM

We have identified the issue and got a fix for the problem. It hasn't been decided whether the fix will be included in our next VS 2012 Update, but it will definitely be included in our next major release.

Thank you very much for taking the time to send us the report.

YongKang Zhu
VC++ CodeGen and Tools
Posted by Microsoft on 12/17/2012 at 3:59 AM
Thanks for your update. We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by small_mountain_0705 on 12/14/2012 at 1:04 PM
Tried the transfer web site, seemed to work but hung at the end. Since the zipped dump file was under 500MB, I tried just uploaded that here, and it got to 100% and then just hung. You guys aren't making this easy.
Posted by Microsoft on 12/14/2012 at 1:23 AM
Thanks for your response. You can use the following workspace to upload the file:
Password: aKUsg]Fk{epF

Please zip the file and use "FeedbackID-774026" as prefix of the file name.

Microsoft Visual Studio Connect Support Team
Posted by small_mountain_0705 on 12/13/2012 at 11:02 AM
I figured out how to get a dump from VS 2012 outside of the feedback tool (Debug > Save Dump As...), but the resulting dump file is 1GB. The Attach Files function here says 500 MB is the maximum attachment. So trying to attach the minidump failed. If you want it, let me know a different way to get it to you.

And, get this. The Attach Files part of Connect obviously knew right away that the attachment was too large, because it showed the size right in the progress bar, but it still went through the laborious process of trying to upload it, telling me it would take 30 minutes. When I got back from lunch, all that the connect to said was that attaching the file failed. Didn't say why. I think you guys need to try harder to find better summer students to be in charge of the Connect site this year.
Posted by small_mountain_0705 on 12/12/2012 at 7:14 AM
Somebody needs to debug the Microsoft Visual Studio 2012 Feedback Tool, because it has been a complete fail for me. I have already submitted connect issue #773080 on one problem, and it has failed me again here. I have attached the error message I get when I try to upload the mini-dump. On the plus side, I was able to follow the instructions to use a second instance of VS to create a mini-dump on the instance that is hanging. Is there a way for me to get at the mini dump that the tool created so I can manually attach it? I also looked for a way to take a mini-dump without the VSFT, but Debug > Save Minidump As... menu item has disappeared in VS 2012. When I ask VS 2012 for help saving a mini-dump, it shows me information for VS 2005. None of this is inspiring confidence.

If you can figure out another way for me to get you the minidump, I'll give it a go.
Posted by Microsoft on 12/11/2012 at 10:05 PM
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 dump file so that we can conduct further research?

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)

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 small_mountain_0705 on 12/11/2012 at 8:12 AM
I have attached two files:

* a ZIP file that contains a text file showing call stacks from attaching a debugger to Visual Studio while it was hanging. That might be useful to you. The ZIP file also contains the source code for the function in our application where having the breakpoint caused the hang. But don't get too caught up in the details of that source code - I reduced the code in that function to one line that just printed a message to our log and the hang did not change.

* I have now added a PNG file showing the call stack within the running application at the point of the hang. It is very shallow, just a call down from InitInstance.
Posted by Microsoft on 12/11/2012 at 7:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(