在开发过程中更新 UMDF 驱动程序
我在使用“devcon”更新 UMDF 驱动程序时遇到一些问题 标准代码-部署-调试周期。问题是“devcon update”不是 真正更新任何内容，除非 DLL 的版本号或日期 文件和 INF 文件已与系统驱动程序中存储的内容发生更改 缓存文件夹。经过一系列令人发狂的实验后我发现 强制使用最新文件的一种方法是执行以下操作 以下：
- 更改传递给的参数 “makefile.inc”中的“stampinf.exe” 显式设置版本 “-v”选项。
- 修改 首先定义的资源脚本文件（“DRIVER_NAME.rc”）
VER_USE_OTHER_MAJOR_MINOR_VER在包含“ntverp.h”之前，然后 明确定义VER_ProductMAJORVERSION和VER_ProductMINORVERSION。你会 请注意，该系统不允许 我们改变构建和 修订号。在Win7上这个 好像固定在7600和16385 在“ntverp.h”中。这是设计使然吗？
所以，我首先修改“makefile.inc”并将“-v”选项设置为类似的内容 “1.1.7600.16385”手动增加每个版本的次要版本 构建然后修改 RC 文件并更新 VER_PRODUCTMINORVERSION 相同的数字。
或者，如果我在 SYSTEM 帐户下运行命令提示符并转到 删除驱动程序缓存文件夹 “C:\windows\system32\DriverStore\FileRepository\DRIVER FOLDER”之前 运行“devcon”然后也可以。
现在，我想我在这里遗漏了一些相当基本的东西，因为这似乎 这是一种相当痛苦的做法。请帮忙！谢谢！
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:
- Change the parameters passed to
"stampinf.exe" in "makefile.inc" by
explicitly setting a version with
the "-v" option. - Modify the
resource script file ("DRIVER_NAME.rc") to first defineVER_USE_OTHER_MAJOR_MINOR_VER
before including "ntverp.h" and then
explicitly defineVER_PRODUCTMAJORVERSIONandVER_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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么不能直接拔掉设备并替换卸载的 DLL？您不需要重新安装驱动程序，只需更换模块即可。请注意，您不应该在生产期间或与客户有关的任何事情中执行此操作，但如果您正在编写驱动程序，只需猛击具有相同版本号的新模块即可。
是的，至少在下一个服务包之前
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.
Yep, at least until the next service pack
正如 Paul Betts 上面所建议的，解决方法似乎是在禁用驱动程序文件夹后直接替换驱动程序文件夹中的 UMDF DLL（例如
c:\windows\system32\drivers\umdf\）设备可以在设备管理器中或使用“devcon”。在我在这里发帖之前，我曾在微软的设备驱动程序新闻组中提出过这个问题，但没有得到满意的答复 - 但在我在这里发帖之后有些人最终在那里做出了回应！所以我也会发布该帖子的链接：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: