Hyper-V Discrete Device Assignment (DDA) with a TV Tuner (Hauppauge HVR-4400)

System Requirements:

  • Windows Server 2016
  • Hauppauge HVR-4400 PCIe Tuner

The Problem:

I am a DVBLink user. DVBLink does not play nicely with Windows Service and consequently it wants to run on a client OS. This means that I have lots of server hardware running server Operating Systems and one device with 4 TV Tuners in it running Windows 10.

With the release of Windows Server 2016 came the promise of VMWare like PCIe Pass-through, allowing physical devices on the PCI bus to be attached to VMs. The plan is to attach the PCIe TV Tuner and attempt to get DVBLink working in a VM so that the physical unit can be decommissioned (saving the power bill).

More Info

As part of the process, I was considering building a new server at the start of 2017 to perform a consolidation against. The Windows 10 DVBLink machine would be one consolidated devices onto more powerful modern hardware. I would also need new TV Tuners as only 2 of the 4 in the DVBLink TV Server is PCIe, the rest are PCI. Again, there are opportunities to consolidate that into fewer PCIe devices too.

The driver for the new server was Hyper-V PCIe Pass-through, or “Discrete Device Assignment” (DDA) as Microsoft are calling it. It is however quite difficult to find out whether BIOS firmware supports the proper implementations of I/O-MMU VT-d to permit it, making the purchase a risk. Equally, there is no guarantee that DDA will work with a TV Tuner.

Consequently, I decided to borrow a dual CPU Dell PowerEdge R630 to perform the experiment as there were several reports on-line that the R6xx and R7xx have the proper VT-d and SR-IOV feature set for this type of activity. Well done Dell (why don’t you advertise this?!).

After updating firmware, adding the TV Tuner and installing Windows Hyper-V Server 2016 on the machine, the first step was to – as an experiment – attempt to install the TV Tuner drivers on Windows Server 2016 (which errored). After that it was time to run the DDA Survey Script from Microsoft.

Download: DDA Survey Script (GitHub)

 

This was promising. The script found two devices that it stated were capable of being used with DDA

PERC H730 Mini
Express Endpoint -- more secure.
And its interrupts are message-based, assignment can work.
PCIROOT(0)#PCI(0100)#PCI(0000)

and

Hauppauge WinTV HVR-4400 (Model 121xxx, Hybrid DVB-T/S2, IR)
Express Endpoint -- more secure.
And it has no interrupts at all -- assignment can work.
PCIROOT(0)#PCI(0200)#PCI(0000)

The next step was to dismount the device from the Hypervisor and make it available to Hyper-V

# Find the HVR-4400
$pnpdevs = Get-PnpDevice -PresentOnly | Where-Object {$_.Class -eq "Media"} | Where-Object {$_.Service -eq "HCW85BDA"}# ... or if you know the hardware ID
$pnpdevs = Get-PnpDevice -PresentOnly | Where-Object {$_.InstanceId -eq "PCI\VEN_14F1&DEV_888
0&SUBSYS_C1080070&REV_04\4&39CDA168&0&0010"}foreach ($pnpdev in $pnpdevs) {
Disable-PnpDevice -InstanceId $pnpdev.InstanceId -Confirm:$false
Write-Host 'Device ' $pnpdev.InstanceId ' Disabled. NOTE: If this hangs, reboot and try again'
$instanceId = $pnpdev.InstanceId
$locationpath = ($pnpdev | get-pnpdeviceproperty DEVPKEY_Device_LocationPaths).data[0]
Write-Host 'Dismounting Device At: ' $locationpath ' (' $instanceId ')'
Dismount-VmHostAssignableDevice -locationpath $locationpath
Write-Host $locationpath
}

Initially, it hung PowerShell (and the system) so I had to hard reset the server. In this instance it was in fact necessary to reboot after issuing

Disable-PnpDevice

After trying again and rebooting the Dismount-VmHostAssignableDevice failed with

