TRUST_E_PROVIDER_UNKNOWN (0x800B0001) in Windows 10/11
This error appears when Windows can't verify a signed file's trust provider. It's a security check failure, not a malware infection.
When You'll See This
You're trying to install a signed driver or run a legit piece of software on Windows 10 or 11. The installer stops, or you get a dialog that says "Unknown Publisher" with the error code 0x800B0001. Maybe it's a printer driver from Canon or an old VPN client. The file is signed, but Windows can't figure out who signed it.
This isn't malware. It's a configuration problem. The trust provider—the component that decides if a certificate is valid—can't do its job. The file itself is often fine.
Root Cause
What's actually happening here is that Windows relies on a set of DLLs called "trust providers" to verify digital signatures. These live in %SystemRoot%\System32\—files like wintrust.dll, crypt32.dll, and softpub.dll. When the system can't find or load the right trust provider for the signature type being checked, it returns the TRUST_E_PROVIDER_UNKNOWN error.
The most common triggers:
- Corrupted system files—a bad Windows update or disk error broke
wintrust.dllor its dependencies. - Third-party security software that hooks into certificate verification—some antivirus tools replace trust providers with their own, then fail when the file's signature format isn't supported.
- Missing registry entries for trust providers under
HKLM\SOFTWARE\Microsoft\Cryptography\Providers\Trust. If those are deleted or modified, Windows has no map for which DLL to call. - SHA-2 signature issues on older Windows 10 builds—though this is rarer now, some early builds didn't fully support SHA-2 certificates.
The reason step 3 works in the fix below is that re-registering the trust provider DLLs forces Windows to rebuild the registry mapping for certificate validation. regsvr32 doesn't just register a COM component; it also triggers the DllRegisterServer entry point in these DLLs, which rewrites the correct registry keys.
How to Fix It
Step 1: Run SFC and DISM
Before touching anything else, rule out system file corruption. Open an elevated Command Prompt (right-click Start > Windows Terminal (Admin) or Command Prompt (Admin)). Run these in order:
DISM /Online /Cleanup-Image /RestoreHealth
Wait—this can take 5–15 minutes. It uses Windows Update to fix the component store. Then:
sfc /scannow
Let SFC finish and reboot. If this alone clears the error, your problem was file corruption. Skip to the "Still Fails?" section. If not, move on.
Step 2: Re-register Trust Provider DLLs
This is the real fix for 90% of cases. Run these commands in the same admin prompt:
regsvr32 /s wintrust.dll
regsvr32 /s crypt32.dll
regsvr32 /s softpub.dll
regsvr32 /s mssip32.dll
regsvr32 /s initpki.dll
The /s flag suppresses success messages. You won't see a dialog unless something errors. If any command fails with a specific error, note it—that tells you which DLL is missing or can't self-register.
After running all five, reboot and test your original install. If the error's gone, done. If not, next step.
Step 3: Check the Trust Provider Registry
Open regedit.exe as Administrator. Navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Providers\Trust
You should see subkeys like DrvGood, DrvUnknown, FinalProv, Revocation, etc. Each should have a DLL value pointing to the correct file (e.g., wintrust.dll). If any key is missing or has an empty/wrong DLL value, that's your culprit.
If you're missing the entire Trust key entirely—which shouldn't happen, but I've seen it after aggressive registry cleaners—you'll need to manually recreate it. Export a matching key from a healthy Windows 10/11 system (same build version) and import it. This is advanced; if you don't have a healthy system nearby, reinstall Windows instead of trying to reconstruct from memory.
Step 4: Disable Third-Party Security Temporarily
If you're running McAfee, Norton, Bitdefender, or any security suite that does SSL inspection or certificate validation, disable it completely (not just pause) for a test. Reboot, then try your install again. If it works, you know the security software is intercepting the trust provider calls. Either configure it to exclude the specific files you're verifying, or contact the vendor for a fix.
Still Fails?
If you've done all four steps and the error persists:
- Check your antivirus exclusion list. Some suites, especially Webroot and Malwarebytes, are known to block
regsvr32operations on trust provider DLLs. Temporarily uninstall (not just disable) the security software, reboot, and re-run Step 2. - Verify the file's signature manually. Run
sigcheck -t -h file.exefrom Sysinternals. This will tell you exactly which signature method failed and why. It gives different output than the built-in explorer properties. - Check for pending Windows updates. Sometimes a partial update leaves the trust provider infrastructure in a broken state. Install all pending updates, reboot, and try again.
- As a last resort, use the Windows Media Creation Tool to do an in-place upgrade. This reinstalls Windows while keeping your apps and files. It's the nuclear option—it replaces every system file, including the trust provider DLLs and registry, without wiping your data. Make sure you have a backup anyway.
The 0x800B0001 error is frustrating because it looks like a security problem, but it's really just a broken link in the chain. Fix the link, and Windows will trust your file again.
Was this solution helpful?