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.



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:


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.

CDO Error Message “Error ‘80040211’”

System Requirements:

  • Windows Server
  • Internet Information Services
  • ASP
  • CDO

The Problem:

When attempting to send an email using CDO under Windows Server you receive the following unspecific error message from your application debugger or web browser session:

error ‘80040211’
<path>/<file>.asp, line ##

Your application is unable to relay email into the SMTP system.

More Info:

The CDO error message is certainly due to your configuration of the SMTP server, or CDO’s inability to raise the stated SMTP server.

Step 1

A frequent cause of this error message comes from messages with lengthy message lines. It is common place within SMTP systems to refuse to transmit text lines that are greater than around 1000 characters (including the CRLF).

This does not mean that the message itself cannot be greater than 1000 characters, but that individual lines before the carriage return must be less than or equal to 998 characters (the CR [carriage return] and the LF [line feed] count as the remaining two characters).

This rule applies to plain text and to HTML messages. Ensure that your messages comply with this rule.


Step 2

Ensure that your ISP does not require authenticated SMTP access. If they do, you will need to modify your CDO connector to include authentication. In ASP this is achieved through the addition of the following lines into the CDO settings.

.Item(cdoSMTPAuthenticate) = cdoBasic
.Item(cdoSendUserName) = “YOUR-USER-NAME”
.Item(cdoSendPassword) = “YOUR-PASSWORD”


Step 3

Ensure that your system is able to connect to to the SMTP service port. A quick trick to check for SMTP connectivity without relying upon port scanners is:

  1. Open a command prompt
  2. Type:
    telnet <fully-qualified-domain-name / SMTP Server IP address> 25For example: telnet 25
  3. If the path to your SMTP server is being blocked you will see the following message
    Connecting To <server>…Could not open connection to the host, on port 25 : Connect failed

If your server is unable to access the STMP network, then this error message is consistent with such a failure. The most likely cause of such a block is a firewall rule from a software firewall or a rule configured on a hardware firewall by the network administrator.

An additional consideration to make while checking for connectivity is the impact that Anti-Virus and real-time Anti-Spyware products may have. For example, McAfee Virus Scan Enterprise 8.0.0i makes use of an anti-spyware rule that prevents mass mailing worms from sending email. McAfee will block the SMTP port by default and must be configured to allow IIS (or your application) to relay email.

To reconfigure McAfee Enterprise 8.0.0i:

  1. Open Virus Scan Console
  2. Double click Access Protection
    McAfee Filters
  3. Highlight the “Prevent mass mailing worms from sending email” and click Edit
  4. For IIS 6.0 running in with standard IIS 6.0 application protection add w3wp.exe to the exceptions list.
    Exceptions List
    For application you will need to query the McAfee log file for the executable name involved in the error message. By default this log can be found at:
    C:\Documents and Settings\All Users\Application Data\Network Associates\VirusScan\AccessProtectionLog.txt

Installing Capita’s SIMS FMS on a Citrix Metaframe server (and having it work)

System Requirements:

  • Citrix
  • Capita’s SIMS
  • FMS for SIMS
  • Windows Server 2003 / Windows Server 2003 R2

The Problem:

Capita’s SIMS, or ‘Schools Information Management System’ is a widely used UK school management application made by the masters of conglomerate outsourcing the Capita group. The propaganda states that it is used by over 22,000 schools here in the UK…

FMS (Financial Management System) is a bursary module for SIMS providing financial support backed by the wider SIMS database sub-system. FMS makes use of its own database environment, separated from the main SIMS data store: should you attempt to install FMS (version less than 6.91) on a Citrix server you are going to run into a no longer working version of FMS.

FMS installation on the Citrix terminal server system renders a mal-configured users session, resulting in a DSN error.

SIMS configuration requires the presence of a User level DSN on the system (At the NTLM SAM level) in order for the client application to make a connection to the database server.

The problem has been diagnosed as three fold:

  1. The FMS installation process is not MSTSC/Citrix compatible and is unable to correctly configure the client system at run-time. The current assumption is that this is due to the use of a pre-windows/very early windows 2000 driver which is certified for NT4 (non-TSE) and not enterprise TS environments (Dated 1999).
  2. The user DSN database setting are not being registered into the default profile on the server and as such no user accounts are receiving the user configuration settings.
  3. The legacy database connectivity driver is unable to automatically register on the system, relying upon the installation process to perform all required integration into the ODBC environment. As the installer is failing, so is the driver registration. This means that the User DSN cannot be created on the TS without intervention.

Lovely problem, terrible system

As you all know, I like a challenge.

FMS makes use of the Borland Desktop Engine, or more accurately the Sybase SQL Anywhere 5.0 DBMS. The version compiled for use by SIMS FMS was compiled way back in 1999 when men were men, terminal server were never used and Windows 2000 was not exactly being used by anyone other than… me.

Here we are in 2007 and trying to push the FMS configuration data off of a standalone workstation and onto a dedicated Citrix server; it wasn’t going to play nicely was it!

FMS will install, but it will never enable you to connect to the database citing connectivity issues.

The Fix:

This problem is squarely due to Capita having never evolved their database components, it isn’t FMS causing the issue, it isn’t Citrix, Windows Server 2003 or SIMS. It’s SQL Anywhere 5.0.

