ERROR_IPSEC_IKE_LOAD_FAILED (0x3634): What's Actually Breaking

You set up an IKEv2 VPN or an IPsec tunnel, hit connect, and Windows spits back 0x00003634 — ERROR_IPSEC_IKE_LOAD_FAILED. The message sounds like a network problem. It isn't. What's actually happening here is the IKE and AuthIP IPsec Keying Modules service (IKEEXT) tried to load a DLL or crypto provider it needs and the load call returned a failure. That's a filesystem, registry, or integrity problem — the packets never even leave your machine.

The error surfaces most often in three situations: after a Windows Update or in-place upgrade, when running a hardened/STIG build that locks down system DLLs, and when third-party VPN clients (Cisco AnyConnect, FortiClient, Check Point) have registered their own IKE providers and something got clobbered.

Cause 1: A required IKE DLL is missing, blocked, or failing signature checks

This is the top reason you'll see 0x3634. IKEEXT loads a small set of core modules — ikeext.dll, ikmp extensions, and the crypto provider chain via bcrypt.dll and the CNG providers under System32. If any of those files are gone, quarantined by AV, or have a broken catalog signature, the load fails and IKEEXT bails out with this exact code.

Antivirus is a common culprit. I've watched Defender's attack-surface-reduction rules and a couple of EDR agents quarantine ikeext.dll after a false positive on a heuristic scan. The file isn't deleted — it's renamed to something like ikeext.dll.quarantine — so SFC can't fix it either, which is why people chase their tail on this one.

Check the files exist and the signature is valid

Open an elevated PowerShell and run:

Get-AuthenticodeSignature C:\Windows\System32\ikeext.dll | Format-List Status,SignerCertificate
Get-AuthenticodeSignature C:\Windows\System32\bcrypt.dll | Format-List Status,SignerCertificate

If Status is anything other than Valid, that's your answer. A HashMismatch or NotSigned result means the file was tampered with, partially restored from a bad backup, or swapped by an installer.

Restore the files

Run these from an elevated command prompt, in order. Don't skip DISM — SFC alone can't repair the component store, and if the store is corrupt SFC will claim everything is fine while nothing changes.

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

If your AV quarantined a file, restore it from the AV console first, then run DISM/SFC. Otherwise the repair succeeds, the AV eats it again on the next scan, and you're back to square one. Add an exclusion for C:\Windows\System32\ikeext.dll if you've confirmed it's a false positive — and file a report with the AV vendor, because their heuristic is wrong.

Cause 2: The IKE provider registry keys are pointing at nothing

IKE doesn't just hardcode which modules to load. It reads provider registrations under:

HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IkeProviders

Each subkey has a DllName value pointing at the module to load. Uninstall a third-party VPN client badly — or roll back a Windows feature update — and you can end up with orphaned entries pointing at DLLs that no longer exist. IKEEXT tries to load them anyway, fails, and returns 0x3634.

This is very common on machines that have had multiple VPN clients installed over their lifetime. I've seen a box with stale entries for both an old SonicWall client and a dead Pulse Secure install. Neither was even on disk anymore.

Inspect and clean the provider list

Export the key first — you're editing the registry and one typo can break IKE entirely:

reg export "HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT" C:\ikeext-backup.reg /y
reg query "HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IkeProviders" /s

Walk the output. For every DllName you see, verify the file actually exists in System32 or the full path listed. If it doesn't, delete that subkey. If the path looks like it belongs to an uninstalled VPN product, delete it too.

Once the registry matches the files actually on disk, restart the services:

net stop IKEEXT
net stop PolicyAgent
net start PolicyAgent
net start IKEEXT

Order matters. PolicyAgent depends on IKEEXT in some configurations, and IKEEXT won't start cleanly if PolicyAgent is wedged. If net start IKEEXT still fails, check Event Viewer under Applications and Services Logs > Microsoft > Windows > IKEEXT > Operational — it logs the specific DLL that failed to load, which saves you guessing.

Cause 3: Cryptography catalog corruption or FIPS policy conflict

Less common, but it hits hardened environments hard. IKEEXT loads CNG providers, and those providers are validated against Windows catalog files in C:\Windows\System32\CatRoot. If the catalog store is corrupted — which happens after failed updates, disk issues, or aggressive disk cleanup tools — the crypto provider load fails and IKE reports it as LOAD_FAILED.

The other flavor: someone enabled the FIPS policy (System cryptography: Use FIPS compliant algorithms) and the VPN peer is negotiating a non-FIPS cipher like 3DES or a SHA-1 hash. IKE can't load a compliant provider that satisfies the policy for the proposed transform, and the load fails.

Verify the catalog store and FIPS state

certutil -verifyctl -silent
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy" -Name Enabled

If the FIPS value is 1 and you don't have a compliance reason to keep it, set it to 0 and reboot. If you do need FIPS, reconfigure the VPN peer to propose AES/SHA-256 only — 3DES and SHA-1 are non-FIPS and will keep breaking this.

For catalog corruption, the fix is a component store repair, same as Cause 1:

DISM /Online /Cleanup-Image /RestoreHealth

Skip the third-party "registry cleaner" tools. They don't touch the catalog store and they've never once fixed this error.

Quick reference

If all three come back clean and you still get 0x3634, grab a trace with netsh trace start scenario=NetConnection capture=yes, reproduce the failure, then netsh trace stop. The IKE diagnostic events in that ETL will name the exact module the service couldn't load — after that it's a five-minute fix instead of an afternoon of guessing.