Updating UMDF drivers during development

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 inclu开发者_开发问答ding "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!

---

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

---

As Paul Betts has suggested above, the way to go seems to be to simply replace the UMDF DLL directly in the driver folder (for e.g. c:\windows\system32\drivers\umdf\) after disabling the device either in the device manager or using "devcon". I'd asked this question on Microsoft's device drivers newsgroup before posting here but hadn't got a satisfactory response - but some folks ended up responding there after I posted here! So I'll put up a link to that post as well:

http://bit.ly/6PDxKT