I really would urge you as a School’s administrator to head to Capita at this point and perform a cost / benefit analysis on obtaining FMS 6.91 or higher, which will port your old databases across to a new MS SQL 2005 environment. I guess even Capita realised that they were on borrowed time!

There are two distinct problems that must be solved before you will be able to use FMS over Citrix:

  1. The installation of the SQL Anywhere 5.0 driver set is not designed to run across the Terminal Server Installation Mode. As a direct consequence, once the installation is complete you will be left with the FMS database binary data scattered around your servers hard drive, but it will not be in a state where it is able to do anything! Windows is left oblivious to its presence.
  2. FMS makes use of a Mandatory DNS connection hosted at the user level to initiate connections between the client (on the Citrix server) and the SIMS / FMS database (hopefully stored somewhere other than the Citrix server). The user level DNS is not installed as part of the Citrix install and must be constructed by hand in the required user accounts.


Fixing the Sybase SQL Anywhere 5.0 Driver

The failure here is down to the age of the database components being used. Sybase’s developers must have been using legacy design standards and/or cut some corners in the construction of their ODBC driver set because there is not a single component in version 5.0 which is capable of performing and self registration functions under Win32.

The long and short of it is that the entire system had to be pulled to pieces, analysed and a manual driver registration system generated.

You will be pleased to hear that I served my penance, did my good deed for society and the future generation and am offering it up to you here to download.

Download: (2KB)


The following steps require that the FMS installation be performed on the TS as far as is permissible before failure.

The steps assume that the default installation paths are used on all components of the database client system.

The following documentation assumes that future connection attempts are being made to the FMS database server using the same database name, conventions and settings as found at the time of writing.


  1. Ensure that FMS is installed
  2. Ensure that the Sybase SQL Anywhere 5.0 driver components are located on the client at the following location:
    Note: The default installation for the client software is C:\SQLANY50\win32\. If you have installed the client applications to another location, you must edit the path in the hack file you downloaded above before registering it.
  3. Ensure that you have the DBclient.exe in the above path
  4. Ensure that you have FMS-Terminal-Server-Hack.reg from the zip file accompanying this document
  5. Make any edits to the fie that are required to tailor it to your system (see note above)
  6. Log into the terminal server with Administrative permissions to begin the process

Server configuration

Enter FMS-Terminal-Server-Hack.reg into the Windows registry.
This should be all that is required to configure the server. A reboot should not be necessary.

To validate the reconfiguration

  1. Start > Run > obdcad32.exe > ok
  2. User DSN tab
  3. Add
  4. Scroll to the bottom of the list and verify the presence of: Sybase SQL Anywhere 5.0 version date 10/08/1999

Client Configuration

The use of a mandatory User DSN means that the DSN must be configured on the client account, not the administrator account as it is not a global configuration setting.

The settings will be replicated to the user account profile.


Note: I cannot/will not provide screen shots of the process that follows in the interest of preserving client security. You will need to source the information from a working FMS client system from within your organisation.


To add the User DSN by hand:

  1. Start > Run > odbcad32.exe
  2. User DSN tab
  3. Add
  4. Select Sybase SQL Anywhere 5.0 from the bottom of the list, click Finish

Configure the Sybase DSN as follows

  • DSN: SIMS32
  • Description: General
  • User ID: <blank>
  • Password: <blank>
    Type: Custom
  • Translator Name: <No Translator>
  • Enable: Microsoft Applications (Keys in SQLStatistics)

Click on the OPTIONS button

  • Start Command: c:\sqlany50\win32\dbclient.exe -ta 600 -x NamedPipes,TCPIP
    Note: Modify the path above to match your Sybase SQL Anywhere 5.0 drive path
  • Database Switches: <blank>
  • Agent: Client
  • Autostop Database: Ticked
  • Isolation Level: <blank>
  • Describe Cursor Behaviour: If Required

Click Ok twice to save the DSN

Run FMS to prove that it works and and publish it into your Citrix environment as to your specific organisational needs.

Error: Activex componet can not create object: “WScript.Shell” when running WScript application

System Requirements:

  • Windows 95, 98, 98SE, Millennium
  • Windows NT 4.0, 2000, XP, 2003, Vista

The Problem:

When you run a .vbs file with a call to CreateObject(“WScript.Shell”) the script/application terminates with the follow error message:

ActiveX componet can not create object:”WScript.Shell”
Code: 800A01AD

The script then exits

More Information:

Your Windows Scripting Host has a mis-registered control. If you have just Installed Microsoft Internet Explorer <anything>.<anything> chances are the install went wrong. Check the install log in %SystemRoot% and check for failures.

I would recommend reinstalling IE properly to be safe, but chances are the problem will still be there afterward (it was with this particular muse and MSIE 7.0).

The fix is very simple however (assuming that your error is down to Windows Scripting Host and not bad programming; you are on your own on that one).

From cmd, or from a .bat run:

regsvr32 dispex.dll
regsvr32 jscript.dll
regsvr32 scrobj.dll
regsvr32 scrrun.dll
regsvr32 vbscript.dll
regsvr32 wshcon.dll
regsvr32 wshext.dll
regsvr32 wshom.ocx

I recommend that you start with wshom.ocx and test . No reboot is required for shell initiated .vbs files. If the problem is with IIS, you should restart the IIS Administrative and WWW services.

Be sure that you are using WScipt 5.6 (Unless running Vista or XP with IE7). You can download the latest release here: