Home Dashboard Directory Help
Search

heap corruption while debugging an unmanaged c++ app by olith6115833


Status: 

Closed
 as Fixed Help for as Fixed


2
0
Sign in
to vote
Type: Bug
ID: 785923
Opened: 4/30/2013 8:06:28 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

start debugging on a breakpoint in my native app, i can step over my bug free code as long as i do not select my auto watch window, which shows me a view local and member variable and a this pointer. If the auto watch window is visible and i step over my code devenv.exe crash with an unhandled win32 exception.
If i debug the devenv.exe process, the debugger detects a heap corruption in nt.dll.
if i choose the local or watch1 window, which shows the exact same list of variables in it, no crash occurs.
This issue is independent from the selected build konfiguration (Debug or Release)
Is this a known bug? Is a Bugfix available? Any suggestions?
Details
Sign in to post a comment.
Posted by olith6115833 on 5/21/2013 at 7:22 AM
I can also reproduce this crash under vs2012 update 3. Let me know, if you are interested in a crash dump with update 3.
Posted by Microsoft on 5/7/2013 at 2:07 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 olith6115833 on 5/3/2013 at 4:50 AM
I have sent the desired data under the given workspace.
Here some additional annotations:
- since i suffer under the known bug 783137, i fallback to VS2012 Update 1 (since i rollback with an Backup that dosen't contain a VS2012 installation, Update 2 was never installed on my developer machine). Nevertheless this crash also happens with Update 2
- the Zip contains the application event log with the two last crashes. Only the first crash which was not started over procdump.exe, creates an event 1001
- the callstack in file devenv2012_Callstack.txt is from the latest crash.
Posted by olith6115833 on 5/3/2013 at 12:16 AM
I am currently quite busy but i try to send you the crash report today. at the latest on weekend.
Posted by Microsoft on 5/2/2013 at 11:26 PM
I am currently standing by for an update from you and would like to know how things are going on your end. If you could get back to me at your earliest convenience with information I request, we will be able to make headway towards a resolution. I look forward to hearing from you.
Posted by Microsoft on 4/30/2013 at 8:02 PM
Thanks for your feedback. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.
    
It may help if you provide us with Bucket ID, a dump file and call stack.

Bucket ID:
1.    Open Event Viewer        
2.    Click on Windows Logs -> Application
3.    Search for a 1001 event that occurred soon after you encountered the crash
4.    The bucket ID should be available in the event details
(there may be multiple 1001 events for any given crash - only one will have the bucket ID)
Dump File and Callstack:
You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx

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

************************************************************
You can use the following workspace to upload the file:
https://sftus.one.microsoft.com/choosetransfer.aspx?key=f75487e4-1650-4283-ba90-ea48cf824428
Password is WEXBO$l0qc66vw9b

Thanks again for your efforts and we look forward to hearing from you.

Microsoft Visual Studio Connect Support Team
Posted by Microsoft on 4/30/2013 at 8: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(http://support.microsoft.com)
Sign in to post a workaround.