VirtualBox

Ticket #18265 (closed defect: fixed)

Opened 9 months ago

Last modified 4 months ago

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

Reported by: PetrGasparik Owned by:
Component: other Version: VirtualBox 6.0.0
Keywords: Cc:
Guest type: Windows Host type: Windows

Description

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%

Attachments

IEUser - Win7-2019-01-03-11-55-20.log Download (294.4 KB) - added by PetrGasparik 9 months ago.
VB log of crashed resume
vb6-crash.png Download (15.8 KB) - added by PetrGasparik 9 months ago.
E_FAIL error
Windows 7 32-bit-2019-01-05-15-33-21.log Download (169.6 KB) - added by mihi42 9 months ago.
vbox.log from "real" VM
Win7Naked-2019-01-05-15-44-44.log Download (166.9 KB) - added by mihi42 9 months ago.
vbox.log from "naked" VM

Change History

Changed 9 months ago by PetrGasparik

VB log of crashed resume

comment:1 Changed 9 months ago by PetrGasparik

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

Changed 9 months ago by PetrGasparik

E_FAIL error

comment:2 Changed 9 months ago by PetrGasparik

E FAIL (0x80004005) SessionMachine

comment:3 Changed 9 months ago by 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".
  1. You were supposed to follow these steps when you filed the bug, and provide a "VBox.log". You unfortunately provided the "VBoxHardening.log".
  1. If you're using a SCSI:LsiLogic controller for your virtual HD, then it's a duplicate of #18263.

Changed 9 months ago by mihi42

vbox.log from "real" VM

Changed 9 months ago by mihi42

vbox.log from "naked" VM

comment:4 Changed 9 months ago by 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 :)

comment:5 follow-ups: ↓ 6 ↓ 7 Changed 9 months ago by 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.

comment:6 in reply to: ↑ 5 Changed 6 months ago by 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.

comment:7 in reply to: ↑ 5 Changed 6 months ago by 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)...

comment:8 Changed 5 months ago by 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.

comment:9 follow-up: ↓ 10 Changed 5 months ago by bird

  • Summary changed from Win7 in VB 6.0.0 fails on resume on 97% to Win7 in VB 6.0.0 fails on resume on 97% => Fixed in SVN

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.)

comment:10 in reply to: ↑ 9 Changed 5 months ago by 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?

comment:11 Changed 4 months ago by michael

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use