STATUS_EVENT_DONE 0x40000012: TDI Event Done Meaning

STATUS_EVENT_DONE isn't a failure — it's a success code. TDI transport drivers log it when an indication completes normally. Here's why you're seeing it and what to do.

Quick answer: 0x40000012 is STATUS_EVENT_DONE — an NTSTATUS success code, not an error. You only see it because something is logging or surfacing a return value that should've been swallowed.

Here's what's actually happening. The Transport Driver Interface (TDI) is the ancient Windows kernel interface that network filter drivers — old firewalls, VPN shims, protocol hooks — use to talk to TCP/IP. When a TDI indication (basically a callback from the transport) finishes its work, the transport returns STATUS_EVENT_DONE to signal "that indication completed, move along." The value 0x40000012 is on the 0x40000000 range, which in NTSTATUS land means informational success. Not a warning. Not an error. It's the kernel equivalent of a thumbs-up.

So why are you seeing it? Because some tool is treating it as an anomaly. I've run into this most often on Windows 7 and Server 2008 R2 boxes running third-party network filter drivers — think old Symantec Endpoint clients, pre-2015 Check Point VPN clients, or a browser helper DLL that installs a layered service provider. Those drivers register a completion routine, get STATUS_EVENT_DONE back, and either bubble it up to Event Viewer or trip a debug assertion because the developer didn't expect a non-STATUS_SUCCESS NTSTATUS there. The fix isn't to make the code go away. The code is fine. The fix is to stop whoever's logging it from logging it.

Step-by-step: figuring out what's actually emitting it

Confirm it's not a real network fault first. Open an elevated command prompt and run:
```
netstat -e
netsh int ip show stats all
```
If your interface shows clean counters — no excessive discards, no interface resets — the STATUS_EVENT_DONE is cosmetic. Move on.
Find who's writing it to the log. If it's in the System event log, filter by source:
```
wevtutil qe System /q:"*[System[EventID=1]]" /f:text | findstr /i tdi
```
More often though, this shows up in a vendor application log or a Wireshark debug stream. Check the filter driver's own log directory — Symantec writes to %ProgramData%\Symantec\Endpoint Protection, Check Point to %ProgramData%\CheckPoint\CPSuite-R80\fw1\log.
Identify the TDI client. TDI is deprecated since Vista but still ships for compatibility. List loaded TDI transports:
```
driverquery /v | findstr /i "tdi tcpip"
```
Anything that isn't Microsoft-built and hooks TCP/IP is a candidate. The old-guard offenders are tcpip.sys (fine), tdi.sys (fine), and then whatever third-party driver is sitting between them.
Update or remove the offender. Nine times out of ten this is a filter driver from 2012 that was never tested against a modern kernel. Vendor updates almost always fix it because the vendor eventually noticed their completion routines were mis-classifying STATUS_EVENT_DONE. If the vendor's gone, uninstall the driver.
If it's your own code, treat 0x40000012 the same as STATUS_SUCCESS. In C:
```
if (status == STATUS_SUCCESS || status == STATUS_EVENT_DONE) {
    // indication finished, return normally
    return STATUS_SUCCESS;
}
```
The reason step 5 works is that the transport is telling you the indication is done — you don't need to take further action on that specific request. Re-queueing it or logging it as a failure is what creates the noise.

Alternative fixes when the driver won't update

Disable the TDI filter layer entirely. Open the network adapter's properties, and in the "This connection uses the following items" list, uncheck anything that isn't Microsoft. You lose that vendor's filtering, but if it's just an old AV shim that the modern AV doesn't need, that's fine. Reboot.

Suppress the log entry, not the code. If the noise is coming from Event Viewer, create a custom view that excludes the source, or set the vendor's event log to a smaller max size so it rolls over. This is a workaround, not a fix — but for a code that literally means "everything worked," it's honest enough.

Check for an LSP (Layered Service Provider). Old LSPs are the other common source. Run:

netsh winsock show catalog

Anything with a non-Microsoft, non-standard name is suspicious. Removing an LSP is a real fix, but it can break the app that installed it. netsh winsock reset as a last resort, then reboot.

Prevention

Don't install network filter drivers you don't need. That's the whole game. Every TDI filter you stack on top of TCP/IP is another completion routine that can mishandle a success code and dump noise into your logs. If you're on Windows 10 or 11, prefer WFP (Windows Filtering Platform) callout drivers — TDI has been deprecated for over a decade and the ecosystem around it is mostly abandonware. For legacy Server 2008 R2 or Win 7 systems still running this stack, keep filter drivers patched, and treat STATUS_EVENT_DONE like you'd treat STATUS_SUCCESS: acknowledge it and move on.