Windows Driver Profiler Script
Created: 30 Nov 2011 | 3 comments
Getting a new computer imported into your imaging hardware pool can often be a right pain. One of those pains I'm going to ease today is driver tracking.
Today's article is a vbscript which will dump your hardware into a nice HTML template, so you avoid all that vendor confusion when downloading those 'unknown' drivers from the vendor's website.
I often do my driver tracking from within Linux automation. For me, the native command line tools lspci, lsmod and modinfo provide a faster route to driver tracking then anything I could find under Windows. It is not however an environment which many other admins find within their comfort zone, and I've often thought that there must be a way an easier way to do this on Windows (without invoking 3rd party tools).
A couple of days ago, our very own Ed introduced me to the Win32_PnPSignedDriver class when I was working through a Dell Accelerometer driver problem. Once I reviewed the class, it occurred to me that finally I could make a Windows script which could help.
This script can be found in the zip archive attached to this article.
Running the Script
In the Zip archive, you'll find two files, DriverProfiler.vbs and DriverProfiler_Template.html. Extract them both to a folder on a machine you'd like to take a driver profile from. For the purposes of what follows, let's assume C:\DriverProfiler
Double-click the script and wait for 5 seconds. When the script completes you'll see a new file html file appear which is named according to the rule DriverProfiler_<Model>_<Mass_Storage_Mode>_<Date>.html
If you open up your new HTML file, your browser should open to reveal something similar to that shown below (where I've only shown the first couple of drivers for clarity),
What you see here is a driver enumeration of your system. I've colourised and prioritised the following 10 driver classes for clarity,
- UNKNOWN (for unknown drivers)
- HDC (Hard disk Controller)
After these specific driver classes, all the remaining drivers are listed in their classes in alphabetical order. There are many drivers missing here, as i've considered them unimportant for imaging purposes. Among the drivers I've omitted are those found in the following inf files,
Microsoft's native information file for installing common system devices
contains descriptions of Packet Scheduler adapters
contains descriptions of WAN miniports and wrappers
contains descriptions of common monitors
contains descriptions of all the supported non-WDM audio drivers
contains descriptions of common communications ports (serial, parallel ports etc)
contains descriptions of USB hubs and composite devices
contains descriptions of USB Host Controllers that use USBPORT
Removing drivers which reference the above information files really help reduce the clutter in the driver report. If you feel you really want them though, you can always remove these exclusions from the CollectDriverData function in the vbscript.
Scenarios for Using the DriverProfiler Script
Now you've tried the script out, when should you use it? Well, I have a few scenarios,
- When new hardware arrives
When you get a new computer from your favorite vendor, don't just image it immediately. Boot it up and run this script to profile all the drivers installed by the vendor. Now store the results somewhere safe. When you now image the machine with your Hardware Independent Imaging (HII) solution, should any devices come up as unknown just need to fire up your report and search by deviceID to locate the missing driver.
- When ratifying hardware
If you have a process of ratifying your hardware, it might be very handy to keep with you performance and burn-in reports a report of the drivers you tested the machine with. This means that if you get any driver related problems in the future with this model, you can run another driver profile to check what's changed at the driver level. Nothing might have changed of course, but at least that eliminates straight off for you one course of enquiry.
- When Deploying images
You could attach this script to your image deployment jobs to alert you should a computer be imaged without a full set of drivers installed. This means you'll know fast that there is a problem allowing you to be proactive in resolving it. This could be because someone is imaging an unsupported model, but it is not unknown for vendors to slightly tweak your hardware configuration without notice.
By default, if DriverProfiler finds unknown devices, it will complete the report and then exit with error code INF_UNKNOWNDRIVERS=20. This exit code is to allow you to automate actions should unknown drivers be found. You can change this exit code by modifying the constant entry at the top of the vbscript.
Below is an example of an UNKNOWN device entry in the output HTML
How The Script Works
The heart of the driver profiling script is the Function CollectDriverData. This uses a WMI query to grab all the data from the Win32_PnPSignedDriver class and dump it into the one-dimensional MyDevices array. In order to store the data neatly, this array is actually an array of custom objects defined by the class,
All the elements here are returned from the WMI query with the exception of IsOutput which is set to 1. At this stage if any classless devices are found, the class is set to UNKNOWN and unknownflag is set to the value of the constant INF_UNKNOWNDRIVERS.
Next, as WQL doesn't like ORDER BY clauses I perform a bubble sort on the array to order the array alphabetically by DeviceClass. This is purely for neatness of presentation later.
Now we've harvested the data, it's time to write it to an html string. First I output the 'Tier1' device classes, with the UNKNOWN classes at the top. As each class entry is written to the html string, I also set at this point the IsOutput value to 1 so I know this device has been dealt with.
Once I've finished with the Tier1 devices, I then iterate through the array writing all entries without the IsOutput flag set to the html string.
Now it's time to write the file. For this purpose the template HTML is loaded into memory and the HTML injected into it (using a macro search and replace). As mass-storage controllers are often an issue, I then call the function GetHDC which uses Win32_PnPSignedDriver HDC class enumeration to discover if our mass-storage controller is RAID, AHCI or IDE.
Now we can write the HTML string to file, using in the naming scheme the computer model name (as determined by enumerating the Win32_ComputerSystemProduct class), the mass-storage controller type and the date.
Today's little project aims to provide a simple and useful vbscript to enumerate device drivers on your system. My hope is that it will save time when preparing new hardware for imaging with Altiris.
If you use it a task embedded in your deployment jobs, you might also be able to give yourself a little forewarning when machines are deplolyed without a full driver set installed.
It should work across all Windows platforms and architectures. If it doesn't let me know!
 If I'm honest -this is a cludge. In Linux I'd be able to determine the devices PCI Class and SubClass IDs to determine unambiguously the controller type. Across all Windows platforms however, this is more tricky and something I've left as a later project for myself.
Download Filed Under:
Endpoint Management, Altiris Client Management Suite - 6.x, Altiris Deployment Solution - 6.x, Altiris Client Management Suite, Altiris Client Management Suite - 7.x, Altiris Deployment Solution - 7.x, Altiris Deployment Solution, Basics, Best Practice, Documentation, Downloads, Features, Installing, Reporting, Tip/How to, Troubleshooting