简介一套基于Visual Studio开发的驱动程序自动安装程序源码面向需要简化Windows驱动部署的开发者与普通用户。程序无需手工处理inf文件便可自动完成硬件检测、驱动查找、验证、复制与注册适合想学习MFC界面编程及驱动安装流程的读者。资源共15个文件以C源文件(cpp)、头文件(h)、Visual Studio工程文件(dsp/dsw)为主辅以rc、ico等资源文件完整呈现了对话框界面、安装逻辑和inf解析等核心模块。压缩包仅15KB代码精简便于快速阅读和二次修改。已有806人学习浏览。通过学习这份源码可掌握基于MFC的驱动安装工具框架、inf文件解析方法以及驱动验证与注册等关键步骤为开发类似自动安装工具提供可复用的参考实现。1. 驱动自动安装一次“放下 inf 路径”的封装很多人在新装机或给老旧设备找驱动时都经历过“找到新硬件向导”弹出后无处下手的场面设备管理器里一个黄色感叹号inf 文件明明就在那里右键“安装”却提示“无法验证数字签名”或直接报错代码 31。Windows 的驱动安装本质不是“执行”某个安装包而是由 PnP 管理器把硬件 ID 和 inf 文件中的 Models 段做匹配再把文件复制、注册表写入等动作依次执行。传统手工流程把这些细节全丢给用户而这个 VC6 时代的 MFC 工程做了一件反直觉的事把 SetupAPI 的调用链封装成一次点击。程序先登记 inf 到 DriverStore再触发 PnP 重新匹配设备用户全程只看到进度条和结果。适合驱动开发自测、装机部署和运维分发场景对工作五年以上的人值得拆的是 SetupAPI 的调用顺序、错误处理与签名校验之间的配合关系。2. SetupAPI 调用链inf 如何变成设备的“简历”双击 inf 文件选择“安装”系统背后做的事远比表面多SetupAPI 会解析 inf 里的 Version、Manufacturer、Models、DDInstall 四段结构把设备实例 ID 与硬件 ID 做比对然后按 DDInstall 段里的动作逐个执行。理解了这条调用链才知道自动安装程序到底“自动”在哪里。2.1 inf 四段式结构Version、Manufacturer、Models、DDInstall一个最小可用 inf 通常长这样[Version] Signature $WINDOWS NT$ Class Ports ClassGuid {4D36E978-E325-11CE-BFC1-08002BE10318} Provider %Mfg% DriverVer 01/01/2024,1.0.0.0 [Manufacturer] %Mfg% DeviceList, NTamd64 [DeviceList.NTamd64] %DeviceDesc% USBDrv_Install, USB\VID_1234PID_5678 [USBDrv_Install] CopyFiles DrvFiles [DestinationDirs] DefaultDestDir 12 DrvFiles 12 [DrvFiles] serial.sys [Strings] Mfg Example Corp DeviceDesc Example USB Serial Port这里最值得关注的是 Models 段里的那行硬件 IDUSB\VID_1234PID_5678。PnP 管理器枚举到设备后拿设备上报的硬件 ID 去全库匹配匹配到的 inf 才会进入安装流程。DDInstall 段USBDrv_Install则定义了具体动作比如复制哪些文件、写哪些注册表项。自动安装程序里的UpdateDriverForPlugAndPlayDevices函数参数里带的就是这个硬件 ID 字符串。各段职责可以归纳为下表inf 段作用对自动安装程序的意义Version声明签名类型、设备类 GUID、驱动版本决定 inf 能否被系统接受签名校验失败多发生在这里Manufacturer把厂商名映射到型号列表基本不用程序关心但 OEM inf 必须有Models硬件 ID 到安装段名的映射自动安装程序靠它拿硬件 ID 去匹配设备DDInstall文件复制、注册表、服务、重启动作安装时真正执行的“动作脚本”Strings字符串变量定义避免硬编码中文和路径2.2 为什么用 SetupAPI 而不是手工复制 sys 文件有人图省事把.sys直接拷贝到C:\Windows\System32\drivers再手动改注册表 HKLM\SYSTEM\CurrentControlSet\Control\Class 下的主键这样设备管理器里确实能“亮”起来但驱动没有进入 DriverStore一旦系统更新或设备重新枚举PnP 根本找不到可用的驱动瞬间回到代码 39。SetupAPI 这组函数比手工操作多做了三件正事第一SetupCopyOEMInf会把第三方 inf 复制到%windir%\INF并生成唯一的oemXX.inf编号PnP 从此把这份驱动当成“已登记”的合法驱动第二SetupDiGetClassDevs配合SetupDiEnumDeviceInfo能枚举当前在线的设备程序可以主动确认目标设备是否存在第三SetupDiCallClassInstaller或UpdateDriverForPlugAndPlayDevices会触发完整的 DIF 安装流程包括签名检查、文件复制、服务注册和重启标志计算。以下是常用函数速查表函数用途常见失败返回值SetupDiGetClassDevs获取设备信息集句柄INVALID_HANDLE_VALUESetupDiEnumDeviceInfo遍历设备信息集ERROR_NO_MORE_ITEMS 表示遍历完毕SetupDiGetDeviceRegistryProperty读设备属性如硬件 IDERROR_INSUFFICIENT_BUFFER 常见于缓冲不足SetupCopyOEMInf把 inf 登记到 DriverStore签名校验失败或路径无效SetupDiCallClassInstaller触发 DIF_* 安装动作FALSE需配合 GetLastError 排查UpdateDriverForPlugAndPlayDevices按硬件 ID 直接更新驱动FALSE常见为 ERROR_NO_SUCH_DEVINSTVC6 自带的 SDK 太老UpdateDriverForPlugAndPlayDevices的声明在 newdev.h 里这个头 VC6 没有。我一般用函数指针从 setupapi.dll 动态加载而不是直接链接这样程序在 Win2000 上也能跑只是少一个能力// VC6 工程中链接 SetupAPI并手动声明新函数 #pragma comment(lib, setupapi.lib) typedef BOOL (WINAPI *fnUpdateDriverForPlugAndPlayDevices)( HWND, PCTSTR, PCTSTR, DWORD, PBOOL); fnUpdateDriverForPlugAndPlayDevices pUpdateDriver (fnUpdateDriverForPlugAndPlayDevices)GetProcAddress( GetModuleHandle(_T(setupapi.dll)), UpdateDriverForPlugAndPlayDevices);这段代码的逻辑是先用#pragma comment(lib, ...)解决 setupapi.lib 的链接问题再通过GetProcAddress运行时获取函数入口。第 2 个参数是父窗口句柄用于安装过程中弹签名确认框第 3 个参数是 inf 全路径第 4 个参数是安装标志一般传 0第 5 个参数返回是否需要重启。如果函数指针为空说明系统版本不支持该 API就退回SetupDiCallClassInstaller的传统路线。3. Setup.cpp 主流程从对话框按钮到安装完成的分工这个工程的源码文件结构很典型InfInstallDlg.cpp管界面交互Setup.cpp管安装逻辑Setup.h暴露接口StdAfx.cpp做预编译头。拆开看安装入口被刻意放在对话框之外这是保证安装过程不卡 UI 的关键决定。3.1 源码文件里谁负责什么下载包里每个文件都有自己的活映射关系如下文件职责说明InfInstallDlg.cppMFC 对话框实现按钮响应、进度显示、结果提示InfInstallDlg.h对话框类声明定义消息处理函数和 UI 控件 IDSetup.cpp安装主逻辑枚举设备、复制 inf、更新驱动Setup.h安装接口声明暴露 DoInstallDriver 等函数StdAfx.cpp / StdAfx.h预编译头提前编译 setupapi.h减少编译时间InfInstall.dsp / .dswVC6 工程文件定义编译配置和依赖关系InfInstall.rc / resource.h对话框资源按钮、编辑框的布局和 ID 定义我拿到这类源码包第一件事是看Setup.h它决定了安装逻辑的边界输入是 inf 路径输出是成功或失败码UI 层不直接碰 SetupAPI。InfInstallDlg.cpp里要做的事其实就两件拿用户选的 inf 路径挂后台线程。设计成这样可以避免一个大坑——SetupDiCallClassInstaller在处理某些 DIF 代码时是阻塞的如果放在主线程十几秒的等待会让整个窗口变成“未响应”Windows 甚至会弹出“正在安装虚拟网络驱动程序”那种疑似卡死的假象。3.2 OnBnClickedInstall 的线程与参数传递安装按钮的响应函数把真正的工作交给后台线程// InfInstallDlg.cpp —— 安装按钮响应 void CInfInstallDlg::OnBnClickedInstall() { CString infPath; GetDlgItemText(IDC_EDIT_INF, infPath); if (infPath.IsEmpty()) { AfxMessageBox(_T(请先指定 inf 文件路径)); return; } CInstallParam *p new CInstallParam; p-infPath infPath; p-pDlg this; AfxBeginThread(InstallThreadProc, p); } UINT CInfInstallDlg::InstallThreadProc(LPVOID lpParam) { CInstallParam *p (CInstallParam*)lpParam; int code DoInstallDriver(p-infPath, p-pDlg); p-pDlg-PostMessage(WM_INSTALL_DONE, code, 0); delete p; return 0; }AfxBeginThread启动一个 worker 线程CInstallParam在堆上分配线程结束时负责删除。这里使用PostMessage而不是SendMessage的原因很实际SendMessage会等待主线程处理完消息如果主线程正在弹模态框两边互相等待就成了死锁。安装完成后主线程收到WM_INSTALL_DONE就能安全地在对话框上显示结果。参数code是DoInstallDriver的返回值用 0 表示成功非 0 表示错误码错误详情写日志而不是弹窗打断用户。3.3 Setup.cpp 的 DoInstallDriver 四步流程安装主函数的核心调用链如下// Setup.cpp —— 安装主流程 int DoInstallDriver(LPCTSTR infPath, CInfInstallDlg *pDlg) { // 1. 把 inf 交给 DriverStore生成 oemXX.inf if (!SetupCopyOEMInf(infPath, NULL, SPOST_PATH, SP_COPY_NEWER, NULL, 0, NULL, NULL)) { return LogErr(_T(SetupCopyOEMInf 失败), GetLastError()); } // 2. 枚举设备确认目标硬件 ID 在线 HDEVINFO devs SetupDiGetClassDevs(NULL, NULL, NULL, DIGCF_ALLCLASSES | DIGCF_PRESENT); // 这里省略 SetupDiEnumDeviceInfo 遍历与硬件 ID 比对过程 // 3. 按硬件 ID 触发驱动更新 BOOL reboot FALSE; if (!UpdateDriverForPlugAndPlayDevices(NULL, _T(USB\\VID_1234PID_5678), infPath, 0, reboot)) { return LogErr(_T(UpdateDriverForPlugAndPlayDevices 失败), GetLastError()); } // 4. 系统要求重启时通知用户 if (reboot) pDlg-PostMessage(WM_NEED_REBOOT); return 0; }第一步的SP_COPY_NEWER表示只在目标 inf 比已有版本新时才覆盖避免重复安装把系统里正常工作的驱动搞坏。第三步的硬件 ID 可以做成从命令行或配置文件读取这样同一份程序既能应对 USB 设备也能处理 PCIe 网卡。第 2 个参数传NULL作为父窗口句柄时必须小心UpdateDriverForPlugAndPlayDevices在需要签名确认时会弹系统对话框传NULL它也能工作但用户体验不如传主窗口句柄。整个流程如果卡住八成不是 API 调用问题而是SetupCopyOEMInf返回了签名校验失败这在第 5 章会专门展开。4. CopyFiles、AddReg 与重启标志安装动作的三大件inf 里的动作脚本由CopyFiles、AddReg、DelFiles、DelReg、AddService等指令组成。自动安装程序把这些动作交给系统执行但程序作者必须能预判每一步会落在哪里否则设备装了“能用”系统一重启又回到黄色感叹号。4.1 CopyFiles 与 DestinationDirs驱动文件去哪了看这段稍复杂的 INF[FakeDevice_Install.NT] CopyFiles DriverFiles, LegacyFiles [DestinationDirs] DriverFiles 12, Drv\FakeDevice LegacyFiles 11DestinationDirs段的数字是系统目录编号11表示C:\Windows\System3212表示C:\Windows\System32\drivers10是C:\Windows13是C:\Windows\SysWow64。常见做法是内核驱动放12用户态 DLL 放11需要 32 位兼容的应用放13。指定子目录时如12, Drv\FakeDevice表示drivers\FakeDevice子目录系统会自动创建。自动安装程序里最容易犯的错是以为把.sys复制到drivers目录就等于装完。实际上系统加载驱动时还要查服务注册表项和 DriverStore文件在不在只是第一步。我在排查代码 39 时经常看到的情况是文件确实在但HKLM\SYSTEM\CurrentControlSet\Services\某驱动的ImagePath指向了另一个不存在的路径或者文件版本与 inf 里声明的DriverVer不一致系统直接判定驱动损坏。4.2 AddReg 与注册表 Class 键设备栈为什么会乱AddReg 指令负责往注册表写设备参数下面这段的效果是往调制解调器类的第一个设备实例写一个 DWORD 值[FakeDevice_Install.NT.AddReg] HKLM, SYSTEM\CurrentControlSet\Control\Class\{4D36E97D-E325-11CE-BFC1-08002BE10318}\0000, DeviceType, 0x00010001, 1第二段的{4D36E97D-...}是设备类 GUID0000是该类下第一个设备实例的编号。安装程序在调用 SetupAPI 前应当先确认设备类 GUID 和 inf 里 Version 段的 ClassGuid 一致否则会出现设备栈错乱——把网卡驱动装到声卡类下设备管理器里能看到设备却根本不工作。实例编号是自增的设备卸载后一般不回收所以不能写死0000而应该通过SetupDiGetDeviceRegistryProperty读取现有实例的最大编号再加一。很多驱动包安装后出现“设备工作异常代码 31”原因就是注册表类键被错误覆盖到了不相关设备上。注册表 Class 键下字段的用途注册表值用途排查时看什么DriverDesc设备显示名称确认设备是否被正确识别MatchingDeviceId匹配的硬件 ID看是不是 PnP 匹配到了错误的 infInfPath使用的 inf 文件名确认是否是刚安装的 oemXX.infDriverDate驱动日期和 inf 里 DriverVer 对比版本新旧4.3 DI_NEEDRESTART 与 DI_NEEDREBOOT重启时机怎么算安装动作完成后驱动是否立即生效取决于 PnP 是否重枚举了设备。UpdateDriverForPlugAndPlayDevices的最后一个参数reboot返回TRUE时表示该驱动必须重启系统才能加载。对网卡这类热插拔设备重启设备而非系统往往就能生效SP_DEVINSTALL_PARAMS params; params.cbSize sizeof(params); SetupDiGetDeviceInstallParams(devs, devInfo, params); params.Flags | DI_NEEDRESTART; SetupDiSetDeviceInstallParams(devs, devInfo, params); SetupDiCallClassInstaller(DIF_PROPERTYCHANGE, devs, devInfo);DIF_PROPERTYCHANGE 配合SP_DEVINSTALL_PARAMS里的DI_NEEDRESTART标志会让 PnP 管理器停掉并重新启动设备。设置标志时必须先调SetupDiGetDeviceInstallParams读取现有 Flags再按位或新增标志直接赋值会把系统预设的标志清零。这个技巧尤其适合处理“正在安装虚拟网络驱动程序卡住了”这类场景——虚拟网卡安装其实已经完成只是设备还挂着一个需要重启的旧驱动栈触发 DIF_PROPERTYCHANGE 比让用户重启整个系统快得多。5. 用 setupapi.dev.log 与注册表反查代码 31 / 39设备管理器里的代码 31 和代码 39 是驱动安装程序最常见的两种失败结果但错误码本身不提供细节真正的线索在C:\Windows\INF\setupapi.dev.log。每次手动或自动安装尝试都会在这个日志里追加一段记录失败行通常以!!!开头后面跟着错误码和失败原因。常见的做法是先看尾部再定位具体的失败段。Get-Content C:\Windows\INF\setupapi.dev.log -Tail 80 | Select-String !!! -Context 2,6-Tail 80只取最近 80 行!!!开头的行是错误标记-Context 2,6输出错误行前 2 行和后 6 行方便看清是哪个操作失败。重点看两处一处是sig关键字附近的签名校验信息——“Driver package failed signature validation”说明 inf 没通过数字签名验证另一处是File相关行如果CopyFiles找不到源文件会报类似Cannot copy ...的错误。代码 31 和代码 39 的根因不同。代码 31 表示系统始终没有可用驱动最常见的是“第三方 inf 不包含数字签名信息”或“Windows 无法验证此设备所需的驱动程序的数字签名”——x64 系统默认强制签名校验未签名 inf 在SetupCopyOEMInf阶段就会被拒绝根本走不到文件复制。代码 39 则说明 PnP 匹配到了驱动但加载失败去HKLM\SYSTEM\CurrentControlSet\Control\Class\{设备类GUID}\对应实例下查InfPath和DriverDate如果InfPath指向的还是旧 oemXX.inf说明本次安装的 inf 根本没被采用。排查时还有一个常用技巧对比 DriverStore 里登记过的驱动版本。C:\Windows\System32\DriverStore\FileRepository下能找到所有已批准的驱动包如果刚复制进去的.sys不在任何以 inf 名命名的目录里说明SetupCopyOEMInf实际没有成功问题出在签名阶段而不是后续调用。通过注册表确认InfPath的时间戳和生成号就能判断 PnP 到底采用了哪一份驱动剩下的事情就是带着 setupapi.dev.log 的错误行号和注册表截图去逐段排查。本文还有配套的精品资源点击获取