I use Virtual Box 4.1.2 with a Windows 7 x64 Guest. On my guest is Visual Studio 2010 Pro.

I'm developing a C# project which makes heavy use of threads. When stepping through the code on my guest the Visual Studio debugger throws the exception:

"Attempted to read or write protected memory. This is often an indication that other memory is corrupt"

Using Visual Studio 2010 on the host, the debugger never throws this exception. I tested multiple hardware and rebuilt guest images with the same result. I believe that Virtual Box is corrupting the memory of the Visual Studio debugger.

I made a clean install image of Win 7 32bit, tossed on VS 2010 and still ran into the problem. It's not a corrupted framework. Until the issue gets resolved I've switched to using VMWare Player which doesn't exhibit the problem.

I can pretty easily repro, not sure what would be usefull as far as dumps. I can dump vs or w3p or something else. I've saved a "Minidump with Heap" from within VS, but its 120mb compressed. I can send if that would be useful.

Would like to help get this fixed as it is really hurting my debugging....

extract (better to delete 'bin' and 'obj' directories) and open the solution in Visual Studio 2012 or 2010

open NumberCounter.cs in code editor

goto line 79, put breakpoint there

press F5 (Run)

press 'Start' button on the form

when the debugger stops at the breakpoint, press and hold F10 key

The debugged application will crash with AccessViolationException after approx 10 seconds. If you enable "Native code debugging" in the example project it will take more time to crash and the AV address is still the same, see the ticket comment 9 for details. Note that it never happens in non-virtualized environment or using VMware.

It appears this issue occurs when 32 bit application is debugged on a x64 machine. Looks to me that somehow the calling into or returning from the "heavesn gate", ie the 'connection' between x64 and x86 mode, corrupts a stack.

This does not appear to be a VS bug, and should really be investigated, as the root cause may be much deeper.

Even more complicated, I can reproduce it by all combinations. 32 bit application on x64 virtual machine, 64 bit application on x64 virtual machine and 32 bit application on x86 virtual machine. All these environments produces the same error under Visual Studio debugger when stopping on a breakpoint. Note that VMware nor Virtual PC does not have the issue on the same hardware.

Can you reproduce the crash if you comment out the accessors for the Count property?
I can reproduce an access violation using a simpler C# application. But not if I use a field, instead of a property.

Yes, after a bit longer period of time, more step over the breakpoint line iterations. But it is still there in 100% cases anyway. I also can not reproduce it with a native C++ project but that's completely different platform and debugger.

I have also tried to insert System.Diagnostics.Debugger.Break() before the M1() method call instead of setting a breakpoint in Visual Studio and it worked fine. It seems to be as a thread synchronization (CPU cache coherence ?) issue between the debugger process (Visual Studio) and debugged one. Still, it is weird that only debugged process is affected and there are no similar issues with multithreaded code in general. Maybe there is something in VirtualBox that handles processes with 'debugger attached flag' in a different way.

Does all of you run VirtualBox on Windows host ? Any chance to check the issue on different one ?

I think there isn't anything else to try. We have to wait if the issue gets attention and will be investigated. If not, the only solution is probably to move to different vitualization software because such serious bug makes software development almost impossible.

Getting the same results here with Linux 3.8.x on ArchLinux and OS X Mountain Lion 10.8.2 and 10.8.3. Occurs much more frequently on OS X. Tolerably rare on ArchLinux.

On the OS X host, guest also occasionally throws an "illegal operation" in IIS Express while debugging.

Just attempted to disable nested paging and will see if it improves the frequency on Mountain Lion.

Guest:

Windows 7 Professional x64 SP1

Visual Studio 2012 Update 2

Debugging ASP.NET MVC and WPF projects

Hosts:

ArchLinux 3.8.x; Core i7-3770K; 32GB RAM

Mountain Lion 10.8.3; Retina MBP mid-2012; 8GB RAM

This has happened across several recent versions of Virtual 4.2.

VT-X is enabled, with nested paging and some other stuff. Guest has 4 CPUs. As above, just disabled nested paging and will see if that improves things. Will also attempt to set CPU affinity on the debugged process.

