Diagnose native Windows process exits (0xC0000142 / 0xC0000005 / 0xC0000409) seen in extension telemetry

[eleanorjboyd]

Summary

Python Environments extension telemetry (May 25, 2026 report) shows small but real counts of native Windows process-exit codes on PET v1.33 over 7 days:

Exit code	Meaning	Events	Machines
0xC0000142	DLL initialization failure	90	11
0xC0000005	Access violation	49	12
0xC0000409	Stack buffer overrun	30	3

PET has no panic::set_hook, no catch_unwind at the JSON-RPC dispatcher, and no shutdown event. We currently cannot attribute these on our side.

Tasks

• Pull SQM IDs from the extension team for the affected cohort.
• Cross-reference with the JSON-RPC payload right before exit (the extension may have it in the last pet.process_restart event).
• Once a crash hook is in place (tracked separately), wait for repro on a real machine.

Notes

This issue is mostly blocked on data from the extension team. The fix — adding a panic hook and a crash sentinel JSON-RPC notification — will be a separate issue; this one tracks the diagnosis.

Context

Filed in response to the Python Environments extension team's May 25, 2026 regression report. Volume is small (~150 events / 7d across the three codes) but the machine counts suggest a persistent crash for a subset of users rather than a one-off. Worth diagnosing now rather than after volume grows.

[karthiknadig]

The current evidence points primarily to an attribution gap rather than a failure that the JSON-RPC dispatcher can reliably catch.

The reported Windows statuses have important limitations:

• 0xC0000142 (DLL initialization failure) can occur before Rust reaches main, so PET cannot emit a hook, log, or JSON-RPC notification.
• 0xC0000005 (access violation) is a native structured exception, not a normal Rust unwind; panic::catch_unwind and a Rust panic hook will not reliably handle it.
• 0xC0000409 is a fail-fast/stack-corruption status; executing allocation, locking, or stdout-based JSON-RPC code from that failure path is unsafe and generally impossible.

A panic hook and dispatcher-level catch_unwind could still improve diagnostics for ordinary Rust panics, but they should not be presented as coverage for these three native exit codes. A crash-time JSON-RPC sentinel is likewise unreliable because the process may terminate before it can be sent, and writing through the normal protocol from a compromised process risks corrupting stdout.

The most reliable attribution approach is to record privacy-safe breadcrumbs before failure:

1. In the extension, track each in-flight PET RPC method/request ID and its start time.
2. On PET process exit, attach the active method(s), elapsed time, and the most recent PET progress breadcrumb to pet.process_restart telemetry event.
3. Retain the latest RefreshProgress notification (refreshId, phase, locator name, elapsed times). PET already emits these, so a refresh crash can be attributed to the last observed discovery phase/locator without adding raw paths or request parameters.
4. If configure/resolve need equivalent granularity, add privacy-safe started/completed progress notifications for those operations. The extension already knows when each RPC starts, so PET-side events are most useful for internal phases rather than duplicating request-start tracking.
5. Preserve the PET version/build/commit and a bounded stderr tail in the extension's process wrapper where telemetry policy permits. Do not send raw RPC params or filesystem paths.

The PET dispatcher could emit a generic request-start notification, but the extension is the more reliable owner of this state: it knows a request was submitted even if PET fails before parsing or dispatching it, and it owns the child-process exit event. PET should supply internal phase breadcrumbs; the extension should correlate them with pending requests and the exit code.

There are also two dispatcher hardening opportunities worth tracking separately, though neither directly explains these statuses: bound accepted Content-Length before allocating the input buffer, and exit cleanly when stdin reaches EOF instead of looping on Ok(0).