OSS_TRACE_FILE_ALREADY_OPEN (0X8009301C) Fix

Cause #1: A Hung Process Holding the Trace File Lock

The most common trigger for OSS_TRACE_FILE_ALREADY_OPEN (0X8009301C) is a process that crashed or was killed while writing to the OSS ASN.1 trace log. On Windows Server 2019, I've seen this after a certificate enrollment attempt gets interrupted — maybe a reboot during a renewal, or the CertSvc service stops unexpectedly while AD CS is logging.

What's actually happening here is the OSS ASN.1 runtime calls CreateFile with OPEN_ALWAYS but the previous handle never closed. The kernel knows the file isn't gone — it's just orphaned. The error code 0X8009301C maps to OSS_TRACE_FILE_ALREADY_OPEN in the Microsoft ASN.1 library, which confirms the trace file handle is already in use.

The Fix: Find and Kill the Locking Process

1. Identify the locked file. Open an elevated Command Prompt or PowerShell and run:

handle.exe -a -p * -nobanner | findstr /i "asn1"

Or, if you have Sysinternals Handle handy, this variant works better:

handle.exe -accepteula -p * asn1*.log

This lists every process with an open handle to any file matching asn1*.log. In my experience, the culprit is usually lsass.exe (if AD CS is involved) or svchost.exe hosting the Certificate Services. Write down the PID.

2. Kill it, but carefully. If it's lsass.exe, killing it will crash the system. Instead, restart the service that holds the handle:

net stop certsvc
net start certsvc

If it's a standalone application (like a custom OSS ASN.1 decoder), you can use taskkill /PID <PID> /F. Test this on a dev box first — I've seen taskkill /F on lsass cause a blue screen.

3. Confirm the file is free. Run the handle command again. You should see no handles. Then try your original operation — the error should disappear.

The reason step 3 works is the OSS runtime only checks for an existing open handle, not file system locks. Once the handle count drops to zero, the next call to ossTraceOpen succeeds.

Cause #2: Two Instances of the Same Process Running

Less common but equally annoying: you've launched two copies of a tool that writes to the same trace file path. The ASN.1 library was designed for single-instance logging. If you run myapp.exe twice, the second instance hits this error immediately.

I've reproduced this with the Windows SDK's asn1trace.exe on Windows 10 22H2. Launch it from two consoles and the second one throws 0X8009301C before writing a single byte.

The Fix: Use Unique Trace File Paths Per Instance

Don't rely on the default trace file name. Modify your application's configuration to include a unique identifier — usually the process ID or a timestamp. In a C++ application using OSSAPI, you'd set:

ossSetTraceFile( hAsn1, "trace_%d.log", GetCurrentProcessId() );

If you can't change the code (third-party binary), use a wrapper script that creates a per-instance directory:

set TRACE_DIR=C:\Logs\%COMPUTERNAME%_%RANDOM%
mkdir %TRACE_DIR%
start /b myapp.exe -trace %TRACE_DIR%\trace.log

This way each process gets its own file. The error won't occur because the paths don't collide.

One edge case: if the application hardcodes the trace file to the same path regardless of flags, you're stuck. In that case, you need to use a separate user account for each instance (via runas) so file permissions differ. That's hacky, but I've done it for a legacy app that refused to play nice.

Cause #3: Corrupted Trace File from Prior Abnormal Termination

Third possibility: the trace file itself is corrupt. The OSS library writes a header when it opens the file. If the process crashed mid-write, the header might be incomplete. On the next open attempt, the library sees a valid-looking file size but the header checksum fails — the runtime might retry the open and fail with this same error instead of a clearer one.

I've seen this happen when a VM snapshot was taken while certsvc was running. The snapshot freezes the file state, and after restore, the trace file has a partial header. The service won't restart fully because the trace file won't open.

The Fix: Delete or Rename the Stale Trace File

First, locate the trace file. By default, OSS ASN.1 logs go to %TEMP%\oss*.log or C:\Windows\Temp\oss*.log. For Certificate Services, it's often C:\Windows\System32\CertLog\. Search for any file matching *asn* or *oss* with a .log extension.

Stop the service holding the handle first (as in Cause #1), then:

del /f /q C:\Windows\Temp\oss*.log 2>nul

Or rename it instead of deleting, in case you need to debug later:

ren C:\Windows\Temp\oss_trace.log oss_trace.corrupt

Restart the service. The library will create a fresh trace file from scratch — no header checksum issues.

The reason renaming works and deleting sometimes doesn't is file system locking. If a process has already opened the file with FILE_SHARE_READ but not FILE_SHARE_DELETE, del fails silently. Renaming only needs FILE_SHARE_READ on the directory, which almost always works. Then the stale handle points to the renamed file, and the library creates a new one.

I've used this trick on Windows Server 2022 to restore AD CS enrollment without a reboot.

Quick-Reference Summary

Pick the fix that matches your situation. If you're still seeing 0X8009301C after all three, check for antivirus real-time scanning locking the trace file — I've seen that once on a heavily locked-down government server. Exclude the trace directory from AV scans as a last resort.