Updating UMDF drivers during development
Ranju V
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/
--
Maxim S. Shatskih
> 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
ma...@storagecraft.com
http://www.storagecraft.com
Tim Roberts
>
> [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, ti...@probo.com
Providenza & Boekelheide, Inc.
Doron Holan [MSFT]
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" <avr...@gmail.com> wrote in message
news:316C0129-2EF7-4CDE...@microsoft.com...
Ranju V
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!