Visual Studio 2012 Debugger crashes attaching to a 32-bit native program RRS feed

  • Question

  • I use Visual Studio Professional 2012 (Version 11.0.50272.1 RTMREL) on Windows 7 Ultimate SP1.

    When I try to attach to a 32-bit native C++ process (an app written by us) for debugging, Visual Studio crashes with the following "problem details":

      Problem Event Name: APPCRASH
      Application Name: devenv.exe
      Application Version: 11.0.50727.1
      Application Timestamp: 5011ecaa
      Fault Module Name: StackHash_49d8
      Fault Module Version: 6.1.7601.17725
      Fault Module Timestamp: 4ec49b8f
      Exception Code: c0000374
      Exception Offset: 000ce6c3
      OS Version: 6.1.7601.
      Locale ID: 2055
      Additional Information 1: 49d8
      Additional Information 2: 49d8b70dda68122a33abe0501cd3f8d0
      Additional Information 3: eb29
      Additional Information 4: eb292b51ca76d41f5a360d510e1043f9

    The Windows Event Viewer shows a corresponding app event, but with no additional useful info as far as I could see.

    I tried the same under Windows 8, with the same result. We already used and use Visual Studio 2005, 2008 and 2010 to debug the same app without any problems.

    The crash occurs after only a few seconds. If I debug the crashing devenv.exe with another Visual Studio, it gives me the info "A heap has been corrupted" and shows a part of "free.c":

    void __cdecl _free_base (void * pBlock)
            int retval = 0;
            if (pBlock == NULL)
            RTCCALLBACK(_RTC_Free_hook, (pBlock, 0));
            retval = HeapFree(_crtheap, 0, pBlock);
            if (retval == 0)
                errno = _get_errno_from_oserr(GetLastError());

    (The "HeapFree" call causes the trouble.)

    I googled for "StackHash" and saw that some people could solve similar problems with Visual Studio crashes by switching of DEP, Data Execution Prevention. I tried, but without luck, neither with listing devenv.exe as an exception for DEP nor by switching off DEP altogether for the OS as a whole with the help of bcdedit.exe: Without DEP, the crash looks identical.

    I checked with SysInternal's ProcMon what devenv.exe does and how far it gets when it tries to attach: Regarding the files of the process to debug, it executes "QueryNameInformationFile" followed by "CreateFile" system calls for the exe itself and the 8 or so referenced dll's, but that's it.

    I see 3 things that could be special with our app:

    a) For historical reasons, our build process uses a quite old version of the C++ compiler and the runtime system - the compiler version is 13.10.3077 from 2002, the exe uses "msvcr71d.dll".

    b) One of the referenced dll's creates a special data segment named .DS that is shared between all process that attach to the dll, a "global" data segment, produced by using the linker option "/SECTION:.SD,RWS"

    c) The dll's referenced by the exe reference each other in somewhat unusual ways - almost each dll references most others.

    Anyway, to me it looks as if the Visual Studio tries to find out info about the exe and the dll's, how they are linked and which system API's they reference, and crashes while doing so.

    Monday, September 24, 2012 2:57 PM


