Microsoft does not currently document TCP ports 4444, 4723, or 8090 stopping after KB5127936, so capture the listener’s owning process and a network trace while the failure occurs before removing the update.
KB5127936 is a preview update for Windows 11 versions 25H2 and 26H2, OS builds 26200.9818 and 26300.9818. Its documented networking fix concerns Always On VPN automatic protocol selection or fallback—not arbitrary local application listeners—and the listed known issues do not describe this behavior.^1^
Determine what happens to each listener
Start the automation tool, then run this in an elevated PowerShell window:
$ports = 4444,4723,8090
while ($true) {
Get-NetTCPConnection -LocalPort $ports -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, State, OwningProcess,
@{N='Process';E={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).Name}}
Start-Sleep -Seconds 2
Clear-Host
}
Get-NetTCPConnection reports the local address, port, state, and owning PID.^2^
Record the result immediately before and after failure:
- PID disappears: the application or helper process terminated. Check Event Viewer → Windows Logs → Application for an application-error event at that time.
- PID remains but its LISTENING entries disappear: the application closed or lost its sockets. This is primarily an application/runtime investigation, not an inbound firewall issue.
- LISTENING remains but connections fail: investigate Windows Filtering Platform, firewall, security software, or the network path. Microsoft’s TCP guidance specifically distinguishes a missing listener from traffic being dropped despite an active listener.^3^
Also record the exact Windows version:
winver
Get-ComputerInfo |
Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
KB5127936 applies only to 25H2 and 26H2. If the machine reports 24H2, verify the actual installed package and build before associating the behavior with this KB.^1^
Capture the failure without uninstalling
From an elevated Command Prompt, start a TCP/network trace:
mkdir C:\Temp 2>nul
netsh trace start scenario=NetConnection capture=yes report=yes ^
tracefile=C:\Temp\KB5127936-ports.etl
Start the automation tool, wait until its ports disappear, and then stop the trace:
netsh trace stop
Only one netsh trace session can run at a time, and the commands require elevation.^4^ The resulting ETL helps determine whether bind/close activity or dropped connection attempts coincide with the failure.
If the owning process terminates, capture a termination dump with Sysinternals ProcDump:
procdump.exe -accepteula -ma -t -w AutomationTool.exe C:\Temp\Dumps
Replace AutomationTool.exe with the actual process name. -w waits for the process to launch, -t writes a dump when it terminates, and -ma requests a full dump.^5^ Dump files can contain sensitive process memory, so share them only through the application vendor’s or Microsoft Support’s secure upload channel.
Workarounds and escalation
- Install the latest update offered under Settings → Windows Update → Check for updates. KB5127936 is a preview release; a later cumulative update is preferable if one is available for the device.
- If no later update resolves it, pause preview updates and temporarily remove KB5127936 on affected test hosts. Since uninstalling has already restored the listeners, repeating that test is unnecessary.
- Open Feedback Hub, search for
KB5127936 ports stop listening, and upvote a matching report or create a new one. Attach:- Windows edition, version, and build
- Exact automation-tool version
- Before/after PowerShell output
- The ETL trace
- Event Viewer entries or ProcDump output
- Reproduction timing and confirmation that removing KB5127936 restores operation
Feedback Hub can be opened by searching for it, and existing matching reports can be upvoted before creating a new report.^6^
At present, this should be reported as a reproducible KB5127936 compatibility regression, not as an established intended port-policy change or published known issue.
References