’m running into exactly the same issue with our smart card minidriver, and I can confirm it’s still unresolved as of October 2026.
What we’ve tried so far:
- Literal
HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais\SmartCardsin AddReg → InfVerif error 1304 (legacy AddReg using a non-relative key). - Native path with
FLG_ADDREG_32BITKEY→ InfVerif warning 1331. On top of that, on ARM64 the 32-bit entry ends up overwriting the native registry view underCalais\SmartCards, so it isn’t a usable workaround either. - HKR isn’t an option, since Base CSP/KSP only looks up minidrivers under
Calais\SmartCards.
As a result, our only option has been to copy the x86 DLL to SysWOW64 from the INF and register it with a separate script outside the driver package, which obviously goes against the driver package isolation requirements and isn’t a clean solution.
This puts minidriver vendors in a contradictory position: the HLK requirement explicitly says the 32-bit minidriver must be registered under Wow6432Node\...\Calais\SmartCards, while InfVerif rejects exactly that. It’s even more critical on ARM64, where 32-bit x86 applications (for example, Adobe Reader, which has no native ARM64 build) still depend on the x86 minidriver.
Could someone from Microsoft please confirm whether an exception for the Wow6432Node path is planned, or clarify what the supported way to register the 32-bit minidriver from a compliant INF is?