John Howard - Senior Program Manager in the Hyper-V team at Microsoft

Senior Program Manager, Hyper-V team, Windows Core Operating System Division.

VMBus fails to load (device cannot find enough free resources Code 12) on a Windows Server 2008 x86 virtual machine under Hyper-V

VMBus fails to load (device cannot find enough free resources Code 12) on a Windows Server 2008 x86 virtual machine under Hyper-V

  • Comments 39
  • Likes

There is one particular scenario where you could be faced with this when booting a VM using Hyper-V. The most obvious way you can immediately notice it is that when using Virtual Machine Connection to remotely control a virtual machine, you do not have mouse integration.

(Note that in Windows Server 2008 RTM, Hyper-V Beta integration components are in-box. You will see similar lack of mouse integration on future releases of Hyper-V where you have updated the physical machine but not updated the virtual machine image. Once we have a new release of Hyper-V available, I’ll post more on that.)

The issue is very specific to where you have a Windows Server 2008 x86 (not x64) virtual machine originally built using Virtual PC or Virtual Server.  It should not apply to Windows Vista SP1 (currently not supported in Hyper-V Beta). Opening Device Manager (Start devmgmt.msc) inside the virtual machine will provide the first sign that you are hitting the issue. As you can see in the screenshot below, under the Computer node, it says “Advanced Configuration and Power Interface (ACPI) PC”.


If you scan further down Device Manager to the bottom of the “System Devices” and double-click on VMBus (which has a yellow exclamation mark against it), you will see in the device status area that the device cannot find enough free resources that it can use. (Code 12).


The reason for this is similar to the issues stated in yesterdays blog post about having the correct HAL installed. For VMBus and other components necessary for synthetic device support in Hyper-V to load correctly, the HAL running in the virtual machine must be an APIC HAL. Fortunately, Windows Vista and Windows Server 2008 have a new boot option to force HAL detection during boot, which is off by default. The easiest way (command line junkies excused) to change this setting is through the “msconfig.exe” tool. If you select the boot tab and then hit advanced, you’ll notice a checkbox marked “Detect HAL”. After selecting this checkbox and hitting OK, you must reboot the virtual machine.


Once the virtual machine is restarted, open up device manager again. This time you will notice that under the computer node, it now reads “ACPI x86-based PC”.


A few final comments. First, the “Detect HAL” checkbox is sticky, and causes boot to be very slightly longer (so slight in fact, I can’t notice a difference using a stop-watch). If you do not intend returning this virtual machine back to Virtual Server or Virtual PC, you could turn the checkbox off and reboot.

To clear up a point from my previous post, I said that “In theory it is possible to swap the HAL, but not in a Microsoft supported manner (except on Vista and Windows Server 2008 – that’s a post for another day)”. Hopefully that is a little clearer now. You may be wondering, if you clear the checkbox, and while the virtual machine is configured with an APIC HAL, what happens if you take the VHD back to Virtual Server or Virtual PC?  In this case, the boot will not complete, even in safe mode. The way to resolve this is to ensure the check box for Detect HAL is checked before shutting down the virtual machine under Hyper-V. 

