locked
Reading driver information from INF/driver files RRS feed

  • Question

  • I'm working on a script for validating driver installation post build.  The process involves using SCCM/MDT to deploy my OS with a specific set of drivers, run the script and then validate that each driver has successfully installed.  To achieve this i've been looking at the INF files of the drivers that i had attempted to install and read information like version, date, driver name, compatable hardware ID, etc.  Then, i'd compare that information against what WMI shows as being installed.

    I'm finding that all INF files are not alike in structure and there does not seem to be an easy way to read that information for my comparison (getting driver information from WMI for installed drivers works just fine).  I know MDT has a method of taking a directory, finding what drivers are in it, and then importing them in and displaying driver information (without actually doing a real installation into the OS), so it is possible to do.

    Does anyone know how this is accomplished? 

    To summarise i'm looking for a way (with VBScript) to look at a directory, identify every driver in that directory, and then read in Device ID, Device Name, Driver Version, Driver Date, etc.

     

    Thank you

    Wednesday, December 7, 2011 6:01 PM

Answers

  • Hi,

    Yes, I would say if that's what you want to do, you're going to have to write your own. There's no standard way (that I know of) to get the information you're looking for.

    Bill

    • Marked as answer by Jason Tech Thursday, December 8, 2011 7:10 PM
    Thursday, December 8, 2011 5:20 PM
  • The question isn't related to checking what drivers are installed on a machine.  As the first post states, i know this can easily be done with WMI and have code to handle that.  There are many many sources discussing how to do that.

    The question is how to i take a folder containing driver source files (INF, SYS, CAB, etc) and identify the driver information as MDT does during driver importation.

    So far it seems like the only way to do this is to identify the INF files in the folder, and then use logic to read in the driver version, compatable pnp device ID's, provider, etc from those INF's.  My issue with that originally was that not all INF files follow the same formatting.  It sounds like i just need to add logic to handle the differences between INF files to gather the data (and that's likely how MDT does it).

    If anyone can say if my theory is correct then at least i'd know i'm following the right process.


    MDT does not use script. It uses the driver APIs and loads the diriver setup inot memory. It can then use the driver installer AP to install the driver or do anything it wants with it.

    If you need to decode the INF file you will need to post in the driver developers forum or refer to the driver development SDK which is available online.

    Yes - INFs can be a nuemrous formats depending on the version they were created in.  These differences are not documented.  I have built drivers and manged driver instals.  WHta you are doing in unnecessary and is the hard way to do what you want in scripting.  It is something that would normally be done in a compiled language.

    You say you want to validate an install. The normal method for doing this is to review the log files. 

    Normally when we say 'validate' a driver we mean check the drivers signature and checksum.  This is done against the driver file using any of a number of utilities. The only thing you need is the path to the installed driver file which is available from WMI.

    Microsoft Process Explorer has a built in facility for verifiing files.

     

     


    jv
    • Marked as answer by Jason Tech Thursday, December 8, 2011 7:10 PM
    Thursday, December 8, 2011 6:29 PM

All replies

  • Hi,

    If I understand your question, my (partial) answer is that you could look at driver files (*.sys?) and retrieve the file's version information and date using the FileSystemObject object's GetFileVersion method (provided the file has embedded version information, of course) and the DateLastModified property.

    Bill

    Wednesday, December 7, 2011 7:37 PM
  • The best way to valiate is to look in the setup log file for driver installation errors.  This is how the Microsoft tools do this.

    A better validation would be to just run teh Microsoft diagnostic tool and viw the summary results.

    If you are only interested in  one or two drivers then just search the installationlog for the installers messages.

     


    jv
    Wednesday, December 7, 2011 8:41 PM
  • I realize there are other ways to do it and logs that can be looked at. But, the preference would be a I described so the script can check about 20 drivers on 20 systems without requiring any manual work. When MDT imports drivers I think it looks at the inf file to gather the driver version, provider, comparable pnp's etc. if all it is is loads of logic to handle the differences in structure between inf files then I'll just try to reproduce that
    Wednesday, December 7, 2011 8:52 PM
  • Use WMI to check the drivers on remote systems.

    Query the device and look for the driver info.  The asociated class Win32_SystemDriver contains the path to the driver.

    $drv=gwmi Win32_NetworkAdapter -filter'Name="Intel(R) PRO/1000 MT Network Connection"' -computer remotepc1
    drv.GetRelated('Win32_SystemDriver')|select pathname

     

     


    jv
    Wednesday, December 7, 2011 9:33 PM
  • The question isn't related to checking what drivers are installed on a machine.  As the first post states, i know this can easily be done with WMI and have code to handle that.  There are many many sources discussing how to do that.

    The question is how to i take a folder containing driver source files (INF, SYS, CAB, etc) and identify the driver information as MDT does during driver importation.

    So far it seems like the only way to do this is to identify the INF files in the folder, and then use logic to read in the driver version, compatable pnp device ID's, provider, etc from those INF's.  My issue with that originally was that not all INF files follow the same formatting.  It sounds like i just need to add logic to handle the differences between INF files to gather the data (and that's likely how MDT does it).

    If anyone can say if my theory is correct then at least i'd know i'm following the right process.

    Thursday, December 8, 2011 4:42 PM
  • Hi,

    Yes, I would say if that's what you want to do, you're going to have to write your own. There's no standard way (that I know of) to get the information you're looking for.

    Bill

    • Marked as answer by Jason Tech Thursday, December 8, 2011 7:10 PM
    Thursday, December 8, 2011 5:20 PM
  • The question isn't related to checking what drivers are installed on a machine.  As the first post states, i know this can easily be done with WMI and have code to handle that.  There are many many sources discussing how to do that.

    The question is how to i take a folder containing driver source files (INF, SYS, CAB, etc) and identify the driver information as MDT does during driver importation.

    So far it seems like the only way to do this is to identify the INF files in the folder, and then use logic to read in the driver version, compatable pnp device ID's, provider, etc from those INF's.  My issue with that originally was that not all INF files follow the same formatting.  It sounds like i just need to add logic to handle the differences between INF files to gather the data (and that's likely how MDT does it).

    If anyone can say if my theory is correct then at least i'd know i'm following the right process.


    MDT does not use script. It uses the driver APIs and loads the diriver setup inot memory. It can then use the driver installer AP to install the driver or do anything it wants with it.

    If you need to decode the INF file you will need to post in the driver developers forum or refer to the driver development SDK which is available online.

    Yes - INFs can be a nuemrous formats depending on the version they were created in.  These differences are not documented.  I have built drivers and manged driver instals.  WHta you are doing in unnecessary and is the hard way to do what you want in scripting.  It is something that would normally be done in a compiled language.

    You say you want to validate an install. The normal method for doing this is to review the log files. 

    Normally when we say 'validate' a driver we mean check the drivers signature and checksum.  This is done against the driver file using any of a number of utilities. The only thing you need is the path to the installed driver file which is available from WMI.

    Microsoft Process Explorer has a built in facility for verifiing files.

     

     


    jv
    • Marked as answer by Jason Tech Thursday, December 8, 2011 7:10 PM
    Thursday, December 8, 2011 6:29 PM
  • I would agree that what i'm attempting is more difficult, but i wouldn't consider it unnecessary.  In driver validation there are two components.  One is to look at what is currently installed, and the other is to validate against a list of what you expect to see.  The script i'm developing makes the process of generating a list of drivers and versions obsolete.  It's a more efficient process to say "validate against this folder that already exists" rather than "validate against this list of drivers that i had to manually type up in addition to having a folder of drivers".  Sure it's not very difficult to make a csv list of drivers and versions manually, but i'd rather have an automated process to do that then to make a new list every month.

    I feel like if i refer to a log file i might not get 100% accurate results.  For example, maybe a task sequence step to install the driver i wanted was disabled, or a WMI filter blocked it from running, or another competing driver version was determined to be more accurate.  Yes, thats a human error that hopefully wouldn't happen to much but at least if i ignore the log and go right to the source i can identify if something went wrong (even if i'm not sure what it was).  My process would also identify all INF files that were available, but which were not installed (didn't match Pnp Device ID for a particular system or some other issue).  Then i could remove those drivers from the source and reduce package size (granted not by much).

    Using the Driver API as you indicated would be an improvement over VBS.  Maybe for version 2.0 of my script i'll use that but i currently do not have Visual Studio installed.  I think that would reduce the amount of coding and simplify things.  At this point i've already scripted everything i need to make this work other than getting Pnp ID's from the INF's and i expect to have that done before the weekend.  I should be able to click a button and get output on an HTA page that lists every driver that did not install, everyone that did successfully, and everyone where there is a driver version difference.  It will require no maintainance or list making or log checking.  I personally see that as a useful utility to have (but i've been told i'm crazy so who knows).

    Johan Arwidmark posted a list of steps for checking driver installation issues:

    [QUOTE]There are three steps in the driver injection process, each one needs to be verified:

    1. Were the needed drivers copied locally by ZTIDrivers.wsf?
    2. Did SETUP inject the drivers into the driver store?
    3. Did PNP install the drivers from the driver store?

    Log files to review are ZTIDrivers.log, setupact.log, cbs.log and setupapi.dev.log[/QUOTE]

    If i were able to script a process to check all 4 log files for errors and then display them on screen that might be a way to achieve my goal as well, but personally i see checking 4 log files for errors as more work than checking one INF file against WMI and looking for matches.

    Thursday, December 8, 2011 7:08 PM