# Windows 11 26H2 build 26300.9818: native IPv4 TCP tables report state 0 for a demonstrably listening synthetic socket

## Summary

I observed an inconsistency between a socket owned by a small standalone Python program and the state returned for that socket by Windows IP Helper APIs. The program binds an exclusive IPv4 loopback socket to port 0, calls `listen()`, reads `SO_ACCEPTCONN=1`, accepts a client, and successfully exchanges two fixed, fictional byte strings. Nevertheless, `GetTcpTable`, `GetTcpTable2`, and `GetExtendedTcpTable` with `TCP_TABLE_OWNER_PID_LISTENER` report state **0**, rather than **2**, for its listening endpoint. The corresponding connected endpoints report **5**.

This report is based on retained observations from 4 November 2026. Preparing this report did **not** run the reproducer again or change Windows. KB5127936 was installed, but I have **not** performed a local before/after removal experiment. I cannot establish that this update is the exclusive cause.

## Recorded environment

| Item | Retained value |
| --- | --- |
| Windows version/build | Windows 11 26H2, 26300.9818 |
| Update present | KB5127936; installation date reported as 2026-10-28 |
| Environment collection record | 2026-11-04T16:52:41.4771265Z |
| iphlpapi.dll file version | 10.0.26100.9949 |
| tcpip.sys file version | 10.0.26100.8875 |
| netio.sys file version | 10.0.26100.9818 |
| afd.sys file version | 10.0.26100.9949 |
| Reproducer dependencies | Python standard library only: socket, ctypes, struct, JSON and filesystem support |

The fixture output did not record the exact Python version, architecture, Windows edition or elevation level. A separate validation-environment record from the same session reports Python 3.12.10, 64-bit AMD64; it is not a direct measurement of the fixture interpreter. Different networking file versions alone do not establish an incomplete update or damaged system files. The build and update information comes from the retained environment records, not from a new inspection during report preparation.

Microsoft's [release note identifies KB5127936 as a preview update for this build](https://support.microsoft.com/help/5127936). This establishes the release association, not causation of this symptom.

## Minimal standalone reproduction already executed

The attached `minimal-repro/fixture_native_probe.py` is **byte-identical** to the retained source used for the synthetic observation. It does not import the affected application, launch an inference engine, read model files, inspect application configuration, or send HTTP requests.

Historical sequence:

1. Create an IPv4 TCP socket and set `SO_EXCLUSIVEADDRUSE`.
2. Bind to `127.0.0.1:0`, obtaining an OS-selected ephemeral port; call `listen(1)`.
3. Read `SO_ACCEPTCONN`; capture the four table variants listed below.
4. Connect a client to that exact endpoint and accept it in the same process.
5. Exchange `fictional-witness` and `fictional-ack`; capture the tables again while the listening socket remains open.
6. Close all three sockets; verify their descriptors are closed and capture the tables once more.

The APIs are called sequentially, not atomically. `GetExtendedTcpTable` uses `AF_INET=2`, `bOrder=FALSE`, `Reserved=0`, and classes 3/4. The decoder uses 32-bit unsigned fields, a 4-byte table header, and row sizes of 20/28/24 bytes for `GetTcpTable`/`GetTcpTable2`/owner-PID rows. It converts the low 16 port bits from network byte order. No state value is remapped.

The source asserts size-query return code 122 and final data-call return code 0. It permits at most three buffer-allocation attempts if the required size changes. The retained JSON records final codes, not allocation-attempt counts. This is Python/ctypes evidence, **not** a locally compiled Windows SDK witness. Review of the declarations does not independently rule out every possible decoder issue. See [GetTcpTable](https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-gettcptable), [GetTcpTable2](https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-gettcptable2), and [GetExtendedTcpTable](https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getextendedtcptable).

## Actual synthetic result

Run-start timestamp: **2026-11-04T16:53:29.120209+00:00**. Fixture PID: **39428**. Listener: **127.0.0.1:6226**. Client: **127.0.0.1:6227**. These are historical, test-only identifiers, not ports to reuse. There are no per-call timestamps.

