A house of cards -- that's how I'd describe the current state of the Windows device driver ecosystem. With so many Windows-compatible devices and so few competent driver developers, it's no surprise that hunting for driver updates has become a necessary part of every power user's skill set. Most of the time, the search ends in frustration: Either the new driver doesn't correct the existing problem(s) or, worse, creates a set of new ones. And now, with the introduction of Hyper-V, we have a whole new failure vector to think about.

In a nutshell, one of Hyper-V's advertised strengths -- the host partition's ability to work with generic Windows device drivers -- is also its greatest weakness. That's because the quality level of Windows device drivers, especially those from third-party developers, is notoriously inconsistent.

I found this out the hard way while experimenting with the Hyper-V Release Candidate on a newly configured Windows "Workstation" 2008 system. After enabling the Hyper-V role in Server Manager, I made the mistake of trying to install the latest ATI Catalyst (8.4) software for the system's X1300 display adapter. The resulting Blue Screen of Death was both alarming (I hadn't seen one of these in months) and puzzling: I had successfully installed this driver before, on the same system, without incident. The only difference this time around was Hyper-V (uninstalling the role and rebooting allowed me to complete the driver installation).

Even more disturbing was the fact that I had just finished watching an old (December 2007) Channel9.com interview with Mark Russinovich, a Technical Fellow at Microsoft and one of the smartest guys I know. In the interview, Mark talks about Hyper-V and how its ability to leverage existing Windows drivers in the host partition gives Microsoft a competitive advantage over certain unnamed competitors (read: VMware), which require custom drivers for their proprietary hypervisor OS layer.

It all sounds great on paper, until you realize that it effectively places Hyper-V -- and the rest of Microsoft's virtualization architecture, for that matter -- at the mercy of the single most glaring weakness of the Windows ecosystem: third-party device driver developers, most of whom have no idea what Hyper-V is or how to avoid tripping over it during driver configuration/installation.

I point this out because it runs counter to everything that makes VMware's ESX platform so compelling. With ESX, you get, effectively, a black box: a proprietary environment, but one with its own, rigorous testing and development model. The pieces that go into that box -- the drivers and services that extend the Console OS layer (which is, itself, a derivative of Linux) -- are carefully vetted to ensure at least a baseline level of robustness.

By contrast, the Windows device driver landscape is more akin to a Wild West shoot-out. And while you can try to minimize the risk by sticking to Windows Hardware Quality Lab (WHQL)-certified products, there's no guarantee that they'll work reliably under the added stress introduced by the shared VM bus architecture on which Hyper-V is built. Eventually, something is going to cause a conflict, resulting in the kind of catastrophic system failure I experienced during the aforementioned ATI driver installation.

Bottom line: What Microsoft needs is more and better certification options. The company needs to expand WHQL to include Hyper-V testing and/or create a parallel program that further tests WHQL candidates for Hyper-V compatibility. Until then, it'll be hard to take its virtualization plans -- desktop or server -- seriously.