none
JIT debugging 32-bit app crashing with access violation

    Question

  • Got a new development machine with Win7 64-bit, VS 2010, using just-in-time debugging for 32-bit applications is crashing the application with Access violation. Debugging a x64 application work fine without any such issues.

    For 32-bit apps, if I Start Debugging this application within (the F5 option), it works fine, or if I use the "Attach to Process" option, it still works fine.

    But if I use DebugBreak() to break into the code, or purposely write a divide-by-zero case in the code,  then the JIT debugger window is launched (as expected) and it does let me get into the code, but as soon as I press continue, it will crash before reaching the breakpoint on the very next line.

    The following simple piece of code reproduces this issue.

    int main()
    {
    	DebugBreak();
    	return 0;
    }
    
    

    What could be going wrong there? How can I resolve this issue?

    Thanks,
    Shoaib.
    • Moved by Helen Zhao Monday, December 26, 2011 6:15 AM (From:Visual C++ General)
    Friday, December 23, 2011 9:22 PM

Answers

  • Sorry for being out of the picture for such a long period. In the meanwhile, I have been able to reproduce this issue on a few systems, while around equally not on a few others. Also, I was able to reproduce this bug using WinDbg as well, so it left the scope of Visual Studio Debugger that this forum belongs to, in my opinion.

    I was never able to resolve this issue, well, until today, when I came across this blog post: www.os2museum.com/wp/?p=960. The blog posting contains a detailed explanation of what the problem is, and a workaround solution, that I am including here, as follows.

    Before mentioning the solution, I would quote from the post that, "The issue is 100% reproducible… but only on some systems. The ingredients are: 64-bit Windows 7 SP1, a 32-bit process being debugged, and a recent CPU.". In my case, I have a Sandy Bridge based processor, and I believe was the case with most other systems where I could reproduce it.

    The issue is with AVX support that is enabled by default on Windows 7 SP1, as per MSDN: msdn.microsoft.com/en-us/library/ff919571.aspx.

    The big good news that I found at this post is that, there's a documented way to disable AVX here: support.microsoft.com/kb/2568088. So, this could be used as a workaround to this problem, by running the following command from an elevated command prompt to disable AVX:

        bcdedit /set xsavedisable 1

    Now further quoting from the post.."The problem is definitely a bug in Windows 7 SP1 on AVX-enabled systems; however, it seems to be specific to the debug support in the WoW64 component.".

    I also believe this is certainly a bug. I tried reporting it on Microsoft Connect but couldn't find an appropriate category to report it, given that this should probably be regarded as a bug in Windows. Any suggestion from others regarding this?

    Regards,
    Shoaib.

    Monday, August 06, 2012 2:54 AM

