Ever had an “Unknown Device” in Device Manager and ended up spending a long time trying to find drivers for the device? This can be particularly difficult on laptops where the vendor has put in hardware that you don’t even know about and weren’t necessarily expecting.
Fortunately, it is actually quite easy, usually, to troubleshoot these situations and know what drivers to search for by looking at the hardware id in the details in Device Manager and then searching the web for that term.
Note that the “VEN_” tells us the vendor, “NVIDIA” in the example above, as can be found at http://www.pcidatabase.com and the “DEV_” is the device. Incidentally, vendor “VEN_8086” is Intel which always makes me chuckle! I usually don’t need to bother searching for the “SUBSYS_” or “REV_” strings since “VEN_” and “DEV_” is enough to identify the vendor and device and thence driver. Obviously it is always best to get the drivers from the Vendor’s website rather than a third party site since these latter drivers could contain malware, etc.
However, sometimes even with the seemingly correct driver package it still does not cure the problem. For instance, I recently had a battle with the drivers for an Epson printer. I knew I’d win but it was how long it would take and how much hair I would lose in the process!
I started with getting the latest driver package from the vendor’s web site rather than using the bundled CD as you never quite know how long these have been sat in a stock room somewhere. However, after installing the drivers, the USB attached printer was still showing as an unknown device. Even trying to update the driver, via Device Manager, and pointing it at the folder where the .inf file resided did not rectify the situation.
I then looked in the .inf file for the hardware id since the way Windows finds the right .inf file for a device is to look for an .inf file with that hardware id in it (see http://msdn.microsoft.com/en-us/library/windows/hardware/ff549520(v=vs.85).aspx). What I noticed was that the hardware id wasn’t listed despite the .inf file being the right one according to the descriptions in the file, i.e. had the name of the printer model I was trying to use in it. An easy way to search .inf files for a given id from a cmd prompt is:
findstr /i /c:”PCI\VEN_10DE^&DEV_0A6C” %systemroot%\inf\*.inf
Note the escaping of the ampersand (&) above otherwise the batch processor will treat the command line as two separate commands and will not run properly. Due to a limitation in “findstr” (and “find”), the above won’t work for Unicode files so instead I use Strings.exe from SysInternals/Microsoft in the following way which works for both Unicode and ASCII files:
strings.exe %systemroot%\inf\*.inf | find /i “PCI\VEN_10DE&DEV_0A6C”
I use “find” instead of “findstr” as I frequently get “out of memory” errors when using findstr in this pipelined way.
What I then did was to take a copy of the .inf file and add in the “missing” hardware id such that Windows now accepted it as being the “correct” .inf file for this device. It did then fail on some of the subsequent copying of driver files but that was soon rectified by creating a new, temporary, folder with a copy of this .inf file in, and then copying into there all of the missing files, which were dotted around the system in such places as the driver installation package folder and %systemroot%\ System32\spool. Identifying the missing files was achieved with a mixture of SysInternals/Microsoft Process Monitor running during the driver install and entries in the file %systemroot%\inf\setupapi.dev.log.
This setupapi.dev.log is “quite interesting” in that it keeps a record of all device installations, and statuses, from the birth of the specific computer. Think someone may have inserted a USB stick to “steal” something when you left your system unlocked (tut, tut)? Then either search for that date/time in the setupapi.dev.log file or look for the hardware id in this file, e.g. search for “Cruzer” if you think that the device was a SanDisk Cruzer flash drive, for instance.