VirtualBox

Ticket #6153 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

Vista guest, DWM crashes in 3.1.2

Reported by: KenHagan Owned by:
Priority: major Component: other
Version: VirtualBox 3.1.2 Keywords:
Cc: Guest type: Windows
Host type: Windows

Description

Since upgrading from 3.1.0 to 3.1.2, both my Windows Vista VMs have been broken. They boot up fine, but when you log in (any user) they just hang. The host CPU sticks at 50% usage (it's a 2 core chip).

The workaround was to boot into safe mode and disable the Desktop Window Manager service, then reboot the guest.

Having done that, I can log in and discover from the event log that DWM.EXE (6.0.6002.18005) has crashed in VBoxOGLpackspu.dll (3.1.2.0) at offset 0x00011102 with exception code 0xC0000005.

Both the host (Windows Server 2003) and the guest are fully patched.

Attachments

VBox.log.3 Download (60.6 KB) - added by KenHagan 4 years ago.

Change History

Changed 4 years ago by KenHagan

comment:1 Changed 4 years ago by sandervl73

Try to go back to one CPU in the guest or try out the 3.1.4 beta announced on the forum. If neither helps, then disable 3d support for the VM.

comment:2 Changed 4 years ago by KenHagan

OK, I've run through the eight permutations of: "1 or 2 CPUs", "3D support or not", "version 3.1.2 or 3.1.4beta (with guest additions)". The mis-behaviour remains in every case. (One small difference is that when 3D support is disabled but 2 CPUs are present, the CPU usage sticks at 100%, not 50%.)

Looking through the event log, I actually find just two crash reports. Both blame VBoxOGLpackspu.dll offset 0x00011102, but one happened yesterday in DWM.EXE and is version 3.1.2.0 of the DLL whereas the other happened in December in TaskEng.exe and relates to 3.1.0.0 of the DLL. It may be a bit of a red herring, since the dominant symptom is a CPU in wheelspin, rather than crashing to a halt!

comment:3 Changed 3 years ago by KenHagan

In case anyone bumps into this bug on a search, I should point out that subsequent releases (3.2.x, certainly for larger values of x) have not exhibited this problem. Whether it was fixed or was simply pilot error to begin with, I don't know.

comment:4 Changed 3 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

So let's close this ticket as fixed.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use