You can also set or clear the checkbox in a slightly smarter way if you don’t have a Hyper-V machine available to boot the virtual machine to toggle the checkbox directly while the VM is running. The answer is in BCDEditt. You could loopback mount the VHD and use bcdedit to alter the boot configuration store offline. I haven’t tried it with a mounted VHD, but the parameters would look something like “bcdedit /set {current} detecthal yes” replacing {current} with an appropriate store. There's something to investigate and a blog post for another day…


  • in windows 2008 x64 version latest trial, this does not work, still vmbus sends code 12.

  • redstone64 - can you provide a download link to the actual media you are installing from. Can you also confirm whether you are running Hyper-V Beta or Hyper-V RC0, and if the latter, you have applied the RC0 MSU update in the virtual machine.



  • Download Link:

    Windows version is 6.0.6001 Service Pack 1 Build 6001

    Downloaded Installed Windows 2008 x64 Edition

    More Shortly


    Applied Patch After Install:

    Release Candidate 0 (RC0) update to the Hyper-V

    Update for Windows Server 2008 x64 Edition (KB949219)

    Still In device manager, vmbus device sends code 12.

  • Redstone64 - Just to be clear (sorry!) - so you

    1. downloaded this ISO, burnt it and installed that on the physical machine itself (ie the parent partition).

    2. Applied the x64 version of KB949219 MSU on the parent partition

    3. Enabled the Hyper-V role

    4. Build a virtual machine using the same media

    5. Applied the x64 version of KB949219 MSU inside the virtual machine

    6. You are seeing VMBus device error 12 in the virtual machine

    That will allow me to verify things here.



  • My machine is:

    Intel E6320 Core 2 Duo Processor,

    EM64T, MMX,MMX2,SSE,SSE2,SSE3,SSSE3,Intel-VT, Execute Disable Bit

    P5VD2-VM Mainboard

    2GB RAM DDR2-800

    x1950GT x16 PCI-E Graphics Card

    Machine supports hardware virtualization, both BIOS and CPU.

  • Redstone64-  FYI, following the exact steps 1-6 above, I can't repro. I just need to know if you did something different which could explain what you're seeing.



  • I installed these roles and features with the hyper-v to the machine:

    .NET Framework 3.0 Features

    .NET Framework 3.0

    Desktop Exprience

    Group Policy Environment

    Windows Process Activation Service

    Process Model

    .NET Environment

    Configuration APIs.



    File Services

    Network Policy and Access Services

    today, I do the 1-6 of all things you applied except I install the hyper-v before the patch. still it does not work. Sends code 12 from vmbus driver.

  • Redstone64 - Can you email me \windows\logs\cbs\cbs.log from inside the virtual machine please. The link is at the top.



  • Same problem here, clean Server 2008 RTM install, installed hyper-v and downloaded and installed the rc0 update for hyper-v

    in device manager VMbus sits there with a yellow exclamation and code 12 . this is on the physical machine btw and it is preventing me to run any virtual machine....

  • @Korleqn - I took it from Redstone64's confirmation that he did steps 1-6 that he was able to start a virtual machine, which I would not expect if VMBus fails to start on the parent partition (physical machine), so this sounds different. Have you enabled VT/AMD-V and NX/XD in the BIOS, made sure you are on the latest BIOS and hard power cycled the machine.

    Can you provide similar details for your physical machine as for Redstone64?



  • Just wanted to add my own comment, since there seems to be a lot of people out there who like myself missunderstood all the steps earlier (although it is in fact written there..).

    The trick most people forget is that you have to install the patch "on the virtuel machine" in addition to the host itself! This can be a problem if you have no network drivers working, but either burn a cd or mount a physical disk.

    Anyway, hope this helps!

    Best regards,

    Morten Yndesdal

    MCT Glasspaper

  • After long fighting with VMBus device driver, I got a conclusion from a message comes out to event viewer.

    "VMBus cannot start because the machine does not support MSI."

    What  is MSI? I looked up wikipedia with a sadly conclusion.

    Message Signaled Interrupts, in PCI 2.2 and later and PCI Express, is an alternate form of interrupt from the traditional pin-signalled system; instead of asserting a given IRQ pin, a message is written to a segment of system memory. Each device can have from 1 to 32 unique memory locations in which to write MSI events to. An advantage of the MSI system is that data can be pushed along with the MSI event, allowing for greater functionality.

    That means i need a very good, brand new motherboard to use hyper-v functionality.

    Thank You,

  • @Redstone64. Yes, indeed, MSI is Message Signalled Interrupt. Out of interest, what motherboard is this you are using. There are very few motherboards which support VT/AMD-V and NX/XD which do not support MSI. In fact, there is only one I am aware of (need to go digging now to find out what machine it was).



  • VIA P4M900 Chipset, ASUS P5VD2-VM Mainboard.

    Pretty old.

  • I've got the same message as Redstone64. My motherboard is an Asus M2V.

    I do agree that this may not be the ideal machine where to run Hyper-V, but it's a pain if I'm not able to prototype virtual machines on my home system before deployng them on a server.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment