在自定义OEM镜像中“真正启用”Synaptics触控板：不是加个驱动，而是重建输入信任链
你有没有遇到过这样的场景？
一台崭新的XPS 13或ThinkPad X1 Carbon刚刷完自研OEM镜像，开机进系统——设备管理器里赫然躺着一个黄色感叹号：“未知设备”，属性里显示硬件ID是ACPI\SYN3092；点开“鼠标和其他指针设备”，只看到灰扑扑的“HID-compliant mouse”，三指滑动没反应、四指切换桌面像在按空气、滚动像拖着砂纸……
这不是驱动没装上，而是Windows压根没把它当Synaptics用。
很多OEM工程师卡在这一步：反复DISM注入、改Unattend.xml、重签名、清缓存……最后发现，问题不在命令写错，而在于对Windows驱动加载机制的理解还停留在“复制文件→注册服务”这个表层。真正的症结，在于Windows如何决定“这个设备该用哪个驱动”——它不看厂商名字，只认三样东西：硬件ID匹配精度、签名信任链完整性、服务依赖时序闭环性。
下面，我们就从一次真实的Dell XPS 13 9315（搭载Synaptics SYNA8003）预装失败复盘出发，把整个集成过程拆解成可验证、可调试、可回溯的工程动作，而不是照搬文档的“配置清单”。
为什么“加驱动”不等于“启功能”？先破三个认知误区
❌ 误区一：“INF文件放进去，DISM一跑就完事”
真相是：DISM/Add-Driver只做两件事——把INF内容写入镜像的DRIVERS注册表项，并将.sys/.cat等文件拷贝到\Windows\System32\DriverStore\FileRepository\下的哈希命名子目录。但它不会触发PnP枚举，更不会验证驱动是否能真正加载。
你看到dism /Get-Drivers | findstr Synaptics有输出，只代表元数据注册成功，不代表驱动已就绪。就像往图书馆编目系统里登记了一本书，不等于它已经上架、能被借阅。
❌ 误区二：“Unattend.xml里配了路径，Setup就会自动装”
关键陷阱在<Path>的语义。它不是指向某个INF文件，而是告诉Setup：“请扫描这个目录下所有.inf，并按[Manufacturer]和[Models]节逐个尝试匹配当前硬件”。如果INF里写的硬件ID是ACPI\SYN0a00，而你的机器报的是ACPI\SYN3092，哪怕路径完全正确，Setup也会默默跳过——连日志都不会记一条错误，只会安静地继续装下一个驱动。
✅ 验证方法：部署后立刻查
C:\Windows\inf\setupapi.dev.log，搜索SYN3092。如果只有>>> Section start 2024/05/12 10:23:45.123但没有后续Device install finished successfully，说明INF根本没被选中。
❌ 误区三：“驱动签名只是合规要求，测试环境关掉就行”
/ForceUnsigned在DISM阶段确实能绕过签名检查，但它埋下两个致命隐患：
-.cat文件未被解析，导致PnP Customizations
