Repository navigation
Diagnose native Windows process exits (0xC0000142 / 0xC0000005 / 0xC0000409) seen in extension telemetry #1694
Description
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_restartevent). - 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.
Activity
karthiknadig commentedon Aug 6, 2026
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 reachesmain, 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_unwindand a Rust panic hook will not reliably handle it.0xC0000409is 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_unwindcould 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:
pet.process_restarttelemetry event.RefreshProgressnotification (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.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-Lengthbefore allocating the input buffer, and exit cleanly when stdin reaches EOF instead of looping onOk(0).