Home Dashboard Directory Help

Visual Studio debugger throws AccessViolationException by Paul gmed


 as Fixed Help for as Fixed

Sign in
to vote
Type: Bug
ID: 819552
Opened: 2/19/2014 4:19:12 PM
Access Restriction: Public
User(s) can reproduce this bug


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 Microsoft on 7/17/2014 at 10:35 AM

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!

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.

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)
Sign in to post a workaround.
Posted by Microsoft on 4/7/2014 at 10:05 AM
This issue is caused by the code which gathers return values. It is possible to work around the issue by disabling Managed return values.

1. Go to the System properties (Win8: WinKey+X, select ‘System’, Win7: Open ‘Properties’ from my computer)
2. Advanced System Settings
3. Environment Variables…
4. Click ‘New’ and add
- Name: VSDebug_DisableManagedReturnValue
- Value: 1