I recently installed ubuntu-13.10-desktop-amd64 in a VM using Easy Install and everything worked fine initially. Install completed, and guest OS booted successfully (host OS is Win7 64-bit). I shut down the guest and exited Workstation, then restarted Workstation and booted the Ubuntu VM. The VM starts booting, then the host OS crashes with a blue-screen error "BAD_POOL_HEADER". Ran hardware checks and no problems were found. Noted that I can run a similarly-configured ubuntu 12.04 (64-bit) VM without crashing. Workstation version is 10.0.1-1379776. Anyone else run into this problem?
-gfdavis
Is the host crash repeatable ?
If yes - can you prevent it by disabling the networkadapter of that VM ?
Does the VM use any physical devices like rawdisks or serialports or USB ?
it would help to see the vmware.log from that VM
You can attach the vmware.log file as a file (DO NOT copy and paste its contents into the body of a reply) by selecting the "Use advanced editor" link in the upper right corner of the normal reply window to bring up the Advanced Editor where you'll be able to attach files via the Choose File button or Browse button (depending on the Browser) above the Post Message button!
Host OS crash is repeatable. I've reinstalled many times with different VM configurations (including no network adapter) and it crashes each time on the second boot. The VM is not using any physical devices (I installed from an iso on my desktop and nothing else was attached to the laptop during the install or before the crash). The vmware.log that was created during the crash is filled with 96KB of binary garbage (repeating "^@"). The vmware.log created from the installation and the first boot/shutdown is attached.
My guess: Thinprint again ...
set
serial0.present = "TRUE"
to
serial0.present = "false"
and try again.
If you prefer the GUI - disable Thinprint
looks like a kind of buffer-overflowing issue in the vm driver.
Thanks for the suggestions. I tried disabling Thinprint, both after the install (before 2nd boot) and prior to installation (by removing the printer, which I confirmed set the option you indicated in the vmx file). Still crashes host OS in the same way, though I did get a vmware.log that wasn't full of garbage this time (attached). Unfortunately, nothing meaningful is logged after the interactive prompt about the sata0:1 device (from iso install).
I reverted to my older Dell E6510 laptop and it was able to run vmWare Workstation + Ubuntu 13.10/64-bit without problems. Then this laptop was reimaged this week with a new corporate Win7 image and now the BAD_POOL_HEADER bluescreen crash is occurring as described before. So it isn't hardware-specific, but related to whatever is in the new host OS configuration.
I stumbled into a solution just now. I found that I also had a smaller Ubuntu 12.04/64-bit VM that was crashing in the same way, so confirmed it isn't actually Ubuntu 13.10-specific. I made two copies of this VM and changed the hardware compatibility of one of them to be "vmware 9", and left the other one at "vmware 10". Well, the one set to "vmware 9" compatibility boots without crashing, and further, if I change it *back* to "vmware 10" hardware compatibility it also doesn't crash! I've just done this to the Ubuntu 13.10 VM as well and that is now booting without incident.
The process of reverting to "vmware 9" compatibility removes the SATA CD/DVD drive as a side-effect, and going back to "vmware 10" doesn't restore this drive (which is reasonable). If I shut down the working "vmware 10" VM and add a CD drive, which defaults to a SATA type, then click "Advanced" options for the drive and set it to IDE, this brings back the bluescreen crash of the host. I thought maybe it was SATA-emulation specific and could get away with an IDE CD/DVD drive, but that isn't the case.
I had the same problem and when I disabled the CD rom drive, my vm ran. Thanks for finding a solution!
Using VM-WKS 10.0.5 Build-2443746 on a Windows 7 64 had the same issue. Removed the SATA CD-ROM and was able to boot without crashing host OS. The very interesting occurrence was this did not crash other VMs. Guest VM that appeared to cause crash was Window 7 64.
Having the same issue as this.
I have a brand new Dell M4800, imaged with our corporate SOE.
When I do a check on the Dell support site, it shows up a few drivers and BIOS updates available... but nothing mentioning any fix for an issue like this
Any time I boot a VM with the physical DVD drive attached the laptop blue screens.
Similar problems in VMware Workstation 10.0.7 on WinXP SP2 64-bit host but in other circumstances.
While unmount (after click Disconnect button) the VMDK disk, which was previously mounted using the File > Map Virtual Disks ... BSOD BAD_POOL_HEADER follows:
The tested VMDK disk was set as SATA in the virtual machine. I have not tested other disks set in IDE or other modes.
Why resurrect a 9 year old post about VMware and Microsoft software that's been unsupported for almost a decade? Nobody is going to fix anything on those versions.
Time to move on.
Why did you write in this topic if it does not help to solve?
My point is you'll be lucky if someone remembers if there's any kind of workaround for 10 year old pieces of software.
It also appears that you are posting about a totally different problem than what's being discussed in this thread. It looks like you're trying to mount an existing VMDK to the host and not trying to run a VM like the other posters are doing.
The only advice I have is to try Workstation 10.0.7 to see if the issue may have been fixed there. 10.0.7 is the last version of Workstation 10 that VMware released. The release notes aren't published so it's not easy to determine what's changed between 10.0.1 version and 10.0.7.
You do not read carefully - I wrote that the problem is on version 10.0.7 and I do not need to look for a solution because in the older version 8 everything works as it should.
I apologize for not picking up that you are running 10.0.7.
I wonder if there were stability issues in 10.0. It may be possible that’s there’s a bug in the virtual disk kit that may be behind all of this causing a similar BSOD.