Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Windows Driver Profiler Script

Created: 30 Nov 2011 | 3 comments
ianatkin's picture
+5 5 Votes
Login to vote

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.
 

Introduction

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,
 
  1. UNKNOWN (for unknown drivers)
  2. NET
  3. HDC (Hard disk Controller)
  4. SCSIADAPTER
  5. DISPLAY
  6. MOUSE
  7. PORTS
  8. MEDIA
  9. IMAGE
  10. DISKDRIVE
 
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,
 
  • machine.inf
    Microsoft's native information file for installing common system devices
     
  • netpsa.inf
    contains descriptions of Packet Scheduler adapters
     
  • netrasa.inf
    contains descriptions of WAN miniports and wrappers
     
  • monitor.inf
    contains descriptions of common monitors
     
  • wave.inf
    contains descriptions of all the supported non-WDM audio drivers 
     
  • msports.inf
    contains descriptions of common communications ports (serial, parallel ports etc)
     
  • usb.inf
    contains descriptions of USB hubs and composite devices
     
  • usbport.inf
    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,
 
  1. 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.
     
  2. 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. 
     
  3. 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,
 
   Class GblDeviceStore
       Public DeviceClass
       Public DeviceName
       Public DriverVersion
       Public InfName
       Public IsSigned
       Public Manufacturer
       Public Signer
       Public DeviceID
       Public IsOutput
   End 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[1].
 
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.
 
 

Summary

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!
 
Kind Regards,
Ian./
 
 
[1] 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.
 

Comments 3 CommentsJump to latest comment

KSchroeder's picture

Outstanding work as always Ian, and nice use of bubble sort! laugh

Thanks,
Kyle
Symantec Trusted Advisor

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.

+1
Login to vote
ianatkin's picture

Not to mention a dashing use of class objects as data structures for the array to be bubble sorted! (say that 20 times after a few pints....)

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

0
Login to vote
EdT's picture

https://www-secure.symantec.com/connect/articles/readyutility-assist-identifying-plug-and-play-drivers

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

0
Login to vote