Home/ Questions/Q 520347
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T08:08:09+00:00

I am having some trouble updating UMDF drivers using devcon during a standard code-deploy-debug

  • 0

I am having some trouble updating UMDF drivers using “devcon” during a
standard code-deploy-debug cycle. The problem is that “devcon update” isn’t
really updating anything unless the version number or the date of the DLL
file and the INF file has changed from what is stored in the system’s driver
cache folder. After a maddening series of experiments I’ve discovered that
one way to force the thing to use the latest files is by doing the
following:

  1. Change the parameters passed to
    “stampinf.exe” in “makefile.inc” by
    explicitly setting a version with
    the “-v” option.
  2. Modify the
    resource script file (“DRIVER_NAME.rc”) to first define
    VER_USE_OTHER_MAJOR_MINOR_VER
    before including “ntverp.h” and then
    explicitly define
    VER_PRODUCTMAJORVERSION and
    VER_PRODUCTMINORVERSION. You’ll
    note that this system does not allow
    us to change the build and the
    revision numbers. On Win7 this
    seems to be fixed at 7600 and 16385
    in “ntverp.h“. Is this by design?

So, I first modify “makefile.inc” and set the “-v” option to something like
“1.1.7600.16385” manually incrementing the minor version for every single
build and then modify the RC file and update VER_PRODUCTMINORVERSION with
the same number.

Alternatively, if I run a command prompt under the SYSTEM account and go and
delete the driver cache folder in
“C:\windows\system32\DriverStore\FileRepository\DRIVER FOLDER” before
running “devcon” then that works too.

Now, I am thinking I am missing something fairly basic here as this seems to
be a rather painful way of doing it. Please help! Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Why can’t you just unplug the device and replace the unloaded DLL? You shouldn’t need to reinstall the driver, just replace the module. Note that you shouldn’t do this during production or anything that has to do with customers, but if you’re writing a driver, just slam in the new module with the same version number.

    On Win7 this seems to be fixed at 7600 and 16385 in “ntverp.h”. Is this by design?

    Yep, at least until the next service pack

    • 0