OSS_MORE_BUF (0X80093001): Fix the OSS ASN Buffer Error

What OSS_MORE_BUF (0X80093001) Actually Means

OSS_MORE_BUF is a return code from the OSS Nokalva ASN.1 runtime. It gets raised when the decoder walks into a buffer that's smaller than the encoded data it's trying to unpack. The 0X80093001 value is what Windows surfaces when that library call fails inside a service, a smart card middleware, or a certificate chain validator.

Plain English: something handed the ASN.1 decoder a shoebox and asked it to fit a suitcase inside. The decoder did the right thing and refused.

You'll run into this most often with smart card readers, VPN clients that validate client certificates, LDAP tools talking to Active Directory, and older Java-based enterprise apps that bundle their own ASN.1 stack. I've seen it hit three users on the same Tuesday because a certificate authority rolled out a new intermediate cert with a longer serial number than the decoder's hardcoded buffer allowed.

Before You Start — What to Gather

• Which app threw it. The event viewer entry is almost always under Application, not System.
• Whether it started after a Windows update, a cert renewal, or a driver install.
• The exact cert or smart card involved, if there is one.

Write these down. You'll need them if you end up at the advanced section.

Step 1 — The 30-Second Fix: Restart the Service, Not the Machine

Most OSS_MORE_BUF hits come from a service that cached a stale certificate or token buffer and never refreshed it. Restarting the whole PC works, but it's slow and you're going to do it again tomorrow. Restart the specific service instead.

1. Press Windows key + R, type services.msc, and press Enter. The Services window opens.
2. Look for the service tied to your problem app. Common names: Smart Card, Certificate Propagation, ScDeviceEnum, or the branded service for your VPN client (Cisco AnyConnect, GlobalProtect, etc.).
3. Right-click the service and choose Restart. If Restart is greyed out, click Stop, wait five seconds, then Start.
4. Trigger the original action that threw the error.

You should see the operation finish without the OSS_MORE_BUF popup. If it still fails, the buffer wasn't the transient kind. Move on.

Step 2 — The 5-Minute Fix: Clear the Certificate Cache and Re-Enroll

This is the real fix for the majority of cases I've handled. The decoder is fine. What's broken is a certificate in your personal store that's been replaced on the server side, and your local stack is still holding the old DER blob with a truncated extension.

1. Press Windows key + R, type certmgr.msc, press Enter.
2. Expand Personal and click Certificates. Sort by Expiration Date.
3. Look for anything marked with a yellow warning, anything expiring in the next 24 hours, or anything issued in the last 48 hours that duplicates an older entry.
4. Right-click the suspect cert, choose Delete, and confirm.
5. Close certmgr. Open Command Prompt as Administrator and run:

certutil -pulse
certutil -scinfo

The first command forces the certificate enrollment client to wake up and pull a fresh cert. The second dumps smart card info — you'll see a fresh cert listed with today's timestamp.

Now retry the action. If OSS_MORE_BUF is gone, you're done. If it comes back within minutes, the server is issuing something your local decoder can't handle. That's step 3.

Skip the "delete all personal certs" advice you'll find on some forums. It nukes your EFS keys and you'll be reissuing certs for a week.

Step 3 — The 15-Minute Fix: Update the ASN.1 Runtime and the Driver Stack

If the buffer error is deterministic — same action, same failure, every time — you've got an outdated decoder. The OSS ASN.1 library that ships inside Windows smart card middleware and several enterprise apps hasn't kept pace with the longer key identifiers and custom extensions that modern CAs hand out.

3a. Update the smart card middleware

1. Identify your reader's vendor. Open Device Manager (Windows key + X, then M). Expand Smart card readers.
2. Note the exact model. Examples: Yubico YubiKey OTP+FIDO+CCID 0, Identiv SCR3310 v2.0, Gemalto IDBridge CT30.
3. Go to the vendor's download page. Don't use Windows Update for this. It still ships 2019-era middleware for several readers.
4. Install the current driver AND the middleware package (they're separate downloads on most vendor sites).
5. Reboot when prompted.

3b. Update the OSS ASN.1 runtime in the failing app

If the error comes from a Java or .NET app you control, check its bundled runtime version. Older builds of the OSS Nokalva runtime cap default buffers at 4KB. Anything bigger and you get OSS_MORE_BUF. You'll find the version string in one of two places:

• A DLL in the app folder: osssys32.dll or osssys64.dll. Right-click, Properties, Details tab. Version 8.x and earlier are the usual offenders.
• A JAR in a Java app: look for oss.jar or asn1rt.jar in WEB-INF/lib or the classpath.

Upgrade to a current release from Nokalva. If you can't upgrade, the workaround is to set an environment variable before launching the app so the decoder allocates a bigger default buffer:

set OSS_BUFFER_SIZE=65536

Run that in the same command prompt you use to start the app. If you're launching from a shortcut, add it to the shortcut's target line prefixed with cmd /c.

3c. Check for a corrupted registry blob

One more stop before you call the vendor. Smart card enrollment caches a binary blob here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\Readers

If a subkey under Readers matches your reader model but the values look empty or truncated, rename the subkey (don't delete it — you'll want it back if this wasn't the cause) and reboot. Windows rebuilds it on next insertion.

After renaming, insert the smart card. You should hear the reader chirp and see the cert appear in certmgr within about 20 seconds.

If It Still Fails — What to Capture Before Calling Support

You've ruled out transient state, stale certs, and outdated middleware. At this point the buffer error is coming from the server side — your CA is pushing an ASN.1 structure the client legitimately can't decode. Grab this and send it:

1. Run certutil -scinfo -v > scinfo.txt in an admin command prompt. The -v flag dumps the raw ASN.1 bytes.
2. Open Event Viewer, filter Application logs by source matching your app, and export the last 24 hours as CSV.
3. Note the middleware version (from Device Manager, driver tab) and the app build number.

Vendor support will ask for the raw ASN.1 dump nine times out of ten. Having it ready saves you a full day of back-and-forth.

Quick Reference

Work the steps in order. Nine out of ten OSS_MORE_BUF cases close out at step 2 without ever touching a driver.