Driver Load Issues in Windows 11 HLK INF Verification: Error with AddReg Operation

Question

Driver Load Issues in Windows 11 HLK INF Verification: Error with AddReg Operation

hanish gopi 10

Hello everyone I'm using Infverif.exe tool from WDK 10.0.22621 to verify my INF file.

Command used to execute is infverif.exe /u "absolute inf file path".

For INF AddReg directive section i have created the entries as follows.

HKLM, %SmartCardName%
HKLM, %SmartCardName%,"ValueName1",0x00000001,"ValueData1" 
HKLM, %SmartCardName%,"ValueName2",0x00000001,"ValueData2"

and when I validate the file using infverif.exe tool it reports error code "1304" saying "Registry root of value 'ValueName1' is not isolated to HKR".

Referred to the error code description link https://dori-uw-1.kuma-moon.com/en-us/windows-hardware/drivers/devtest/inf-validation-errors-and-warnings and found the error can be solve by replacing the non-relative registry root value with a relative registry root value which is replacing by HKLM to HKR.

After replacing as above the infverif.exe pass the validation of INF file which is good to be.

but the driver enumeration fails by not creating those particular registry entries anymore.
Which lead to failure in complete automatic loading of the driver.
Help me figure out how to ensure my registry entries are created when the driver loads.

Windows 11 24H2 Build 26100

Dariusz Lewicki 5 Reputation points

2025-07-29T16:36:03.1933333+00:00

I am not sure if provided AddReg directive section is just a generalized one or strictly this is content of your INF directive but I am guessing it is related to smart card ATR and CSP/KSP registration within registry tree.
If this is exact content - this is wrong but I do not think this is your intended INF section content.