All replies

  • Hi Shoaib,
     
    According to your description, I'd like to move this thread to "Visual Studio Debugger" forum for better support where more experts live.
     
    Thanks for your understanding and active participation in the MSDN Forum.
    Best regards,
    Helen Zhao [MSFT]
    MSDN Community Support | Feedback to us
    Monday, December 26, 2011 6:15 AM
  • Hi Shoaib,

     

    Thank you for posting in the MSDN forum.

     

    Did you get any error or warning messages?

     

    Based on your description, it means that if you use the “DebugBreak ()” with Debugging the x64 application, it worked fine, but if you use it with Debugging the x32 application (The same codes as the x64 application), it has this issue.

     

    If I have misunderstood anything, make free feel to let us know.

     

    1.       We can use the “System.Diagnostics.Debugger.Break()” to break in a specific place, so change the code “DebugBreak ()” to “System.Diagnostics.Debugger.Break()”. Check it.

    2.       A useful thread, Gregg gave some suggestions about JIT debugging for native32-bit and 64-bit programs, see http://social.msdn.microsoft.com/Forums/en-AU/vsdebug/thread/4c4843f6-aa0a-43d9-80ca-f19b14828e0c

     

    If no helps, please attach your Visual Studio project, you can upload it to the sky driver, and then share the download link in your post. We will download and check it. If you get any messages, please post it in your reply.

    If there's any concern, please feel free to let us know.

     

    Best Regards,

     


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

    Monday, December 26, 2011 11:00 AM
  • Hi Shoaib,

    I am writing to check the status of the issue on your side.
    What about this problem now?
    Would you mind letting us know the result of the suggestion?

    Best Regards,

     


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us
    Wednesday, December 28, 2011 4:34 AM
  • Hi Jack,

    Thanks a lot for your reply and really sorry for not having responded back earlier. I was attempting a few things, including checking with few other systems running Win6 64-bit before replying.

    I will be posting a reply in a short while. I don't think we are exactly at the same page here. Let me try to explain the issue in detail. Please bear with me for a very long posting here.

    Thanks a lot for your help!

    Shoaib.

    Wednesday, December 28, 2011 2:58 PM
  • Hi Jack,

    Thanks a lot for your reply and really sorry for not having responded back earlier.

    Firstly, as far as I know, using "System.Diagnostics.Debugger.Break()" is not an option available in native programs and can only be used in .NET programs, but yes, it has the same behavior that the native function "DebugBreak()" has in native apps. Just to verify though, I did write a .NET program using System.Diagnostics.Debugger.Break() and it works fine without any issues, in all case whether the target is set to "x86", "x64" or "Any CPU". But off course, the Managed environment is a whole other story and most of things there can't apply to native apps.

    Secondly, thanks for directing me to Gregg's post. I had done my share of searching the forums and had saw that post already but it's not the case here. I am well aware of what Gregg is talking about, but that only controls whether JIT debugger window will be launched automatically or not. I have the registry values in both the main and Wow6432Node node set to the same value (that I prefer keeping to "1" on my dev machine) and this issue reproduces in both cases as well, whether Auto is set to "0" or "1".

    I don't think we are exactly at the same page here, so let me try to explain it in detail. Please bear with me for this very long posting here :)

    I don't believe it's an issue in the code. I have been using it for years, since the time of VC6, and as of now, I can use it fine on 32-bit variants of Win XP, Vista and Win7, myself, and I believe it's supposed to work on Win7 64-bit as well. It's probably something in the system environment, either it's a real issue or it's something that needs to be done in the system that I am unaware of.

    Yes, I do receive an error message, that's the "0xC0000005: Access Violation" one.

    What further confuses me here is that debugging does indeed work fine using some of the other options. To review them, please consider the following:

    (1) When I start the debugger with the IDE, using the "Start Debugging" option or pressing F5, it works fine.
    (2) If I put in a shhort "Sleep" in the program, and then use the "Attach to Process" option, the debugger is attached and the program then continues on to debugging fine.
    (3) If I edit the registry to have the program in Image File Execution Options to launch the debugger automatically on appplication start-up (explained in MSDN here: How to: Launch the Debugger), it still works fine.
    (4) If I use "DebugBreak()" to break into the code, it would launch the JIT debugger window, and let me break into the code successfully, but as soon as I would press "Continue", rather than jumping on the next break-point, it would crash with the "0xC0000005: Access Violation" execption message.
    (5) If I purposely code in some condition (like divide-by-zero) that would trigger an exception, again it would launch the JIT debugger window, and let me break into the code, but rather than breaking and pointing at line of code, it would just crash.

    The common thing in the cases of (4) and (5) is that, I believe both would fall into the category of "Post-Mortem Debugging" that's not working in the expected manner. And as said in my original post, that's with the 32-bit or "Win32" programs only. I don't have any current needs for using it in 64-bit programs, but yes, it's working fine when using with "x64" program.

    So why is it throwing that Access Violation error?

    The user I am logged-on with is among the Administrators and I even have UAC completely off (set to Never Notify).

    I have also tried turning off DEP (Data Execution Prevention) off using BCDedit (though I am not sure if that has the intended affect in a 64-bit environment or not) but that doesn't solve the issue.

    Lastly, and probably most importantly, I tried with my few of co-workers' machines with Win 64-bit: I can reproduce the issue at two other machine, but interestingly it works on one other one. The only difference there is that he is using the built-in Administrator and everything including Visual Studio was installed with it. I have tried using the built-in Administrator as well but it still doesn't work but I have installed everything with my own user. So, I wonder if that has something to do with it?

    If not, what do you think could be the problem here? Other than that case, I have tried everything I could think of. What else do you think I should try that will resolve this issue?

    Thanks a lot for your reply again. I would be awaiting your reply as currently that's the only thing offering me any hope in resolving this issue, that's keeping me from shifting to this dev machine :)

    Thanks,
    Shoaib.

    P.S:
    I can attach my solution and post the link but there's nothing special in that code and it's a clean newly created project with just one line addition of the "DebugBreak()" function call that reproduces the issue. In VS2010, I can reproduce this by if just opening the New Project wizard, expand the Visual C++ (could be under Other Languages), choose Win32 and then choose Win32 Console Application, and choose to Finish the wizard with the the default options, and then, replace the contents of the generated code file with the following:

    #include "stdafx.h"
    #include "windows.h"
    
    int main()
    {
        DebugBreak();
        return 0;
    }
    
    

    Please let me know if you still need me to attach the code and share it on SkyDrive and I will do it.
    Wednesday, December 28, 2011 4:31 PM
  • How about just debug the code in Visual Studio for your code?

    Since I found that the application will be continue fine if there's a debugger attached on this process before it hit the DebugBreak() function.

    And I also cannot clear about the phenomenon when it crash or hang, can you share us a test video so that we can ensure if we're on the right research direction.

    Maybe you can try to add your current test account into the Administrators Group, to test if this configuration affect the test:

    Run->gpedit.msc

    Local Computer Policy-> Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> User Rights Assignment

    [Debug Programs]

    If there's any concern, please feel free to let me know.

    Best wishes,


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Thursday, December 29, 2011 9:12 AM
  • Thanks for your reply Mike. Please find my comments/replies inline below.

    How about just debug the code in Visual Studio for your code?
    Off course I can debug the code by starting in Visual Studio. But that's not possible, or at least not ideal, for certain types of apps. e.g., a Service, or a process that's invoked by another process on some condition. I am very used to using it in my day-to-day work.

    Besides that, the case (5) is also not working, for apparently the same reason. When you are debugging a crash scenario, at times that can help give a good insight.

    Since I found that the application will be continue fine if there's a debugger attached on this process before it hit the DebugBreak() function.

    Yes I can confirm that as well. In all three cases (1), (2) and (3) that work fine, if the debugger is attached already, a call to DebugBreak() would trigger another breakpoint and continue to work fine as well. Oh and sorry for not having mentioned it earlier, that I am using it when starting without debugging (or starting the program directly).

    Here I intend to use DebugBreak() itself to interrupt the running program and allowing to attach the debugger to the process, which is the way it is supposed to work. In many practical cases, some of which I just mentioned, its not ideal to have the debugger attached already and using the DebugBreak() is the best choice, at least for me.

    And well, that's what's confusing me more here. If all these cases work, why isn't DebugBreak() working in the way it should?

    And I also cannot clear about the phenomenon when it crash or hang, can you share us a test video so that we can ensure if we're on the right research direction.
    Not hanging, just crashing. I'll try to record a video and post it on weekend.

    Maybe you can try to add your current test account into the Administrators Group, to test if this configuration affect the test:

    Quoting from my previous post: "The user I am logged-on with is among the Administrators and I even have UAC completely off (set to Never Notify)". Except the built-in "Administrator" user (that's disabled by default) itself, I don't think this user account could be given any more privileges that it already has. Or could it be? Also, if that would be the case, then debugging x64 programs shouldn't have worked either, in my opinion. Please let me know if I am missing something here.

    My most probable place of doubt is going doubt towards the Wow64 subsystem or its interaction with the debugger, where the problem lies.

    If there's any concern, please feel free to let me know.

    No concerns except getting it to work :) Thanks for your reply Mike. I appreciate your and Jack's help a lot. I hope we'll able to figure out what the problem is and get it work in the expected manner soon.

    Regards,
    Shoaib.

    Thursday, December 29, 2011 11:41 AM
  • Ok, now I think we can ensure if this DebugBreak() function can work in your computer by just create a common application.

    I found in my Windows 7 x64 system, I need to run the application with "Run as administrator", and choose "New instance of Visual Studio 2010". After these steps, I can debug it.

    And please do not forget to config the registry: http://msdn.microsoft.com/en-us/library/a329t4ed(v=VS.100).aspx

    If the problem is also cannot solved, then it maybe helpful to share us your test screen video.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Friday, December 30, 2011 7:46 AM
  • Hi Mike,

    I am an Administrator and I have UAC off (set to Never Notify), so as far as I know, that brings on all the rights that "Run as administrator" can.

    The link you have provided is the same one in my previous in the case (3) and quoting from my that post, "If I edit the registry to have the program in Image File Execution Options to launch the debugger automatically on appplication start-up (explained in MSDN here: How to: Launch the Debugger), it still works fine.". So, besides that it does work fine, you actually won't even need use the DebugBreak() function anywhere in the code and the application automatically launched the debugger when the application starts.

    I'm not sure where I am lacking to explain it to get both of us at the same page.

    It's nothing too complex and you can think of DebugBreak() as nothing but the native API equivalent (in terms of behavior) of the .NET library System.Diagnostics.Debugger.Break() function.

    Please try the following Please follow the following:

    Firstly, please do make sure "vsjitdebugger.exe" is specified in the following registry keys:
        HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
        HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

    Also, make sure that the "Problem Reporting Settings" (in Action Center) is configired with "Each time a problem occurs, ask me before checking for solutions." option.

    Then,

    1. Create a new Win32 Console Application, and choose to Finish with the the default options.
    2. Add "#include <windows.h>" and call "DebugBreak()" as the first line of the code before "return 0" and set the break-point (press F9) on "return 0" line itself.
    3. Choose to Start without debugging (press Ctrl+F5) or start the application directly.
    4. You will be presented with Problem Reporting dialog where you need to choose "Debug the program" option and then the JIT debugger window will be invoked again where you can choose "New instance of Visual Studio 2010".
    5. The code will open and you will be presented with the dialog to "Break" and "Continue" where you can choose to "Continue" and if everything goes fine, the debugger will take you to the next break-point that will be the "return 0" line.

    This is the way it it supposed to work which it does in some systems. And this also happens to be the point when I press "Continue" that it would crash.

    Hope you will be able to figure out what I am trying to do without the need of the test video, and then we can proceed further to identify what's causing this issue.

    Thanks,
    Shoaib.
    Friday, December 30, 2011 12:10 PM
  • I saw you wrote it works fine for a x64 target platform project, just failed for the win32 target, right?

    Then what the exception code here for your x64 and win32 tests:

    I saw you provide the code: "0xC0000005: Access Violation", can you help me to clarify the details information for each of the two different tests?

    The steps you provided works in my side, so I think maybe we can try to know what is the difference between the two tests in your side.And then see if we can get the clues, instead of don't know the direction.

    You said it crashed when you click on "Continue", did you mean that both the new instance Visual Studio 2010 and your application were all crashed and shutdown?

    Then can you get any error message in the event viewer?

    But what the result if you click on "Break"?

    And since the breakpoint will not keep there in the new instance of Visual Studio 2010 in my side, so we will need to use "Break", then insert a breakpoint to the "return 0;" line, then it will hit as well.

    I have a request, I hope you can help me to log for each information where(application, Visual Studio or system, and so on) and when you got it. It maybe helpful to tell us which step we need to think and do next round for this thread.

     

    If there's any concern, please feel free to let me know.

    Best wishes,


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Monday, January 02, 2012 7:11 AM
  • Thanks for your reply Mike.

    As far as the code and the project configurations are concerned, I can confirm that there's no difference between the two tests. The x64 environments could be involving some different paths through the system libraries, but what's even more confusing is why debugging Win32 programs is working when started within the IDE or when used with "Attached to Process" mechanism, yet it's not working in the mentioned cases.

    No, only that program crashes, not VS itself. And sorry for that one wrong step there, I usually choose that running instance of VS where my program is already opened rather than choosing "New instance of Visual Studio 2010, so in that case, the breakpoints will keep at their locations.

    Well, I guess I should say that glad to know that it's working on your system, although if the issue had reproduced on your system, I would certainly have been much more glad :)

    Please allow me a couple of days and I will record a video and show you the issue.

    Thanks,
    Shoaib.

    Wednesday, January 04, 2012 3:01 AM
  • You're welcome!

    I also would like the issue is also occurring in my side, so that we can look into the whole System, we can check everywhere :).

    I will continue to follow you once got your updates.

    Best wishes,


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Wednesday, January 04, 2012 10:12 AM
  • Any updates on this one?

    I have the same issue.

    Inserting a 'DebugBreak()' in a 32 bit app running on a 64bit OS triggers the bteak, brings up the debugger (windbg in my case), but you can't continue.

    Hitting f10 or f5 just brings up the access violation, thus rendering this approach useless.

    Cheers,

    OK, here's my summary:
    DebugBreak() in a 32 bit app will be caught and can be continued by x86 windbg (only, havn't tried VS of any kind yet, since that is no option).

    DebugBreaks() in x64 apps wil be caught but cannot be continued by either x64 windbg, x86 windbg, vs2010, VS2088

    DebugBreak in x64 is not available anymore, or needs some undocumented tweaking of the debuggers!

    Note :

    editing IFEO to let apps run under debugger isn't really useful under certain circumstances.

    If Debugbreak() isn't usable anymore, it should be documented somewhere.

    Cheers,

    • Edited by robinmi Monday, March 05, 2012 10:21 PM Update:
    Monday, March 05, 2012 3:47 PM
  • I'm also seeing this exact same issue.  DebugBreak() is called by my application when -break is specified as a command line argument.  This argument is used as a convenient way to get to the debugger.  The call to DebugBreak() works well on 32-bit XP machines but won't allow the debugger to continue on 64-bit Windows 7 machines.

    I've discovered a workaround by using vsjitdebugger.exe to launch my application.  This allows the application to be used from the command line but runs it within the Visual Studio debugger.  The command looks as follows.

    C:\Windows\SysWOW64\vsjitdebugger.exe myapp.exe -break [other arguments]

    Saturday, March 31, 2012 3:24 AM
  • Sorry for being out of the picture for such a long period. In the meanwhile, I have been able to reproduce this issue on a few systems, while around equally not on a few others. Also, I was able to reproduce this bug using WinDbg as well, so it left the scope of Visual Studio Debugger that this forum belongs to, in my opinion.

    I was never able to resolve this issue, well, until today, when I came across this blog post: www.os2museum.com/wp/?p=960. The blog posting contains a detailed explanation of what the problem is, and a workaround solution, that I am including here, as follows.

    Before mentioning the solution, I would quote from the post that, "The issue is 100% reproducible… but only on some systems. The ingredients are: 64-bit Windows 7 SP1, a 32-bit process being debugged, and a recent CPU.". In my case, I have a Sandy Bridge based processor, and I believe was the case with most other systems where I could reproduce it.

    The issue is with AVX support that is enabled by default on Windows 7 SP1, as per MSDN: msdn.microsoft.com/en-us/library/ff919571.aspx.

    The big good news that I found at this post is that, there's a documented way to disable AVX here: support.microsoft.com/kb/2568088. So, this could be used as a workaround to this problem, by running the following command from an elevated command prompt to disable AVX:

        bcdedit /set xsavedisable 1

    Now further quoting from the post.."The problem is definitely a bug in Windows 7 SP1 on AVX-enabled systems; however, it seems to be specific to the debug support in the WoW64 component.".

    I also believe this is certainly a bug. I tried reporting it on Microsoft Connect but couldn't find an appropriate category to report it, given that this should probably be regarded as a bug in Windows. Any suggestion from others regarding this?

    Regards,
    Shoaib.

    Monday, August 06, 2012 2:54 AM
  • I think this is the only place for submitting this kind issue: https://connect.microsoft.com/VisualStudio/feedback/CreateFeedbackForm.aspx?FeedbackFormConfigurationID=5303&FeedbackType=1

    I'm glad to hear that you got a workaround to make it work, and thanks for sharing it here!

    Good day!

     

    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us

    Monday, August 06, 2012 6:38 AM