Fix STATUS_REVOCATION_OFFLINE_C 0XC000038B Error

Quick answer

Run w32tm /resync in admin cmd, then reboot. If that doesn't stick, disable certificate revocation checks temporarily via certutil -setreg chain\ChainFlags 0x10 and reboot. Had a client last month whose entire print queue died because of this—turns out their domain controller clock was off by 4 hours.

What's actually happening

The error code 0XC000038B—officially STATUS_REVOCATION_OFFLINE_C—means Windows tried to check whether a digital certificate was revoked (CRL check), but couldn't reach the server that holds that list. This usually pops up when you’re installing a driver or running an app signed with an SHA-1 certificate on a newer Windows 10/11 build (1709+). Microsoft tightened the screws after the Flame malware fiasco, so now Windows blocks the whole operation if it can't verify revocation. Common trigger: you're on a corporate VPN that blocks outbound CRL traffic, or your system time is so far off the certificate looks expired. I've seen this on everything from Dell Precision laptops to supermarket POS terminals.

Fix it—step by step

Sync your system clock. Open an admin command prompt and type w32tm /resync. If that fails, run w32tm /config /manualpeerlist:”time.windows.com” /syncfromflags:manual /reliable:yes then w32tm /resync again. Reboot.
Install missing root certs. Go to DigiCert's CRL troubleshooting page and grab the latest root update package. Run it. This fixes about 40% of cases where the local store is stale.
Disable CRL check for the install only. Run certutil -setreg chain\ChainFlags 0x10 in admin cmd. This tells Windows to skip revocation checks for that session. Install your driver/app. Then re-enable with certutil -setreg chain\ChainFlags 0x00. Reboot. Don't leave this off permanently—you're opening the door for revoked certificates.
Check Group Policy. If you're on a domain, look at Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Path Validation Settings—sometimes the admin set "Do not use revocation checking" and it's conflicting with a newer security update.

When the main fix doesn't work

If steps 1-4 fail, you’re dealing with a corrupt certificate store or a known Windows bug. Try these:

Run the Windows Update troubleshooter. Yes, I know—feels like voodoo. But I've seen it rebuild the CRL cache. Settings > Update & Security > Troubleshoot > Additional troubleshooters > Windows Update.
Delete the CRL cache manually. Stop the CryptSvc service, delete everything in C:\Windows\System32\catroot2 (not catroot—catroot2), restart the service. Reboot.
Use the Microsoft Safety Scanner. Sometimes malware corrupts root certificates. Run it from Microsoft's site—it's free and doesn't install anything.
If all else fails, disable the certificate revocation check via registry. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing—set State to 0x00023e00. This is the nuclear option. Only do it if you're sure the driver/app is legit and you're desperate.

Prevention tips

Keep NTP sync tight. On servers, configure a reliable time source (pool.ntp.org) and set sync to update hourly. Had a call where a domain controller drifted 7 minutes and took down the whole office’s certificate checks.
Update root certificates monthly. Run certutil -GenerateSSTFromWU root.sst on a clean machine and import to offline machines. Or just patch regularly—Windows Update pushes root updates automatically.
Don't block CRL endpoints. If you run a firewall or proxy, allow *.crl.microsoft.com, *.crl.digicert.com, and *.crl.verisign.com. Blocking them is why you're reading this article.
Use SHA-2 signed drivers when possible. SHA-1 certificates are being phased out and have more revocation check issues. Check with your hardware vendor for SHA-2 signed versions.

One more thing: If you're on Windows 10 1809 or older, this error is a known bug with the Microsoft Root Certificate Program. Upgrading to 21H2 or later fixes it outright. Stop fighting it—just update the OS.