| API / class | Before client connection: listening endpoint | During connection: listening endpoint | During connection: connected endpoints |
| --- | --- | --- | --- |
| GetTcpTable | state 0; no PID field | state 0 | both state 5; no PID field |
| GetTcpTable2 | state 0, PID 39428 | state 0, PID 39428 | both state 5, PID 39428 |
| GetExtendedTcpTable / OWNER_PID_LISTENER (3) | state 0, PID 39428 | state 0, PID 39428 | not in this table |
| GetExtendedTcpTable / OWNER_PID_CONNECTIONS (4) | empty | not in this table | both state 5, PID 39428 |

All **12 final data retrievals returned 0**, including the four calls after closure. `SO_ACCEPTCONN` was **1** and the byte exchange succeeded. After closure, the LISTENER table was empty for the test port. Other sequential calls retained a closing row with state 1/PID 0 or state 11/PID 0; that residual closing-row observation is **not** presented as another defect or a leaked listener.

Expected interpretation: **LISTEN=2**, **ESTABLISHED=5**, and **FIN_WAIT_1=6** describe different TCP states. I do not interpret **0** as LISTEN, CLOSED, or proof of ownership. The independent listening evidence here is the program's own socket, `SO_ACCEPTCONN`, and successful acceptance—not the table class name alone. [State definitions](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2); [SO_ACCEPTCONN](https://learn.microsoft.com/en-us/windows/win32/winsock/sol-socket-socket-options).

## Separate historical observations, not part of this reproducer

An earlier synthetic HTTP fixture returned HTTP 200 while CIM reported state 6 for its zero-peer endpoint and psutil labelled it FIN_WAIT1. That record lacks a TCP-sampling timestamp; its process creation time was 2026-11-04T14:49:52.553360+00:00. These interfaces may share underlying Windows facilities; their agreement is not independent kernel-level confirmation.

Two pre-existing application endpoints also produced state 0/6 zero-peer rows in native tables. A separate later health check returned HTTP 200 from both services. The package contains only selected, pseudonymized rows from that historical observation: no application names, process command lines, real service ports, executable paths or instance identifiers. It must not be conflated with the isolated fixture, or used to claim exclusive listener ownership from HTTP health. Differences among successive connected-row samples are reported as observations, not proof of a particular internal race.

## What is established, and what is not

**Measured:** the controlled listener remained open across the before/during phases, accepted a connection, and exchanged fixed bytes; all three API families returned state 0 for its listening row in the recorded run. No application-specific lifecycle code participates in this reproduction.

**Inference:** the immediate mismatch is reproducible outside the affected applications and outside their PowerShell parsers. It warrants investigation of the native enumeration path. The APIs may share underlying implementation, so this is not three independent proofs of a kernel defect.

**Not established:** the responsible layer, whether this is a regression introduced by KB5127936, whether it affects every machine on this build, or whether a driver, interception layer or decoder issue contributes. I have not performed a controlled update-removal comparison, a clean-install comparison, an IPv6 test, a trace of kernel state, or an independent compiled SDK reproduction on this machine. No third-party security driver from another person's report is attributed to this machine. This is one retained standalone run, not a measured failure rate.

A [similar Microsoft Q&A report](https://learn.microsoft.com/en-us/answers/questions/6057787/getextendedtcptable-returns-dwstate-0-for-listenin) and an [Ollama issue](https://github.com/ollama/ollama/issues/19418) provide comparison cases. They are reports by their authors, not my measurements. I have not identified an official Microsoft confirmation of this specific regression or an official fix in the referenced release information. I am not claiming that Microsoft has confirmed it.

## Questions for Microsoft

1. Is state 0 expected under any documented condition for a socket that is demonstrably listening? If so, which contract should callers use?
2. Is this pattern already tracked for build 26300.9818, and is there a supported fix or diagnostic procedure?
3. Which narrowly scoped trace would distinguish an enumeration/translation problem from the actual TCP endpoint state, without collecting unrelated traffic or disabling security controls?

The application currently refuses process-control decisions when ownership cannot be verified; this report does not propose treating state 0/6 as LISTEN.

## Attachments and verification

`observations.md` describes the chronology, provenance and redactions. `evidence/synthetic-observation.json` is an exact copy of the retained synthetic output. The public package includes sanitized environment and contextual observations, a privacy review, and SHA-256 manifests. Original private records remain unchanged and are not attached. Checksums support byte verification; they do not independently authenticate the host or prove root cause.

The reproducer README explains manual use and limitations. The public copy was not rerun when preparing this report. No Windows update was removed, no reboot or system repair performed, and no application process controlled during this documentary task.