I wonder if something has made this bug more severe in recent editions, since it went mostly unnoticed for nearly a year and a half, and now has a lot of activity.

I have some additional info: I can prevent this bug from happening by assigning only one cpu to the guest AND restricting the VirtualBox.exe process to only one cpu on the host (TaskManager -> Set Affinity). So the bug occurs when the VirtualBox Process is switching cpu on the host.

And, as mbursill already stated, VMware does not have this problem: The same VM that exhibits the problem in VirtualBox, when converted to VMDK runs without a problem in VMware Player.

@jeff.deseret.tech: One cause for this bug staying unnoticed for so long might be that many people (me included) never thought this to be a bug in VirtualBox but blamed Visual Studio.

@AltGr: VMware (Workstation and ESX) nor Virtual PC have the issue. I've been using Visual Studio 2005, 2008, 2010 without a single occurence of it for many years. As you have experienced, the same virtual machine have the issue in VirtualBox only so it is hard to blame Visual Studio debugger.

I'll try your workaround to set affinity of the host process (I'd have never thought it could help). Unfortunately I do a lot of multithread code and I'd like to test it in more real environment than a single-CPU one. After all, supporting multiple cores was one of reasons to move from Virtual PC to VirtualBox. Sad.

I have some additional info: I can prevent this bug from happening by assigning only one cpu to the guest AND restricting the VirtualBox.exe process to only one cpu on the host (TaskManager -> Set Affinity). So the bug occurs when the VirtualBox Process is switching cpu on the host.

Yes, I can confirm it helps a bit but the issue is still present anyway.

So I finally got some time today to setup a Windows 7 VM, Visual Studio 2012 and debug the C# console application testcase provided in comment 18. I can confirm that it's indeed broken with VirtualBox 4.2.x and even with single VCPU VMs and is a VirtualBox bug.

The new VT-x code in trunk doesn't have this problem. I didn't have time to investigate even deeper. Unfortunately, identifying and backporting the exact fix to the 4.2.x branch will not be trivial and will require more investigation effort and time. All I can say now is, it should be fixed in the next major release, not in 4.2.x.

Maybe later we could provide you with a test build here for you to try that the fix works. Thank you for the report.

...I can confirm that it's indeed broken with VirtualBox 4.2.x and even with single VCPU VMs and is a VirtualBox bug.

The new VT-x code in trunk doesn't have this problem. I didn't have time to investigate even deeper. Unfortunately, identifying and backporting the exact fix to the 4.2.x branch will not be trivial and will require more investigation effort and time. All I can say now is, it should be fixed in the next major release, not in 4.2.x.

Maybe later we could provide you with a test build here for you to try that the fix works. Thank you for the report.

Ram, thanks so much for taking some time to look into this issue. I, for one, would find such a test build useful if the next major version is expected to be a ways off.

Ram, this is good news the issue is going to be fixed. I understand that it is not easy to propagate it to the older 4.2.x branch. Is there any time frame when the 4.3 will be released (this summer, end of the year, next year etc.) ? Thanks again.

I too can confirm that the bug seems to be solved with this build! I tried debugging the sample code from comment 18 for several hundred loops -> No memory exception!

And, also very important for me, the "other" debugging bug causing the debugger to "Run" instead of "Step Into/Step Over" never occured with this build either, even after minutes of running throught the code with F10 or F11.

Thanks to the developers. I'm looking forward to the next major release containing the fix.

I have been using Virtualbox in Linux Mint 14, I updated to Linux Mint 15, a fresh copy, just installed the package you submitted, created a new instance of Windows 7 virtual machine, using the last working copy of virtual drive, and I am getting this error message while attempting to run it.

I have tried the link in comment 39 and also installed the above extension pack, but ehen trying to start up my older VM's from a previous install I still get the virtualbox error as in comment 40. I noticed that the build version to the extension pack and the link to the Linux amd 64 .run script was different, could this cause a problem also?

Is there something else I can do or try, and if not how do uninstal that version I have just installed?

