Fix OSS_ACCESS_SERIALIZATION_ERROR 0x80093013

This is an OSS ASN.1 serialization failure, usually hit by apps like SQL Server or SSIS when the ASN.1 DLLs are mismatched or the temp folder is locked down.

Quick answer: Re-register the OSS ASN.1 DLLs from the same install source, then make sure the account running the app has write access to the ASN.1 temp directory and %TEMP%.

OSS_ACCESS_SERIALIZATION_ERROR (0x80093013) is an OSS Nokalva ASN.1 runtime failure. It shows up when an app tries to serialize or encode ASN.1 data and the runtime can't do it — either because the DLLs are mixed versions, the temp scratch dir is locked, or the caller passed a buffer that doesn't match the schema. I've seen this most often on SQL Server 2012–2016 boxes running SSIS packages that talk to LDAP or PKI endpoints, and on older BizTalk 2013 R2 installs. It's not a Windows kernel error, even though Windows surfaces it that way. The 0x8009 prefix means it's coming from an OLE/COM component, and the component here is OSS ASN.1 (typically ossasn1.dll, snacc.dll, or asn1.dll).

Two things trigger it in the wild: a version mismatch after a patch (SQL Server CU installs love to swap one DLL and leave the rest), and an access-denied on the temp path when the service account got changed or the machine was hardened by a GPO. Both look identical at the error level. You have to check both.

Fix 1: Re-register the OSS ASN.1 DLLs

Find the OSS DLLs. On SQL Server boxes they usually sit here:

C:\Program Files\Microsoft SQL Server\110\Shared\
C:\Program Files (x86)\Microsoft SQL Server\110\Shared\

Open an elevated Command Prompt (not PowerShell — regsvr32 behaves differently there on some builds).

Re-register each one:

regsvr32 "C:\Program Files\Microsoft SQL Server\110\Shared\ossasn1.dll"
regsvr32 "C:\Program Files\Microsoft SQL Server\110\Shared\snacc.dll"

If regsvr32 returns 0x80070005 (access denied), the file is locked. Stop the SQL Server service and any SSIS-related service first, then retry.
Reboot. Don't skip this — the OSS runtime caches handle state and won't pick up new registration until the process restarts.

Fix 2: Check the temp/scratch directory permissions

The OSS runtime writes encoded buffers to a scratch path. If the service account can't write there, you get 0x80093013 every time. Default path is under the user profile:

%TEMP%\OSS_ASN1\

For a service account like NT SERVICE\MSSQLSERVER or a custom domain account, that resolves to something ugly under C:\Windows\ServiceProfiles\. Verify write access:

Log in as the account running the app (or use psexec -u).
Try creating a file in %TEMP%. If that fails, it's a profile or GPO problem, not OSS.
Grant Modify on the profile temp folder. Don't hand out Full Control — Modify is enough and won't trip your auditor.
If a hardening GPO redirected %TEMP% to a network share, that's your culprit. OSS can't do SMB serialization reliably. Move it back to a local disk.

Fix 3: Match DLL versions across the board

This one bites after SQL Server cumulative updates. Run this from an elevated prompt:

wmic datafile where "name like '%ossasn1.dll%'" get name,version,creationdate

You want every OSS DLL reporting the same version. If you've got a 12.x sitting next to a 14.x, patch one of them over the other from the CU installer. Don't try to copy DLLs from another server — the OSS builds are tied to specific SQL Server builds and mixing them causes the exact error you're already fighting.

Alternative fixes if the above fails

Repair the SQL Server instance. Run setup.exe /Action=Repair from the install media. It's slow but it restores every shared DLL to the build-consistent version. This is my go-to when the box has been patched by five different admins over three years.
Move the ASN.1 temp path off the system drive. Set the environment variable OSS_ASN1_TMPDIR to a dedicated folder like D:\OSSTmp and give the service account Modify. Removes a whole class of permission problems.
Check the calling code. If you control the app, 0x80093013 can also mean you passed a null or undersized buffer to ossEncode. Enable OSS trace logging (set OSSTRACE=1 and restart) and look for the failing PDU. It's usually a schema drift issue — a new optional field someone added to the ASN.1 definition that the runtime doesn't know about.
Roll back the last patch. If this started right after a Windows update or SQL CU, uninstall it. I've seen KB updates ship an updated msvcr120.dll that the OSS runtime doesn't bind against cleanly.

Prevention

Pin your SQL Server patch level and stop letting Windows Update push SQL-related updates. Test CUs in a staging instance before they hit production. Also, set up a monitoring alert for event ID 1000 (Application Error) referencing ossasn1.dll — catching a mismatched DLL the day it lands beats debugging it three weeks later when an SSIS package dies on a Friday night. And if the app is vendor-supplied, get the exact OSS runtime version from them in writing. Don't guess.