All replies

  • Hi rbrunner7,

    Thank you for posting in the MSDN forum.

    Based on your description, you could debug the same app well when you use the other VS version, am I right? If so, I doubt that it is not related to your project code.

      • To make sure that it is not related to your VS, I suggest you try to run it in SafeMode, check it again.
      • If possible, I suggest you close other processes, for example, the fire-wall, the anti-virus software or others, so we could make sure that they didn’t impact the .dll file to be loaded. You would check your task manager, and make it free.
      • If you have other Environment, you could try to debug it in another PC, check the result.

    This is a blog about how to debug crashes and hangs, if possible, you could check it, and maybe you could get useful information.

    Best Regards,

    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, September 25, 2012 8:13 AM
  • Hello

    Thanks for the fast answer.

    I tried running devenv.exe with the /SafeMode switch: The crash is still there.

    I also tried to start the exe under debugger control (instead of attaching to the already running process) with the help of the /DebugExe switch: Visual Studio also crashes a few seconds after I hit "Run".

    I tried Visual Studio 2012 already on two different PCs, one being a Windows 8 PC with nothing more installed than stock Windows 8 itself, Visual Studio 2012 and our program: The crash is already there.

    The blog entry you mentioned is instructive, but I did not see something that I could try further in my particular case: After all, it is devenv.exe itself that crashes and should be debugged, and I am quite limited here because obviously I don't hold its source :) (I could only give the code snippet in my first post because the crash seems to occur somewhere in the VC runtime system that devenv.exe comprises, and it seems something brought the source of that with it on my PC.)

    I agree with you that the crash has somehow something to do with our app. But for all I know, it's a perfectly legal Windows x32 app using perfectly well-formed DLLs, doing nothing fancy like self-modifying code, generating code, debug itself, using special drivers, modify its image in memory, whatever.

    The app does have 3 (only somewhat) special aspects that I mentioned in my first post, but changing any of them just to try what the reaction of VS2012 would be amounts to a lot of work, and without further hints what the problem could be are only shots into the dark IMHO.

    As I said, I am pretty sure that the attach itself fails: With ProcMon and Visual Studio 2008 which does work with our app I saw that the moment of the attachment probably occurs in the log as an entry called "Load Image" with the exe as path. Visual Studio 2012 does not reach this point of execution.

    Because the program does not need to run to reproduce the crash, I think it would be very easy for somebody of the VS team to reproduce it: I provide the exe and the 8 or so DLLs that it references, that's a few megabytes at most, they try to start it using the /DebugExe switch, (probably) crash. But of course I am aware that we are talking here about quite busy people with a lot of work on their hands...

    Tuesday, September 25, 2012 9:52 AM
  • Hi rbrunner7,

    Sorry for my reply no help.

    I couldn’t make sure whether it is related to your VS debugger tool. If you use the same way to debug other app in VS2012, does it work well? If just the specific app has this issue, I’m afraid that it is not the debugger tool issue. In addition, to make sure that it is not related to the VS settings, try to reset it and debug it again.

    If it is an app written by you, whether you could debug this app opened in the VS? I mean that we could debug it without the “attach to Process”. Maybe we could get some error message when we debug it in the VS.

    In addition, we could break the app when an exception generated, maybe it could help us find more error message, see How to: Break When an Exception is Thrown. Or enable the JIT debugging to get more information, see here.

    A heap has been corrupted

    About the heap corrupted issue, I find the similar question in the VC++ forum, and maybe you could post this issue in the VC++ forum. Not the VC++ expert, maybe you could share me this app, we try to debug it in our PC. If possible, you could share us the detailed steps to debug this app. Thanks for your understanding.


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, September 26, 2012 7:53 AM
  • Well, thanks, but it seems that we produced some misunderstandings. Please allow me to clarify:

    The story started when one of our own programs acted a little strange when running under Windows 8. That problem is already solved, I don't need any help debugging my own program, it's running fine now under Windows 8.

    But: To find out what's the matter with my app and Windows 8, I tried to debug my program with Visual Studio 2012, by attaching to the process and have a look at variables and flow of execution. That did not work, and *that* is the problem here: VS2012 is not able to debug our app in any way, Visual Studio (*not* our app) just immediately crashes.

    No matter whether I try to attach to my program already running, or I try to cold-start it under debugger control: My program does not even *start* to run, VS2012 has already crashed.

    Somehow our app, with itself runs perfectly right now from Windows XP to Windows Server 2008, and can be debugged with VS2010, VS2008 and even VS2005, is *toxic* for VS2012. Too big? DLL's with too many exports? DLL's that reference each other in a way VS2012 does not like? No idea.

    Now, I know already something about what's happening inside VS2012 when it crashes, because I debugged devenv.exe of VS2012 with VS2010 and saw that somehow devenv.exe trashed one of its heaps (again, its heap, *not* the heap of my app, which as I said has no chance to even execute its first statement). But that knowledge does not help me much.

    You may ask: If I can debug my app with VS2010, why does it trouble me that VS2012 can't? Well, that's certainly no immediate urgent problem, but sooner or later we will want to switch to the latest Studio, which is of course 2012 now, but unless debugging is possible, that is out of question.

    And you may agree with me that if there is a perfectly-running harmless native x32 app that reliably crashes VS2012 after the slightest contact, that looks for me like a bug that was introduced somewhere along the way from VS2010 to VS2012.

    Wednesday, September 26, 2012 7:53 PM
  • Hi rbrunner7,

    Glad to receive your reply.

    Since it is hard for me to repro this issue, I’m afraid that I didn’t have a good idea, to help you resolve this issue as soon as possible, if possible, you could submit this feedback to Microsoft Connect feedback portal: http://connect.microsoft.com, Microsoft engineers will evaluate them seriously. If this issue is urgent, please contact support at http://support.microsoft.com. If you submit this feedback, you could post the link here, I will vote it. Thanks for your understanding.


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, September 27, 2012 2:31 AM
  • Many thanks for your prompt support, Jack.

    I followed your recommendation and posted a Connect feedback here:


    Thursday, September 27, 2012 7:49 AM
  • Vote it!

    Best Regards,

    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, September 27, 2012 9:25 AM
  • The friendly people from the Visual Studio Debugger Team already found the problem and showed me how I can avoid and/or correct it:


    The root cause of all the trouble was a many-years-old small mistake in a VERSIONINFO structure in the .RC file for our app concerning resources with version info that somehow never mattered so far but now managed to crash VS2012.

    Thanks to all involved for the fast problem solution!

    Saturday, October 13, 2012 8:23 AM
  • Hi....

    Im wncountering the same problem with VS2012...

    Pls let me know is there any workaround found for this issue and is there any patch/fix we avialable for this...

    Pls help.. im breaking my  head like anything because of this issue...

    Appreciate your help...


    Monday, February 4, 2013 2:03 PM
  • I started getting this issue when I installed VS2013 alongside VS2012. I did because MS said it was safe and there were no issues. They were wrong. I can no longer debug applications, this is critical for development. I've since uninstalled 2013, run repair on 2012 and it still doesn't work.
    Tuesday, October 29, 2013 10:40 AM