dismount-vmhostassignabledevice : The operation failed.
The manufacturer of this device has not supplied any directives for securing this device while exposing it to a
virtual machine. The device should only be exposed to trusted virtual machines.
This device is not supported when passed through to a virtual machine.
The operation failed.
The manufacturer of this device has not supplied any directives for securing this device while exposing it to a
virtual machine. The device should only be exposed to trusted virtual machines.
This device is not supported and has not been tested when passed through to a virtual machine. It may or may not
function. The system as a whole may become unstable. The device should only be exposed to trusted virtual machines.
At line:1 char:1

It would not proceed past this point. The trick was to change the line to

Dismount-VmHostAssignableDevice -locationpath $locationpath -Force

The next step was to ensure that the VM’s Automatic Stop Action was set to anything other than “Save”

Set-VM -Name “10-TEST” -AutomaticStopAction Shutdown

… and at this point it was simply a case of creating a VM and assigning the device

Add-VMAssignableDevice -LocationPath “$locationpath” -VMName “10-Test”

At which point the device immediately popped up in Device Manager under Windows 10 in the Generation 2 VM

DDA PCIe Passthrough in Device Manager

…. before the VM blue screened a few seconds later.

Blue Screen of Death

I tried to use several versions of the HVR-4400 driver that I could find and it made no difference. The VM would crash whenever it attempted to talk to the card. The Hypervisor itself did not seem to be impacted by the Blue Screen event and itself did not crash.

I also tried fully removing the device from the Hypervisor using DEVCON and clearing out the driver using pnputil. Superficially, this action made it worse as the VM wouldn’t boot at all now if it had a driver on-file for the TV Tuner. Before it would at least boot.

So this project was a failure and I will not be investing in new server hardware just yet. I’ll wait to see if Microsoft improve the feature set as allegedly this type of insanity (and yes, it is insane) is possible in VMWare. I do not want to change away from Hyper-V at the current time though, so I will have to stick with a client machine as a service.

This does not mean of course that this cannot work in Hyper-V. The HVR-4400 is a card from 2011/2012. So it is not exactly new hardware. PCIe TV Tuners designed to modern electrical standards and for use on PCIe 3.0 bus architectures may provide better interoperability out of the box. I just don’t have any other cards to test with and am in a bit of a chicken and egg situation over wanting to invest in new cards and servers unless I know they will work nicely together.

If you are interested in this too and would like me to have a go testing your hardware, please get in touch via HPC:Factor.

Error: “Drivers have NOT been updated. Compatible hardware not found. <>” when installing Hauppauge WinTV NOVA-T-500

System Requirements:

  • Windows 2000, XP, Vista
  • Hauppauge WinTV NOVA-T-500

The Problem:

It is highly possible that this error can be seen on other Hauppauge cards aside from my experience with the NOVA-T-500.

I just took delivery of what has turned out to be a rather disastrous eBuyer order, one of the products was a WinTV NOVA-T-500. If you follow the quick start guide (or even if you don’t) you may wind up being presented with the following error message:

Drivers have NOT been updated. Compatible hardware not found. <<click to exit>>

This happens if you use the CD to install from, download the latest driver package or try to use Windows Update as a means to save you from yourself.

Installer Error Screen Shot

Quite simple, Windows cannot find any driver for the application.

More Info:

My instant feeling of dread that I knew precisely what was going on aside, let me walk you through the problem; but before I do, let me give you the bad new right now – unless you have clumsily managed to half insert the NOVA into the PCTV slot, you will be in need of an RMA number because your board will not work.

 

The NOVA

On inspection the NOVA-T-500 is actually quite clever, Hauppauge have elected to keep their dual-tuner configuration as simple as possible, by sticking to what they presumably know works. The NOVA-T-500 is in effect nothing more than a PCI USB 2.0 Controller card with two USB 2.0 DVB-T tuners and a USB IR adapter connected directly to the controllers internal bus. Creative!

The NOVA-T-500

