使用netcfg删除NDIS不会从驱动程序存储中删除它吗？

Question

当我试图使用netcfg -u删除NDIS时，我注意到它没有从驱动程序存储中删除它(可以在pnputil /enum-drivers中看到)。

这会造成问题，因为在某些Windows 10机器上，如果我们卸载以前版本的NDIS并使用netcfg安装新版本，由于某种未知的原因，旧的inf仍然用于安装它！我认为这是因为inf仍然有相同的componentID？我们正在更新INF文件，以便附加到一些以前无法附加的虚拟适配器上。请注意，这在Windows 7中没有发生，我们可以安装新的没有任何问题。

所以我的问题是：

1. 当我们尝试安装新更新的具有不同INF的驱动程序时，为什么Windows仍然使用以前的从驱动程序存储的INF？
2. 怎样才能完全删除之前的NDIS，包括从驱动程序存储中删除？如果我们需要使用pnputil从驱动程序存储中完全删除它，那么考虑到pnputil -d需要一个OEM号，那么找到OEM号的正确方法是什么？

Answer 1

对，正如您注意到的，netcfg.exe -i与netcfg.exe -u不是完全相反的。

安装会执行以下步骤：

1. 将-l提供的INF安装到驱动程序存储区(SetupCopyOEMInf)
2. 打电话给INetCfgClassSetup::Install：

1. Query PNP for the "best match" for the componentId you provided with `-i` (`SetupDiBuildDriverInfoList`, `SetupDiSelectBestCompatDrv`)
2. Run all the sections in the INF (`AddReg`, `AddService`, etc)
3. Register a LWF/Protocol/TDI driver with the system using info in the `Ndi` registry key

卸载以下步骤：

1. 调用INetCfgComponent::DeInstall to：
   1. 取消系统LWF/Protocol/TDI驱动程序的注册
   2. 运行INF的特殊部分 (希望它包含一个DelReg，DelService，用于撤消安装步骤2.2期间完成的所有操作)

(上面的描述忽略了驱动程序重新计数系统(又名OBO_TOKEN)，因为它不是经常使用的--大多数驱动程序只使用一次重新计数。如果您只使用netcfg.exe来管理您的驱动程序，那么您也可以忽略重新计数。)

你可能会想:为什么这不太棒？这里的背景是，netcfg.exe从来就不是真正的通用工具，用于第三方软件来管理他们的驱动程序。它只用于内部，用于内置在操作系统(ms_tcpip等)中的驱动程序。假设第三方驱动程序安装程序希望调用适当的API(如INetCfg )，而不是调用CreateProcess (可执行文件)和屏幕刮取输出。因此，netcfg.exe仅仅是我们内部需求的最低需求。特别是，很少注意卸载，因为内置驱动很少被卸载。(同样，参数解析不灵活，帮助文本没有帮助，错误处理也不健壮。)

从Windows 10开始，内置驱动程序不再使用netcfg.exe安装，因此操作系统本身根本不需要netcfg.exe。但是到那时，第三方产品已经发现了它，并且对它有了依赖，所以我们不能再删除netcfg.exe了。啊，好吧。

当我们尝试安装新更新的具有不同INF的驱动程序时，为什么Windows仍然使用以前的从驱动程序存储的INF？

这是个常见的问题。请注意，在安装过程中，步骤1和步骤2之间没有关联。您可以同时安装打印机INF和LWF - netcfg.exe -l foo.inf -i bar不遗余力地确保步骤2.2中选择的“最佳”组件实际上来自步骤1中安装的INF。

为了确保您想要的驱动程序是“最佳”驱动程序，您必须确保您喜欢的驱动程序赢得了PNP驱动程序选择算法。我个人对此很感兴趣，因为我在开发迭代过程中没有碰到DriverVer行。确保每次更改驱动程序时都会增加DriverVer。

怎样才能完全删除之前的NDIS，包括从驱动程序存储中删除？如果我们需要使用pnputil从驱动程序存储中完全删除它，那么考虑到pnputil -d需要一个OEM号，那么找到OEM号的正确方法是什么？

老实说，如果您想真正正确地完成所有事情，我建议完全避免使用netcfg.exe。而是使用底层的INetCfg API。然后，安装程序必须管理驱动程序(SetupCopyOEMInf / SetupUninstallOEMInf)。

你不会因为放弃netcfg.exe和自己打电话给INetCfg而损失很多。netcfg.exe并没有对INetCfg做什么特别有趣的事情:它自己的实现几乎完全是从此示例代码中获取的。如果您从这一点开始，并给SetupCopyOEMInf打了个电话，那么您已经可以与netcfg.exe保持相当的水平了。从这里，您可以通过更健壮的INF卸载来改进它。您甚至可以编写一些代码来清点componentId中的所有INFs，以确保您的INF不会有过时的副本隐藏在周围。

从安装INF到希望INetCfgClassSetup::Install认为您最近安装的INF是“最好的”INF，您仍然必须实现这种信任的飞跃。但是，如果您已经使用该componentId删除了所有其他INF，则可以确定唯一剩余的INF必须是最佳匹配的。