Visual Studio 2012 crashes immediately when trying to start or attach to our own native x32 app - by rbrunner7

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.


4
0
Sign in
to vote
ID 764861 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 9/27/2012 12:01:58 AM
Access Restriction Public

Description

The debugger component of Visual Studio 2012 is not able to attach to or start one of our own x32 apps written in MS VC++: When the debugger tries to start our app, Visual Studio crashes immediately, before the very first statement of our app even runs.

Our app itself currently runs without problems on Windows XP through Windows 8. VS2005, VS2008 and VS2010 all can be used to debug our app without any problems.

By debugging VS2012 itself with VS2010 (as far as that is possible for me as an outsider) I saw that the program runs into an internal consistency check when trying to free a heap: The heap is considered "corrupted", and devenv.exe terminates. Switching off DEP that seems to help in some such cases does not change anything, neither does running devenv.exe with /SafeMode switch.

I have described the problem and my own investigations so far with many details here:
http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/a5c0aeb1-4542-405b-a9ee-9dc171995836
Sign in to post a comment.
Posted by andy_excom on 12/1/2012 at 3:08 AM
ive downloaded tha latest msdn vs2012 professional and VS2012 crashes when opening a windows forms project, what is the fix for this..

Posted by rbrunner7 on 10/13/2012 at 1:16 AM
Many thanks for that fast fix!

I checked today, and indeed both the fallback that you describe and switching to proper string resources for our version info in the .RC file neatly solve all problems with debugging using VS2012.
Posted by Microsoft on 10/12/2012 at 4:28 PM
Thank you for the feedback. I have fixed this for an upcoming visual studio release. The root cause is the version string resources in your binary. For some reason, those strings are listed as binary resources in your pe file. This caused the debugger to choke on those resources. To work around this, you can either make sure these are string resources or if you'd like to leave them as is, you can fallback to the legacy debug engine by enabling native edit-n-continue in tools->options->debugger->native->enable native edit-n-continue.

Thanks again for reporting this

The Visual Studio Debugger Team
Posted by Microsoft on 9/27/2012 at 2:39 AM
Thanks for your feedback.

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 Microsoft on 9/27/2012 at 12:51 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)