TRUST_E_BAD_DIGEST (0X80096010) – signature hash mismatch fix

You're installing a driver or running a signed executable, and Windows throws 0X80096010 – TRUST_E_BAD_DIGEST. The precise trigger: the file's embedded signature contains a hash that doesn't match what Windows computes from the file's current content. This usually hits when you download a large installer over a flaky connection, or when an IT admin repackages an MSI without re-signing it. I've also seen it with old Windows updates that were partially downloaded then interrupted.

What's actually happening here

Every signed file carries a digital signature that includes a cryptographic hash of the original file. When Windows verifies the signature, it re-calculates the file's hash and compares it to the one stored in the signature. If they differ – even by one byte – you get 0X80096010. The signature certificate itself might be perfectly valid; the problem is the digest (the hash) inside the signature no longer matches the file on disk. Common causes:

• File downloaded over HTTP without checksum verification – a single flipped bit breaks the hash
• Antivirus or security software modified the file in quarantine – some AV tools strip or alter signatures
• File was truncated by a partial download – the hash covers the whole file, but half is missing
• Developer re-compiled the binary but forgot to re-sign it – the old signature's hash is for the old binary
• Windows Update or .NET installer cache corruption – a bad bit in the cached file

Fix it – two approaches

Option 1: Re-download the file (fastest, usually works)

1. Delete the corrupted file entirely – don't just overwrite it, because Windows may cache the bad version
2. Download it again from the official source – use HTTPS, not HTTP
3. If the file has a SHA-256 checksum published (most driver packages do), verify it with certutil -hashfile file.exe SHA256
4. Run the installer again

Option 2: Clear Windows' signature cache (for system files/updates)

1. Open Command Prompt as Administrator
2. Run net stop cryptsvc to stop the Cryptographic Services
3. Delete the contents of C:\Windows\System32\catroot2 – that's the signature catalog cache. Don't delete the folder itself, just its contents
4. Run net start cryptsvc
5. Try the failing operation again

Why step 3 works: Windows caches signature validation results in catroot2. If the cache entry got corrupted (say, from a previous partial download), Windows reuses the bad hash instead of re-validating. Clearing that cache forces a fresh verification.

Option 3: Check file integrity with signtool (for developers or power users)

signtool verify /v /a file.exe

Look for Hash of file (sha256): and Signing Certificate:. If the hash line shows 0 or mismatches what you expect, the file is definitely damaged. You can also run signtool verify /pa file.exe to check only the Authenticode policy – this isolates whether the issue is the digest or the certificate chain.

What to check if it still fails

• System clock is wrong – Windows checks the signature timestamp. If your clock is set to a date before the certificate's valid-from date, the signature will fail even with a correct hash. Sync with w32tm /resync.
• Antivirus is interfering – temporarily disable real-time protection (not permanently – just to test). Some AVs, especially older ones, modify files during scanning. I've seen this with McAfee and Norton specifically.
• The file is actually unsigned – some installers embed a signature that's just a placeholder. Run certutil -dump file.exe and look for a valid PKCS7 block. If it's missing or malformed, the file was never properly signed.
• Windows version matters – on Windows 7 SP1 without SHA-2 code signing support (KB3033929), modern drivers signed with SHA-256 will fail with this error. Install the update or switch to SHA-1 signed version if available.
• Corrupt system files – run sfc /scannow. Rare, but a damaged wintrust.dll can break all signature verification.

In my experience, 9 times out of 10 it's a corrupted download or a bad catroot2 cache. Start with option 1, then option 2. If you're still stuck, check the clock and AV – those are the sneaky ones.