Visual Studio debugger throws AccessViolationException - by Paul gmed

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.


30
0
Sign in
to vote
ID 819552 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 2/19/2014 4:19:12 PM
Access Restriction Public

Description

Certain code patterns are throwing an AccessViolationException in visual studio 2013 while debugging an application compiles for all CPU (preferred 32 bit unchecked) or x64 and stepping in or over that code
Sign in to post a comment.
Posted by AlchemistMatt on 11/24/2014 at 2:25 PM
I was hit with this bug after installing Visual Studio 2013 Update 4 onto a 64 bit Windows 7 system that already had VS 2013 with Update 3. The update installed successfully, but when I tried to debug an AnyCPU project compiled with .NET Framework 4, I could not step into a MustInherit (abstract) function defined in a derived class. After installing Microsoft .NET Framework 4.5.2 (and rebooting), debugging via stepping worked again.
Posted by Xavier Deryckere on 8/12/2014 at 1:48 AM
Worked like a charm!

I had the issue on Windows 7: Trying to step into a { virtual function / with a parameter / returning a value / Any CPU } with VS 2013 => AccessViolationException.

I just installed .NET 4.5.2 via the link provided, and after the reboot everything is back to normal, I can debug normally.
Posted by Microsoft on 8/4/2014 at 10:08 AM
Hi Mathew,

So the fix from the .NET Team addresses a problem with the managed return values feature which could cause the debugger to corrupt the target process while stepping. If you are seeing the AccessViolationException in another scenario, I would suggest creating a new bug, as your bug is unrelated to this one.

If you are seeing the problem while stepping, first make sure that you have installed .NET Framework 4.5.2. Currently at least, my understanding is that it isn't automatically being pushed to computers, so you will want to install it by hand.

If after installing 4.5.2 you are still seeing the problem, first try to use the work around that I posted to the work around section. If the bug repros even with the work around applied, then you must be running into a new issue, so again I would suggest opening a new bug.

If the work around makes the problem go away, and it still reproduces without the work around on the latest .NET Framework, then we will need more information to try and understand what is going on. Do you by chance have a project that you could send us that demonstrated the problem? For example, by taking out a bit of source code from around where you are seeing it?

Thanks!
Gregg
Posted by matthew1471 on 8/3/2014 at 12:17 PM
Sorry but this issue still seems to occur for me on Windows 8.1.. the same code runs fine on 2 Windows 7 machines.

System.AccessViolationException was unhandled
Message: An unhandled exception of type 'System.AccessViolationException' occurred in System.Windows.Forms.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

The call stack is not copyable but contains Forms.Control.SendMessage before moving to Managed to Native Transition. I have tried Visual Studio 2013 Ultimate Update 3 RC but this is no better either.

The workaround didn't work for me either.
Posted by matthew1471 on 8/3/2014 at 12:00 PM
Sorry but this issue still seems to occur for me on Windows 8.1.. the same code runs fine on 2 Windows 7 machines.

System.AccessViolationException was unhandled
Message: An unhandled exception of type 'System.AccessViolationException' occurred in System.Windows.Forms.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

The call stack is not copyable but contains Forms.Control.SendMessage before moving to Managed to Native Transition. I have tried Visual Studio 2013 Ultimate Update 3 RC but this is no better either.

The workaround didn't work for me either.
Posted by Microsoft on 7/17/2014 at 10:35 AM
Hi,

Just letting you know that .NET 4.5.2 has shipped and is available to download: http://www.microsoft.com/en-us/download/details.aspx?id=42642

This will contain the fix and you won’t have to use workarounds anymore!

Thanks!
Maria Ghiondea
Visual Studio Debugger
Posted by Microsoft on 4/10/2014 at 5:01 PM
Thanks Afshin,

Can you step over a method that, for example, returns a string, and look in the 'Autos' window to confirm that managed return values are disabled? Assuming that the work around is applied, if the work around didn't help, then the bug you are running into is a different underlying issue then the issue that Paul originally filed.

If this is the case, can you first try deleting your 'suo' file and restarting VS (this is a hidden file next to your sln file that contains various settings for your solution, such as the set of breakpoints you have set)?

Assuming that this doesn't fix the problem, can you open a new Connect bug to help trouble shoot this. If you can come up with a little app that you can share (or your full app if it is something sharable) that reliably reproduces the problem that this will make it far easier to troubleshoot. Otherwise we can try and work with you to understand what might be happening.

Thanks,
Gregg
Posted by Afshin_Jafari on 4/10/2014 at 3:11 PM
Hi Gregg,
I have the same exact exception in VS2013 Premium on Win 8.1
Applied your workaround and even after restarting still getting the exception.

In my case if I run the output 'exe' file and attach to it after running it does not throw the exception (even without the provided workaround).
Posted by Microsoft on 4/7/2014 at 10:08 AM
Thanks Mark. While we wait for an opportunity for a new .NET Framework release which has the fix for this issue, it is possible to work around the issue by disabling the Managed return value feature. I have posted instructions for doing this to the 'Workarounds' section.

I hope this helps,
Gregg Miskelly
Visual Studio Debugger Team
Posted by Mark Milbourne on 4/5/2014 at 3:29 PM
Is there any movement on this problem. I'm seeing this on a daily basis.

Where I'll get an AccessViolation while stepping over code, but if I put a break point after it and hit run the exception doesn't happen. This is a workaround for me for now. But I'll probably have to go back to using 2012 until this can be resolved.
Posted by Microsoft on 3/7/2014 at 4:37 PM
I'm Darcy Thomas, a PM on the CLR Diagnostics Team. Thanks for making us aware of this issue. We have resolved the issue. The fix will be available as part of our next major public release.
Posted by Microsoft on 2/19/2014 at 4:53 PM
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)