Win7 in VB 6.0.0 fails on resume on 97% => Fixed in SVN

[PetrGasparik]

I moved my Win7 image from VB 5.2 to VB 6.0

Usually, I put my Win image on sleep after end of work. On every resume, there is an error at 97%

[PetrGasparik]

VB log of crashed resume

[PetrGasparik]

By "sleep image" I mean "Save computer state"

[PetrGasparik]

E_FAIL error

[PetrGasparik]

E FAIL (0x80004005) SessionMachine

[Socratis]

1. It's usually better and faster, if issues get first addressed in the ​VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of. For example, yours is most probably not a bug and someone from the developers has to deal with it and close it as "Invalid".

2. You were supposed to follow these steps when you filed the bug, and provide a "VBox.log". You unfortunately provided the "VBoxHardening.log".

3. If you're using a SCSI:LsiLogic controller for your virtual HD, then it's a duplicate of #18263.

[mihi42]

vbox.log from "real" VM

[mihi42]

vbox.log from "naked" VM

[mihi42]

Having the same issue here.

Some more information:

• Old Vbox VM which I think even was created with VBox 4 or earlier
• It is 100% reproducible for me with that VM, when I pause+save the VM while the system is booted, it crashes during resume
• on my machine (Win10 host), vsjitdebugger.exe (from Visual Studio) tries to catch "unknown software exception 0x80000003", but is unable to attach to the target process even when running the debugger elevated. But that may be caused of hardening, and it seems that the required information is also in the vbox.log.
• When I pause the VM while the system is not yet booted (e.g. in Windows 7 Boot Options menu), resuming does *not* crash the VM
• When booting a 32-bit Linux live distro (I used grml32 from grml.org) in that same VM, it crashes on resume too
• When creating a new Win7 vm with all default settings and booting that VM into the same Linux live distro (without installing anything on the attached hard disk), it crashes too. For the record, both VMs use AHCI and no SCSI controllers.
• Whe booting the same 32-bit Linux distro into another VM I have (that normally runs Windows 7 64-bit), *no* crash happens.

So it seems to be a combination of VM settings and the fact that the VM is booted into a 32-bit OS.

I attached vbox.log from both crashes (my "real" VM and the test VM).

I can come to IRC tonight (around 1900 UTC) if you want more information :)

[mihi42]

After testing a few settings - this bug happens if IO APIC is disabled; VMs where IO APIC is enabled can be restored without a problem. Not sure if that qualifies as a workaround, as there are some caveats mentioned in the User Manual about changing IO APIC when Windows is already installed in the VM.

[KnutEdelbert]

Replying to mihi42:

After testing a few settings - this bug happens if IO APIC is disabled; VMs where IO APIC is enabled can be restored without a problem. Not sure if that qualifies as a workaround, as there are some caveats mentioned in the User Manual about changing IO APIC when Windows is already installed in the VM.

Thank you so much! This was my problem too.

[def]

Replying to mihi42:

After testing a few settings - this bug happens if IO APIC is disabled; VMs where IO APIC is enabled can be restored without a problem. Not sure if that qualifies as a workaround, as there are some caveats mentioned in the User Manual about changing IO APIC when Windows is already installed in the VM.

I came here from Ticket #18331 for the 2003 windows guest this IO APIC didnot change anything ... still cant be waked from suspend.

(and for win7 it did not help - it were changing of net adapter that helped stop fail after suspend)...

[mihi42]

For me, the bug is no longer happening in 6.0.6, regardless of IO APIC settings.

This includes VMs that have been paused in previous VBox versions and resumed in 6.0.6.

So from my point of view, this ticket can be closed.

[bird]

Seems some device is raising interrupts while restoring saved state, which it is absolutely not supposed to do, thus the release assertion later in the restore process. However, to move on with this I've degraded the release assertion to a scary log entry (in VBox.log) and we'll try hunt down the real culprit internally.

The fix will appear in 6.0.8, 5.2.30 and any test build with revision 130145 or higher. (No, we did not knowingly fix this in 6.0.6.)

[Socratis]

Replying to bird:

I've degraded the release assertion to a scary log entry (in VBox.log) and we'll try hunt down the real culprit internally.

Anything in particular we should be looking for in the VBox.log?

The fix will appear in 6.0.8, 5.2.30 and any test build with revision 130145 or higher. (No, we did not knowingly fix this in 6.0.6.)

So, we'll continue to see those fails in between?