I'm trying, under Windows 7, to run a virtual machine with VMWare Player from an OS installed on a physical partition. However, when I boot the virtual machine, VMWare Player says that it couldn't access the physical drive for writing.

This seems to be a generally acknowledged problem in the VMWare community, as Windows Vista introduced a compelling new security feature that makes it impossible to write to a raw drive without obtaining exclusive access to it first.

I have googled the issue and found a few workarounds. However, the clean ones seem to only work on whole physical disks, and not on partitions.

So I would be left with the dirty solution. In short, it meddles with the MBR to erase any trace of the partitions to use, makes Windows forget about them, then restores the MBR so we can launch the VM.

I'm not sure I want to do that. Is there a way to let VMWare acquire exclusive access to the partition without requiring me to nuke it away? What I'd be looking for, I suppose, is a way to put just partitions offline instead of whole physical drives.

More infos related to the bounty.

I have a dual-boot setup: Mac OS is my primary operating system, and I have Windows installed too. As much as I can run Windows in a virtual machine if I don't want to reboot, I'd like to be able to run Mac OS in a virtual machine when I'm under Windows.

My goal is to run my main Mac OS partition from VMWare under Windows, just like I run Windows from VMWare Fusion. (Since this is my main OS, I don't plan on patching the kernel or whatever to get it working in a virtual machine.) I created the virtual machine from VMWare Fusion (as it has the "Mac OS X Server" VM type) then moved it to Windows and modified it from VMWare Player. Seems to almost-work, as the OS gets to the loading screen and then the VM dies because it can't access \\.\PhysicalDrive0.

Virtual Box fails even harder, as it starts Mac OS in verbose mode and crashes very quickly (but seems to be able to access the partition), so I think it would be easier to get VMWare access my partition than to get Virtual Box to run it.

On the legal side, I'd be running one copy of Mac OS X on one Apple-labelled machine, so I'm okay.

  • Interesting problem. Does it work if you create a blank, unformatted partition? – nhinkle Dec 31 '10 at 18:01
  • @nhinkle I don't have any spare partition room I can test with on my internal drive. However, from what I read, it seems Windows will lock any partition it can recognize; and I can confirm that it will still lock those that have no mount point as well. – zneak Dec 31 '10 at 21:01
  • @zneak: I have used in the past TrueCrypt to work around Windows restrictions. As it has its own disk driver, it may be able to write to the disk. Why don't you try making the partition into a TrueCrypt virtual disk? – harrymc Jan 2 '11 at 17:44
  • @harrymc I haven't tried. Do I need to encrypt my Mac OS partition? – zneak Jan 2 '11 at 18:04
  • You will need to create a TrueCrypt volume on the partition (losing all content). This might help to show how, but see also the TrueCrypt help. – harrymc Jan 2 '11 at 18:35

I have come across only one possible solution, using the free virtual disk driver imdisk together with devio (remote drive access and acquisition). As imdisk is a kernel driver, it might be able to write to the partition. Unfortunately, as devio works in user-mode, I am not too sure whether this approach will work for you.

devio can acquire a physical partition and publish it on the network. For example:

devio -r 9000 \\.\PhysicalDrive0 2

does publish from the first disk the second partition on TCP port 9000, and will wait for a connection on this port. Better disable the firewall while testing this, and run devio as administrator.

To define this published partition as a new and stand-alone hard disk, use :

imdisk -a -t proxy -o ip -f -m R:

which using localhost will create a new hard disk called R which is not a partition of anything. You can now try whether you can use the pretend real hard disk R in a VMware virtual machine.

This approach is explained in detail in Devio: Remote drive access and acquisition.

If this doesn't work, you will either have to :

  1. Accept a dangerous solution that modifies the MBR.
  2. Abandon using MacOS within Win7 as VM, using files in the Mac partition through Windows applications (with end-of-line character problems).
  3. Use a Virtual File System product, such as ELDOS Callback File System, although I doubt that this problem is worth for you a few thousand dollars.
  4. Abandon Windows 7 and downgrade to XP.
  5. Modify the source of imdisk so that as a kernel driver it will create a pretend disk directly on the physical partition, without the need for devio.
  • If done properly, editing the MBR should not pose too big a threat. Even if it were to become corrupted, it's not the primary OS partition, so who cares? You can easily fix it! – Breakthrough Jan 7 '11 at 5:04
  • @Breakthrough I think you miss the fact that both OSes are on the same disk. – zneak Jan 8 '11 at 4:02
  • @zneak: I think @Breakthrough is right - there are several programs that can save and then restore the MBR in emergency. – harrymc Jan 8 '11 at 9:04
  • Also, just for the record, VMWare unfortunately can't use a virtual drive from imdisk. – zneak Jan 8 '11 at 22:04
  • That's correct, because ImDisk doesn't register correctly with the NT Mount Manager using the IOCTL_MOUNTMGR_CREATE_POINT control code; it instead directly creates a symbolic link for the drive letter, and of course the kernel doesn't consider that a legitimate volume. I've tried to get it to work before, but I haven't succeeded much. (It's the same reason why you can't use an ImDisk volume for, say, mounting a VHD.) – user541686 Jan 8 '11 at 22:45

It depends on how desperate you are to get this working, but I would say that it's possible, with "just" two "easy" (read: brutal) steps:

  1. Write a driver to bypass the restriction set by Windows, using the (semi-?)documented flag SL_FORCE_DIRECT_WRITE.

  2. Hook the CreateFile and/or WriteFile call from VMWare using a library like EasyHook (I told you it was easy!) to communicate with the file manually with your driver, perhaps communicating with the driver using DeviceIoControl.

It actually doesn't sound that bad, if you know where to look for the information for bypassing the restrictions... I've hooked applications like Nero myself in order to examine IOCTL_SCSI_PASS_THROUGH calls so I can make my own CD burner library, and this wouldn't be too difficult; writing a driver will be the harder part, but manageable.


I'm guessing you already figured this out, but the structure you need to modify is called FLT_IO_PARAMETER_BLOCK for IRP_MJ_READ. Not sure how easy it will be, but it shouldn't be too hard.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.