Windows 11 25h2 install non-WHQL WIFI driver report code 39 error

Hello VPHAN:

Thanks a lot for your answer.

According your guide, i have tried below method. There are all don't work

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Config VulnerableDriverBlocklistEnable DWORD to 0
• (gpedit.msc) and navigate to Computer Configuration > Administrative Templates > System > Device Guard. Locate the "Turn on Virtualization Based Security" policy and set it to "Disabled."
• bcdedit /set loadoptions DISABLE_INTEGRITY_CHECKS and reboot

Check the setupapi.dev.log:

setupapi.dev.log

I have added test certificate to the machine's Trusted Root store

The log returns Error 0x800b0109 and Error 0xe0000241.

But Advanced Boot Options (F8) to "Disable Driver Signature Enforcement", it worked.

What additional steps can I take to make the non-WHQL driver load stably on this machine?

Hi Peng DENG,

How are you? Has your issue been resolved yet? If it has, please consider accepting the answer so that others sharing the same problem would benefit too. If not, please get me updated. Thanks

VP

Hi Peng DENG,

The 0x800b0109 error in your logs (CERT_E_UNTRUSTEDROOT) is the smoking gun. It indicates that while the certificate is physically present in the store, the kernel does not trust it for code signing purposes. This commonly happens when a self-signed certificate is generated with "All" purposes in the UI, but lacks the specific Code Signing OID (1.3.6.1.5.5.7.3.3) in the certificate's internal "Enhanced Key Usage" (EKU) field. The Kernel loader ignores certificates that do not explicitly declare this capability.

Please perform these precise steps:

1. Regenerate a Compliant Certificate: Do not rely on the previous certificate. Generate a new one that explicitly flags itself for Code Signing.

• PowerShell Command: New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=SCM_Debug_Cert" -CertStoreLocation Cert:\LocalMachine\My
• Export this new certificate (with public key) and import it into both the Trusted Root Certification Authorities and Trusted Publishers stores on the Local Computer.

2. Embed the Signature: While PnP installs use the catalog file (.cat), the Kernel Loader (which throws Code 39) often fails if the .sys file itself is not embedded-signed in test scenarios.

Command: Use SignTool to sign both the catalog and the driver binary (.sys). signtool sign /v /s MY /n "SCM_Debug_Cert" /fd sha256 /t http://timestamp.digicert.com "C:\Path\To\scmwlan.sys" signtool sign /v /s MY /n "SCM_Debug_Cert" /fd sha256 /t http://timestamp.digicert.com "C:\Path\To\scmwlan.cat"

3. Verify Against Kernel Policy: Before attempting installation, you must verify if the driver passes the Kernel Policy check. Running this command will tell you exactly why the loader is failing:

Command: signtool verify /v /kp /c "C:\Path\To\scmwlan.cat" "C:\Path\To\scmwlan.sys"

• If this returns any error other than "Success," the driver will trigger Code 39. The /kp flag simulates the kernel's strict verification.

4. Clear Previous State

1. Run pnputil /delete-driver oem#.inf /uninstall /force to remove the old driver package.
2. Reboot the machine to flush the kernel's certificate cache.
3. Install the newly signed driver.

VP

Hello again Peng DENG,

Just following up. Refining the previous troubleshooting path regarding the Vulnerable Driver Blocklist and VBS, it is crucial to address the architectural distinction between "test-signing mode" and using a completely unsigned driver. While your BCD configuration (testsiging on) tells the Windows kernel to trust non-production certificates, it does not disable Kernel Mode Code Signing (KMCS) entirely on 64-bit builds of Windows 11. The operating system still mandates that the driver binary contains a valid signature blob and page hash, even if that signature chains to a self-generated test root. Error Code 39 in this context indicates that the kernel loader is rejecting the Senscomm binary because it is either malformed or, more likely, lacks the digital signature structure required to verify its integrity against the memory manager’s requirements. If you are attempting to install a "naked" driver with absolutely no catalog file or embedded signature, testsigning will not resolve this; that command is specifically designed to validate test-signed binaries, not unsigned ones.

To provide the most accurate resolution for your debug environment, I need to evaluate the precise state of the driver package. Please confirm if you have generated a catalog file (.cat) and signed it with a self-created certificate using SignTool, or if you are relying solely on the boot configuration to bypass checks. If the goal is to permanently load a driver without any signature, this is not supported by the standard BCD stack on Windows 11 25H2; you would temporarily need to use the Advanced Boot Options (F8) to "Disable Driver Signature Enforcement" for that specific session. However, the Microsoft recommended best practice for a stable debug environment is to use Inf2Cat to generate the catalog and then sign it with a local test certificate added to the machine's Trusted Root store. Please also review %windir%\inf\setupapi.dev.log for error 0xE000024B or 0xC0000428 to confirm if the rejection is purely signature-based or related to a deeper NDIS compatibility issue with the 25H2 kernel.

If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

VP

Hello Peng DENG,

To resolve this on a dedicated debug machine, you must ensure that the Microsoft Vulnerable Driver Blocklist is explicitly disabled, as it can override test-signing parameters if the driver's hash matches known vulnerable patterns. You can do this by navigating to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Config and setting the VulnerableDriverBlocklistEnable DWORD to 0. If the key does not exist, creating it and setting it to zero will ensure the kernel doesn't block the SCM2625 driver based on its blocklist telemetry.

Additionally, ensure that you have fully disabled Virtualization-Based Security (VBS), which can remain active even if "Memory Integrity" is toggled off in the UI. Open the Group Policy Editor (gpedit.msc) and navigate to Computer Configuration > Administrative Templates > System > Device Guard. Locate the "Turn on Virtualization Based Security" policy and set it to "Disabled." After applying this, run bcdedit /set loadoptions DISABLE_INTEGRITY_CHECKS and reboot. This ensures the kernel loader bypasses the integrity check of the driver's import table, which is a common failure point for unsigned Wi-Fi 6 adapters that rely on specific NDIS wrapper versions.

If the error persists, check the C:\Windows\inf\setupapi.dev.log file. Look specifically for the dvi: and cpy: entries during the driver installation timestamp. If you see a "Signature verification failed" or "Class installer denied" message despite your current bcdedit settings, it indicates the driver's .sys file might be missing a required NT header entry for the architecture of your 25H2 build, or the CatalogFile entry in your .inf is pointing to a non-existent or malformed .cat file. In a test-signing environment, creating a self-signed certificate and manually signing the .cat file using inf2cat and signtool is often more reliable than attempting to load a completely "naked" unsigned driver.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP