[Fixed] Windows 7 64 bit guest memory corruption

[mhanor]

Hello,

You may already have discovered and fixed this. Also I'm not sure if it's a regression, but I haven't managed to reproduce the issue not even once with VirtualBox 4.3.29.100535.
I can reproduce it, once in every 10-20 attempts, sometimes it comes more easily, sometimes it's doesn't, using a newly created Windows 7 64 bit VM (default settings, 2GB of RAM) and a Windows 7 64 bit installation ISO. I let the VM boot the ISO up to the first setup window, then I reboot it (Host+R) and repeat. When the issue is triggered, the ISO fails to boot with different BSOD screens each time, that's if the VM doesn't start a Guru Meditation with VINF_EM_TRIPLE_FAULT (I think the guest starts executing from wrong address). I'm attaching a VM log. I also have two full memory dumps of the VM process, one with the Guru Meditation, one with a crash that occurred while I was trying to reproduce the problem, when I hit a key combination, by mistake, to take a snapshot (I think).
I haven't managed to reproduce anything similar, using Windows 8.1 64 bit.

[mhanor]

I can reproduce the issue with RC1.

[Ramshankar]

Any idea if this happens when you disable Hyper-V for the VM? (use paravirt. provider as "none" in the GUI Acceleration tab)

[mhanor]

I've tried to reproduce the problem with the parav. provider set to 'None' (from 'Default'), so far it hasn't occurred.

[frank]

Too bad: I tried to reproduce this with a Windows 7 Enterprise DVD but was not successful. Hyper-V set as PV and rebooted the guest about 50 times.

[mhanor]

I first observed the issue after a few fresh installs, when sometimes the guest OS would hang (not completely) or VirtualBox would enter "guru meditation", right before it shows you the desktop, after completing the last setup steps (setting the user name, the PC name, the system date, the Windows Update, etc).
Would a guest memory dump be of use? Or the VirtualBox full process dump, while it's in guru meditation?

[mhanor]

I can reproduce this with RC2. If it helps, I can build the dbgopt OSE build and enable some logging.
I have the full process dump and the log for a RC2 VM session that entered guru meditation. In case you're interested...

[Ramshankar]

If you could give us the log for HM that would be useful. Namely, VBOX_WITH_R0_LOGGING=1 in LocalConfig.kmk or build debug VirtualBox using "kmk VBOX_WITH_R0_LOGGING=1".

Then, export or set VBOX_LOG="+hm.e.l4" before starting the VM.

The log will be pretty big as the VM runs longer, so if it takes too long to reproduce on one run, simply poweroff the VM and re-try to keep the log file smaller.

Ideally providing the log when the GURU happens would be more useful than a guest BSOD.

[mhanor]

I'm able to log to a separate log, not the VM log. How do I redirect it?

[mhanor]

Here are the logs, but separate:
https://drive.google.com/file/d/0B1LFjo ... sp=sharing

[Ramshankar]

I'm able to log to a separate log, not the VM log. How do I redirect it?

No need to redirect it, separate is fine and how it works.

[Ramshankar]

Thanks for the log, I had a look. If your problem is very easily reproducible, could you try disabling large pages for the VM and trying?

Code: Select all   Expand viewCollapse view

VBoxManage modifyvm <vmname> --largepages off


And you can verify that it's really off in VBox.log after starting the VM in the line:

Code: Select all   Expand viewCollapse view

EnableLargePages   <integer> = 0x0000000000000001 (1)


It should show 0 there instead of 1.

[mhanor]

I'm not able to reproduce it. Now I know why I wasn't able to reproduce it on my Ubuntu 14.04 x64 host OS. I have just enabled large pages (disabled by default, it seems, for this host) and now I'm able to reproduce it under my Ubuntu host OS, using the RC2 build.

[Ramshankar]

Thanks for testing, we should have a test build available soon.

[frank]

Here is a Windows test build which contains changes which hopefully fix your problem. Could you verify? Thank you!