One of my favourite features in Windows 8 is client side Hyper-V. This allows me to run multiple virtual machines on my Lenovo W530 laptop without having to remote to other machines when I am on site with customers.
As you can imagine I have a plethora of VMs for a variety of situations, and I ran into a bit of a pickle when moving my Exchange 2003/2007/2010 migration workshop lab over to Windows 8. This was for a different series of VMs than the one that would not import.
I thought that I’d share this to save others the time. So if you are seeing issues around:
-
Unable to update Hyper-V Integration Components
-
No mouse integration
-
No network connectivity
-
Updating IC drivers with Error 1168: Element not found.
-
Windows cannot load the device driver for this hardware. The driver may be corrupted or missing (Code 39)
Then you may be interested in seeing what was going on with my naughty integration components! Oooohh matron…
Update 20-1-2014: For a giggle I repeated the exercise with Windows Server 2012 R2 to see if that would upgrade the original VM's ICs correctly. It did not and I still had the same behaviour as shown here.
The Starting Configuration
The machine that we will look at is a Windows Server 2003 x86 Enterprise Edition VM with SP2 installed. Upon starting the VM up we can see that the Windows 2008 R2 SP1 Hyper-V Integration Components (6.1.7601.17514) are currently installed as this VM was last running on that version of Hyper-V.
The VM was copied to my Windows 8 laptop, imported and then powered on.
Device Manager shows that there is a virtual network card present, and as expected there are a couple of unrecognised devices. This is because the Windows 2008 R2 version of the Integration Components will allow the machine to start and function, but does not recognise all of the virtual hardware in a Windows 8/2012 hosted VM.
Looking at the properties of one of the unknown devices we can see the following:
The above is something that updating the Integration Components to a supported version will fix. So moving on…
The virtual network card has the following version information. If your name is Norman Potter, Hyper-V version spotter, then you might notice that something is not quite pukka with this……
And to check the version information of the file on disk: netsvc50.sys 6.0.6001.18004
Hold those thoughts for now, and we’ll come back to them.
Upgrading Integration Components
From the VM’s Action menu when “Insert Integration Services Setup Disk” is selected, the expected prompt appears in the VM.
So far so good, so let’s hit OK to start the upgrade.
The upgrade commences and then states that it has successfully completed. The VM is then immediately restarted as requested.
After the reboot, things are not looking good. In fact, it’s all gone a bit Pete Tong…..
In the event logs multiple services have failed to start. There is also no network connectivity to any other machines. IPCONFIG shows no IPs are present and there is no valid TCP/IP configuration.
It looks like a new party game has been invented, it’s called “Hunt the network card”. Can you see the network card listed below in Device Manager?
Nope, neither can I…..
When showing system devices, some of the system devices are unable to start.
Properties of the above devices shows the following:
Troubleshooting The Naughty Devices
In the C:Windows folder there was nothing of interest in the new Integration Services Setup Logs
C:WindowsVMGuestSetup.log -- - Debug log written by setup.exe. A new section is appended to the log for each installation or uninstallation
C:WindowsVMGcoInstall.log -- Debug log written by the guest components co-installer. A new section is appended to the log for each installation or uninstallation
I also had an older log VMGInst.log dating from April 2008. Opening this log would reveal the issue, but I’ll keep that to the end else it will spoil the surprise 
When troubleshooting virtual machine issues it sometimes helps to think what would you do if there were a physical machine? Well on Windows 2003 I would look at the setupapi.log. And sure enough the setupapi.log had errors within it:
#I443 No installed Authenticode(tm) catalogs matching catalog name "oem0.CAT" were found that validated file "C:WINDOWSsystem32DRVSTOREgencounter_46FBE6659A8242F714DAEF17D05DB56E79E85446gencounter.inf" (key "gencounter.inf"). Error 1168: Element not found.
#I443 No installed Authenticode(tm) catalogs matching catalog name "oem16.CAT" were found that validated file "C:WINDOWSsystem32DRVSTOREgencounter_46FBE6659A8242F714DAEF17D05DB56E79E85446gencounter.inf" (key "gencounter.inf"). Error 1168: Element not found.
#I443 No installed Authenticode(tm) catalogs matching catalog name "oem17.CAT" were found that validated file "C:WINDOWSsystem32DRVSTOREgencounter_46FBE6659A8242F714DAEF17D05DB56E79E85446gencounter.inf" (key "gencounter.inf"). Error 1168: Element not found.
[2012/07/04 18:35:17 2808.202 Driver Install]
Are those files there, and are they corrupt?
Looking at the system showed that these oem.inf files were still present on the file system. When opened up in notepad it is possible to see that they are related to Hyper-V IC, and that the dates indicated that they are old and out dated. So Windows is not attempting to install the later versions of the Hyper-V drivers, and is getting stuck on the old files which are failing Authenticode checks.
Again placing this in context on a physical system with driver issues, one technique is to purge the offending driver from the system and then to re-install it fresh. In the case of this Windows 2003 VM I then uninstalled the latest Hyper-VC ICs and restarted the machine.
Once logged back on after the reboot, I did a quick search to see what other remnants have been left over from previous installs. The results can be seen below. After checking that these are all Hyper-V files I moved all of them out from their current location to a backup location.
Upgrading Integration Components – Part Deux
Now that all traces of the previous Integration Components have been removed, let’s install the latest Integration Components. This was done using the same method as originally discussed above.
After the required restart, the mouse integration, networking and all unknown hardware elements are working fine. The gods of plug & pray are on our side.
All the virtual hardware components were correctly enumerated and installed on the first attempt. This also includes the virtual network card which is rather handy as this was the Domain Controller for this particular lab.
Conclusion
Thinking about certain issues inside a VM will involve the same troubleshooting as a physical machine. VM’s <James Doohan> Cannae Change the Laws of Physics ! </James Doohan> so physical reality still matters.
In the case of this VM, it had existed on every single version of Hyper-v starting from the initial beta build and had managed to retain one of the older drivers. When we look at Windows Vista and up and the move to Component Based Servicing (CBS), this has alleviated a lot of the issues with chaining multiple .inf files and the dependency issues that they create. Take a peek at this for more details on CBS.
The VMGInst.log showed that the initial installation for the Hyper-V beta ICs was the start of this issue. This log had entries like
C:WINDOWSsystem32CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}netvsc.cat with error 0x57
KB article You cannot install some updates or programs discusses some of the issues around such errors.
And for some more historical fun, remember that the initial release of Hyper-V was announced as coming < 180 days after the release for Windows 2008. This was installed through update Description of the update for the release version of the Hyper-V technology for Windows Server 2008 (950050) which is dated 26th of June 2008. This DC VM was built using the beta version in April 2008.
Note that you may not have the VMGInst.log present on your system as this log is not used in the more recent Hyper-V versions.
Cheers,
Rhoderick
