0X8009300E

Fix OSS_MEM_ERROR (0X8009300E) in Windows

Windows Errors Intermediate 👁 6 views 📅 Jun 29, 2026

This error means Windows ran out of memory processing ASN.1 data — usually from corrupt certificates or bad VPN configs. Here's how to fix it.

Most Common Cause: Corrupt Certificate Store

The error 0X8009300E shows up when Windows runs out of memory decoding ASN.1 data — not system RAM, but memory inside the certificate store. What's actually happening here is the certificate parsing engine (CryptoAPI) hits a malformed block and can't allocate more internal buffers.

I've seen this most often on domain-joined machines after a failed certificate auto-enrollment. You'll get the error when opening certlm.msc or during sysprep.

Fix 1: Delete the corrupt machine keyset

  1. Open Command Prompt as Administrator.
  2. Run:
    certutil -delstore MY "<thumbprint>"
    (replace with the thumbprint of the problematic cert — find it in Event Viewer under System, Source: Schannel, Event ID 36888 or 36874).
  3. If you don't know which cert is bad, nuke the whole machine store:
    certutil -delstore -user MY
    (yes, it's drastic — but the OS rebuilds it on next boot).
  4. Reboot.

The reason step 3 works is because certutil -delstore empties the volatile memory cache tied to the MY store. On next boot, Windows re-reads certificates from disk — corrupt ones fail silently and get skipped.

Second Most Common Cause: VPN Configuration Using ASN.1

If you're using a VPN client (SSTP, L2TP, or IKEv2) and see 0X8009300E in connection logs, the VPN server sent a certificate chain that's too large for the client's ASN.1 decoder. This is a known problem with Windows 11 22H2 and newer connecting to older SSTP servers.

Fix 2: Reduce VPN certificate chain size

  1. On the VPN server (if you control it), export the server certificate without intermediate CAs:
    openssl pkcs12 -export -in server.crt -inkey server.key -out server_noint.pfx -chain -CAfile root.crt -nodes
    (the -chain flag includes only the root, not intermediates).
  2. On the client, clear cached VPN certificates:
    certutil -user -delstore -enterprise Root
    (this removes all enterprise root certs — be careful in a domain environment).
  3. Restart the VPN service:
    net stop RasMan && net start RasMan

Skip the registry tweaks you see online — they don't fix the memory issue. The real fix is trimming the certificate chain so Windows doesn't choke on large ASN.1 blobs.

Third Cause: System File Corruption (rare)

Sometimes the OSS ASN.1 library itself gets corrupted. This happens after a failed Windows Update or a disk write error. You'll see 0X8009300E in random places — opening Device Manager, running DISM, even logging in.

Fix 3: Repair system files

  1. Run SFC first:
    sfc /scannow
    (let it finish even if it looks stuck).
  2. Then run DISM:
    DISM /Online /Cleanup-Image /RestoreHealth
    (this replaces corrupt files in the component store).
  3. Reboot and test.

Why this order? SFC fixes user-mode files first; DISM fixes the system image underlying those files. If you run DISM first, SFC might still find corruption in files DISM couldn't restore. Not doing both means you're only half fixing it.

Quick-Reference Summary Table

Cause Fix Time to complete
Corrupt certificate store (most common) Run certutil -delstore MY to clear volatile cache 10 minutes
VPN certificate chain too large Export server cert without intermediates, clear client root store 20 minutes
System file corruption Run SFC then DISM 30-60 minutes

Was this solution helpful?