Updating UMDF drivers during development
in [Device Drivers]
|
Prev: UMDF can not pass a stucture with pointers?
Next: Deadlock problem with ERESOURCEs in filesystem driver
From: Ranju V on 1 Jan 2010 23:05 Hi, 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! -- Ranju. V http://blogorama.nerdworks.in/ --
From: Maxim S. Shatskih on 2 Jan 2010 05:08 > You'll note that this system does not allow us to change the build and the > revision numbers. Why not? Use "svnversion" or similar too, then "sed" to make a C header file from "svnversion" output. Include this as a pre-build step. Then #include the header everywhere, to .rc too. > So, I first modify "makefile.inc" Modifying the .rc file is by far better. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Tim Roberts on 3 Jan 2010 19:39 "Ranju V" <avranju(a)gmail.com> wrote: > > [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? This is a SAMPLE. They do that so all Microsoft-built files have the right version number. You are most certainly not REQUIRED to use those numbers in your resource script. I, for example, do not include "ntverp.h" at all. Instead I define the values I want, and then include "common.ver". >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. The easier way, for testing, is to simply copy the file directly into C:\windows\system32\drivers and restart the device. You'll want to test the whole driver package mechanism before you ship, of course. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: Doron Holan [MSFT] on 4 Jan 2010 16:34 once installed you do not need to update. just disable the device via device manager or devcon, copy the new DLL over, enable the device. done. d -- This posting is provided "AS IS" with no warranties, and confers no rights. "Ranju V" <avranju(a)gmail.com> wrote in message news:316C0129-2EF7-4CDE-9340-FD049F63774A(a)microsoft.com... > Hi, > > 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! > > -- > Ranju. V > http://blogorama.nerdworks.in/ > -- > >
From: Ranju V on 9 Jan 2010 21:51
Thanks for your answers everyone. Replacing the DLL is of course as simple as disabling the device and replacing the DLL before enabling the device again. And fixing the RC up became straightforward once I understood that one didn't *have to* include "ntverp.h". Thanks again! -- Ranju. V http://blogorama.nerdworks.in/ -- |