But your post touches general bug within inf verification logic (both local within DDK but alos within driver attestation signing portal (!) because smart card entries under HMLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards are treated differently and does not require HKR usage (according to this paths exceptions list mentioned here - https://dori-uw-1.kuma-moon.com/en-us/windows-hardware/drivers/devtest/infverif_h?source=recommendations).
But (!) proper registration of smart card related CSP/KSP and/or its miniDriver requires ALSO similar registry entry within Wow6432Node !! which is mistakenly omitted on this paths exceptions list :(
This requirement (using HKR) has been recently straightened.
When I try to validate today (July 2025) INF file of smart card miniDriver which has been successfully validated April 2025, I am getting errors 1321 ONLY for legitimate AddReg entries containing proper Wow6432Node entries.
This is wrong. Any 32bit application dealing with Microsoft CSP/KSP API and utilizing smart cards needs (!) Wow6432Node located registry keys defining this smart card.
Without correcting this by Microsoft smart cards drivers can not be properly registered for 32bit applications running on 64bit OS.
As stated on paths exception list "HMLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards" is not reported as INF error, and only Wow6432Node sibling is rejected since 2-3 months now.

Dear Microsoft Team - please update paths exceptions list of AddReg directive to contain ALSO "HMLM\SOFTWARE*Wow6432Node*\Microsoft\Cryptography\Calais\SmartCards".
Darth Tester 20 Reputation points

2025-12-12T11:41:56.5666667+00:00

Dear Dariusz,

I'm afraid there is no bug.

The official doc you mentioned clearly says, I quote:

"Over time, the requirements will become stricter and will eventually align with driver package isolation requirements."

"The InfVerif /h rulesets are aligned with the requirements of the WHCP program. The requirements are defined as the full driver package isolation requirements, with some set of exceptions applied to the requirements. Some exceptions will be removed each release until InfVerif /h enforces all driver package isolation requirements."

"Note

Any exceptions listed below should not be used, as the usage of them will no longer be allowed in an upcoming release."

There is no choice, exceptions should not be used.
Dariusz Lewicki 5 Reputation points

2025-12-12T13:03:35.4933333+00:00
It might have sens but...

the updated (stricter) rules has been introduced exactly in the same time the list of exceptions has been provided,

exceptions list addresses smart card
CSP/KSP and miniDriver up to date requirement to place some registry keys within strict registry place HKLM\SOFTWAREWow6432Node\Microsoft\Cryptography\Calais\SmartCards (for 32bit applications) and HKLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards (for 64bit applications),

I see no logic in putting one of those locations (for 64bit applications) on exceptions list and NOT including second one (for 32bit applications)... but maybe it is only me who ca not follow Microsoft's logic in this :(
Effective smart card miniDriver can not populate proper registry keys... which are ESSENTIAL for its recognition by the operating system and its smart card handling architecture.
I could (hardly...) understand the decision to phase out BOTH registry locations but just one of them? What would be the rationale of that?
As a miniDriver developer we do not have any issues to create HKR registry paths... but Windows OS has not changed and up to now looks for smart card related keys under HKLM registry paths.
Smart Card miniDriver is not typical "driver" as it is used mainly as just functional DLL by Microsoft SmartCard Base CSP/KSP modules and THOSE modules look for some smart card related registry keys Under HKLM - this is not miniDriver developer decision.
I can not find Microsoft's explanation of this conflicting requirements handling (and AI does not too ;)

1 answer

Your answer

Dariusz Lewicki 5 Reputation points

2025-07-29T16:36:03.1933333+00:00

I am not sure if provided AddReg directive section is just a generalized one or strictly this is content of your INF directive but I am guessing it is related to smart card ATR and CSP/KSP registration within registry tree.
If this is exact content - this is wrong but I do not think this is your intended INF section content.

But your post touches general bug within inf verification logic (both local within DDK but alos within driver attestation signing portal (!) because smart card entries under HMLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards are treated differently and does not require HKR usage (according to this paths exceptions list mentioned here - https://dori-uw-1.kuma-moon.com/en-us/windows-hardware/drivers/devtest/infverif_h?source=recommendations).
But (!) proper registration of smart card related CSP/KSP and/or its miniDriver requires ALSO similar registry entry within Wow6432Node !! which is mistakenly omitted on this paths exceptions list :(
This requirement (using HKR) has been recently straightened.
When I try to validate today (July 2025) INF file of smart card miniDriver which has been successfully validated April 2025, I am getting errors 1321 ONLY for legitimate AddReg entries containing proper Wow6432Node entries.
This is wrong. Any 32bit application dealing with Microsoft CSP/KSP API and utilizing smart cards needs (!) Wow6432Node located registry keys defining this smart card.
Without correcting this by Microsoft smart cards drivers can not be properly registered for 32bit applications running on 64bit OS.
As stated on paths exception list "HMLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards" is not reported as INF error, and only Wow6432Node sibling is rejected since 2-3 months now.

Dear Microsoft Team - please update paths exceptions list of AddReg directive to contain ALSO "HMLM\SOFTWARE*Wow6432Node*\Microsoft\Cryptography\Calais\SmartCards".
Darth Tester 20 Reputation points

2025-12-12T11:41:56.5666667+00:00

Dear Dariusz,

I'm afraid there is no bug.

The official doc you mentioned clearly says, I quote:

"Over time, the requirements will become stricter and will eventually align with driver package isolation requirements."

"The InfVerif /h rulesets are aligned with the requirements of the WHCP program. The requirements are defined as the full driver package isolation requirements, with some set of exceptions applied to the requirements. Some exceptions will be removed each release until InfVerif /h enforces all driver package isolation requirements."

"Note

Any exceptions listed below should not be used, as the usage of them will no longer be allowed in an upcoming release."

There is no choice, exceptions should not be used.
Dariusz Lewicki 5 Reputation points

2025-12-12T13:03:35.4933333+00:00

It might have sens but...

the updated (stricter) rules has been introduced exactly in the same time the list of exceptions has been provided,

exceptions list addresses smart card
CSP/KSP and miniDriver up to date requirement to place some registry keys within strict registry place HKLM\SOFTWAREWow6432Node\Microsoft\Cryptography\Calais\SmartCards (for 32bit applications) and HKLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards (for 64bit applications),

I see no logic in putting one of those locations (for 64bit applications) on exceptions list and NOT including second one (for 32bit applications)... but maybe it is only me who ca not follow Microsoft's logic in this :(
Effective smart card miniDriver can not populate proper registry keys... which are ESSENTIAL for its recognition by the operating system and its smart card handling architecture.
I could (hardly...) understand the decision to phase out BOTH registry locations but just one of them? What would be the rationale of that?
As a miniDriver developer we do not have any issues to create HKR registry paths... but Windows OS has not changed and up to now looks for smart card related keys under HKLM registry paths.
Smart Card miniDriver is not typical "driver" as it is used mainly as just functional DLL by Microsoft SmartCard Base CSP/KSP modules and THOSE modules look for some smart card related registry keys Under HKLM - this is not miniDriver developer decision.
I can not find Microsoft's explanation of this conflicting requirements handling (and AI does not too ;)

Answer 1

Yes, the registry entries are created, but into a different path, for instance:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class{990a2bd7-e738-46c7-b26f-1cf8fb9f1391}\0000\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards

Try to search your driver's name on registry editor starting from HKEY_LOCAL_MACHINE and you will find them.

When you use HKR, the path where registry entries are created changes, but you did not change the path you read from.

There is no choice, you have to touch driver source code.

I guess I found official doc to use registry according to isolation rules:

https://dori-uw-1.kuma-moon.com/en-us/windows-hardware/drivers/develop/driver-isolation#registry-state

Hope this helps.

Share via

Driver Load Issues in Windows 11 HLK INF Verification: Error with AddReg Operation

1 answer

Your answer