As you can see this particular NOVA-T-500 has the following model information:

  • WinTV-NOVA-T-500
  • DVB-T
  • 99101 LF
  • Rev D8B5

I actually just wanted to spell that out because I do think that is is quite a novel approach to their card design.

 

Exploring the driver install failure

A trip to device manager reveals a rather disconcerting unidentified, un-startable hardware device is present within the system – and effectively tells that Windows has no idea what to do with it

Device Manager with the NOVA-T-500

Most modern controller devices, while in their uninstalled state will usually have some sort of identifying attribute, yet here all we receive from the NOVA-T-500 is “HOOK”.

Here is the problem. All modern devices, PCI, USB, AGP – you name it – have a Plug n’ Play identifier (PnPID) which informs the operating system over who (in hexadecimal terms) manufactured the device (the Vid) and which device in their product inventory was just connected to a respective system bus (the Pid).

The WiTV NOVA-T-500’s correct PnPID is:

USB\VID_2040&PID_9951 (I believe)

While the PnPID of the device I received was identifying itself as:

USB\Vid_10b8&Pid_0066

To check your PnPID, all you need to do is visit the Details tab for the device properties in the Windows Device Manager (you can also locate it in the registry if you know where to look).

Vid & Pid PnP information

This explains why Windows was unable to locate a driver, the PnPID in the device driver cannot be matched to the one being identified by the PCI device and as a consequence, the driver installation fails.

It is possible, from time to time, to rewrite the driver ID’s (it will break WHQL certification) so that you can force Windows to mount the driver and load the hardware, I have done this several times quite successfully in the past and naturally wondered if this was going to be possible this time around.

 

Why this is not (easily) fixable

I needed to know the correct PnPID for the NOVA-T-500 and after a lightning search on the web, decided to give Hauppauge UK’s support a call. Sadly this was too technical for them, and they wanted me to phone Hauppauge support in the USA in order to out line the problem to a developer rather than to technical support. I did explain the whole EEprom PnPID issue to them, but these are effectively sales guys who have to pass everything back to HQ in the states that doesn’t come up on the expert system/knowledge base.

While I was explaining the PnPID concept to Hauppauge support, I started playing around with the driver files, and in reading through happened to notice that one of them did indeed contain the Vid/Pid combination being broadcast by my device. With finding this, I now have confirmation of what I suspected was the problem. The EEprom was blank!

; Uncomment these on production test systems to enable blank EEprom programming
;%BDA3700.DeviceDesc_cold2% = BDA3700.Device,USB\VID_10B8&PID_0066

For reference the “;” is a REM statement to comment out the information from being read by the Windows Driver loader, however the plain text comment for the section (found in hcw95all.inf, hcw95all_64.inf, hcw99bda.inf and hcw99bda_64.inf should you want to look) confirmed my suspicion. This Vid/Pid is used to program the EEprom of the device at manufacturing. My device had somehow skipped this part of its assembly, been boxed and found itself inside my computer – if it was going to happen, it was going to happen to me, of course it was!

The missing EEprom information explains why the device is identifying itself as “HOOK” to the system, with the EEprom in place, the PnPID tag would be decidedly different, without it we simply get engineering information.

This problem should be fixable by the end use so long as is a run-time reflash procedure and not a JTag style flash prcoess. If the process is JTag based then the card is not a write-off, it can simply be reflashed and sent back out again.

Either way, I have put in a support request to Hauppauge US with the information found in this article along with a request to be contacted by a developer/engineer and I shall see if they are willing to release the flash information so that I can fix it myself.

Hauppauge UK simply told me to RMA it and that they would look out for a bad batch.

 

Update – 15/01/2007

Hauppauge USA never got back to me, despite their promises to do so – shame on you Hauppauge. The replacement device from eBuyer arrived and works correctly, coming with the UK 4.0A release CD. Version 4.1 has been out for less than 24 hours at this point, so if you are a user, do go and update to the latest release.