Yes i made sure I have installed the extpack before attempting any new instances and runs, I decided to create a fresh new instance of virtual machine to avoid any backwards compatibility bugs/issues, bottom line, I did everything according to my common sense, I honestly belive it has to do with this extpack, I haven't find any solutions so far, I'll keep diggin in. Look forward to hear from you, in the mean time, gracias amigos!.

I develop in Visual Studio on VirtualBox all the day long, and there are serious problems with its debugger and <= VirtualBox 4.2.x. Not only does the corrupted memory exception occur frequently, but the debugger shows other strange behaviors, like exiting loops early. One may say it is almost useless through the current production builds of VirtualBox. The problem seems worse on OS X hosts than Linux hosts.

This is indeed rectified by SVN builds of VirtualBox on an ArchLinux host, although it can be quite hairy to build. I will probably upload a PKGBUILD to the AUR to facilitate the build process soon.

If one *was* to attempt to bisect the repository in order to find the patch or patches that resolved this bug, what would be a good starting point? There are a lot of commits to traverse, so the more it can be narrowed down in both timeframe and affected files, the easier such a traversal would be.

Not to sound too pessimistic, but personally, I don't think it is worth the effort in trying to fix the debugging problems in 4.2.x when the next major release is around the corner.

I'm almost certain it's not a single changeset that "broke" it or fixed it. I don't think the debugging was working reliably in the first place to begin with. With trunk (which the next major release will be based on) has rewritten VT-x, AMD-V code that replaced the existing code. The existing code wasn't changed.

In other words, the chances of this being a one change regression is pretty slim and therefore bisect-regression analysis is unlikely to find anything. At best, you may find one changeset that magically works but that changeset might be a flip of the switch to the new VT-x/AMD-V code that spans thousands of lines.

Ah, I see. I didn't understand that a full rewrite of the VT-x code had occurred. It does indeed sound like a bisection would not be useful.

Do we have an ETA for VirtualBox 4.3? This is a fairly egregious bug that makes .NET development with VirtualBox much more difficult than necessary. I'd love to see the fix placed in the production release cycle soon.

Unfortunately it makes .NET development impossible because if you are hunting a bug for half an hour and then the debugger crashes due this issue ... your productivity is zero.

What makes me worry is that nobody knows what exactly causes it and what fixed it in upcoming 4.3 version. In case there will appear another issue related to VS debugging in 4.3 version, there is probably no hope to get it fixed soon.

It is not that nobody knows what is causing it. We don't have the time right now to investigate this issue especially when there is no significant customer demand and thus is not feasible.

If anyone in the open source community feels like investigating 4.2.x to see why it breaks VS debugging, feel free to send us patches. We're more than willing to review and integrate them if it works and is completely safe to backport.

Thanks for replies.
I understand the difficulty to investigate but temporary patch posted before seemed to work is'nt it ?
Even if it is not posible to include this in futures release this solution would be useful right now :)
Is it possible to have active links again please ?

I understand the difficulty to investigate but temporary patch posted before seemed to work is'nt it ?
Even if it is not posible to include this in futures release this solution would be useful right now :)
Is it possible to have active links again please ?

We've put out a 4.3 beta which includes this fix. Since the beta is out the next major release will (if all things go well) follow soon.

I understand the difficulty to investigate but temporary patch posted before seemed to work is'nt it ?
Even if it is not posible to include this in futures release this solution would be useful right now :)
Is it possible to have active links again please ?

We've put out a 4.3 beta which includes this fix. Since the beta is out the next major release will (if all things go well) follow soon.

I have assumed the F10 Step issue is related to the original issue, but I could be wrong (I and AltGr - ticket:9659#comment:34 - mentioned the F10 issue) and VirtualBox 4.3 seemed to fix my F10 Step issue.

I have Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel

After reading your MS connect links (thanks), my problem may be VS 2010 related rather than VirtualBox : one of the thru links mentioned that debugger property eval timeouts could cause problems, and I do get those for some of my properties that have long-running once-only initialisation.