Posted by: Ed Tittel
I’ll admit it: I love to tinker with computers and to keep their device drivers up-to-date. This requires the occasional bit of creativity in figuring out how to bring the latest drivers together with the devices they support, especially when you find a driver from Vendor X for a device included in a computer build by Vendor Y, and need to extract .inf, .cat, and .dll files from an executable program designed only to run on a machine identifiable as coming from Vendor X for Vendor Y’s version of that same device. I will happily spend hours noodling my way through this kind of thing, trying out Intel drivers initially made available only for Intel motherboards on my systems that include MSI, Asus, or GigaByte motherboards instead, or extracting drivers from packages put together for Dell, Toshiba, or Fujitsu notebook PCs on my HP or Lenovo boxes.
Recently, I found myself updating a Windows 7 Ultimate 32-bit VM that I created just before I finally upgraded my production system from 32- to 64-bit Windows 7 in June. Out of curiosity I began to play with the drivers for the VM to learn what, if anything, I could do to make sure they were up to date. What I learned was that it does little good to seek out device drivers for specific bits of hardware in the underlying physical host when dealing with a VM. By design, there’s a layer of insulation between the VM and the underlying host system that makes any mappings that a driver update tool such as DriverAgent might find more or less irrelevant.
But what I did observe in systematically checking the various entries in Device Manager for that VM was that clicking “Update Driver” for devices in the interface — especially those that register as Unknown Devices, or that have the yellow exclamation point marker to indicate driver issues — will occasionally produce good results, in the form of a driver update or even conversion from Unknown Device to a workable driver of some kind. Using DriverAgent, I was able to see that some device drivers registered as out of date on its radar, and then to use that information to dive into Device Manager to use the “Update Driver” and “Search Automatically…” buttons to provoke some meaningful action. This helped me convert an Unknown Device entry to a working Human Interface Device (HID) entry, and enabled me to update drivers for ACPI and some USB devices as well.
One item remains stubbornly resistant to update or repair, however, and all my searching does not produce any fixes. While PC Integration features to access local hard disks on the host machine, and to use USB devices plugged into that machine work just fine, the Virtual PC Host Bus Driver comes up with a Code 31 error “This device is not working properly because Windows cannot load the drivers required for this device.” Even so, the Automatic Update facility reports “Windows has determined the driver software for your device is up to date.” That’s got me kinda stumped as to how to proceed from here, because I can’t find any fixes to solve this apparent disconnect despite all of my diligent Web searches and spelunking around on TechNet and in the Windows Seven Forums.
Nevertheless, it’s all very interesting and I’m learning more about the architecture and operations of VMs than I ever had a need to before. There’s nothing that makes me happier than figuring out why things aren’t working, and learning not just how to fix what’s (apparently) broke, but also where workarounds make sense, and where leaving well enough alone is the best strategy of all!