You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dev Proxy tracks detached instances by PID alone (state-<pid>.json), and StateManager determines whether an instance is "alive" purely by checking whether a process with that PID currently exists (StateManager.IsProcessRunning(int pid) → Process.GetProcessById).
Operating systems recycle PIDs. After an instance exits (cleanly or via crash), its PID number can be reassigned to a completely unrelated process. When that happens:
IsProcessRunning(pid) returns true for the stale state record, so Dev Proxy believes its old instance is still alive.
Commands that key on liveness (stop, status, LoadAllStatesAsync, FindSystemProxyInstanceAsync, and the crash-recovery / orphaned-system-proxy reconciliation added in the stop --force fix) can act on — or refuse to act on — the wrong process.
This is a pre-existing, low-probability correctness issue in the whole detached-instance design; it is independent of any single command.
Suggested fix
Store additional identity beyond the PID in the state file and verify it before treating a PID as "our" live instance. Options:
Persist the process start time (Process.StartTime) alongside the PID, and in IsProcessRunning compare the running process's start time to the recorded value — a mismatch means the PID was reused and the record is stale.
Optionally also persist the process name / a Dev Proxy marker as a secondary check.
Process.StartTime is available cross-platform in .NET and is the standard, low-cost way to disambiguate PID reuse.
Notes
Found while implementing the fix for devproxy stop --force cannot restore the system proxy after a crashed instance #1731 (devproxy stop --force cannot restore the system proxy after a crashed instance). That fix relies on asSystemProxy state records to reconcile orphaned system-proxy registrations; PID-reuse hardening would make that reconciliation (and all liveness checks) more robust but is intentionally out of scope for that change.
Description
Dev Proxy tracks detached instances by PID alone (
state-<pid>.json), andStateManagerdetermines whether an instance is "alive" purely by checking whether a process with that PID currently exists (StateManager.IsProcessRunning(int pid)→Process.GetProcessById).Operating systems recycle PIDs. After an instance exits (cleanly or via crash), its PID number can be reassigned to a completely unrelated process. When that happens:
IsProcessRunning(pid)returnstruefor the stale state record, so Dev Proxy believes its old instance is still alive.stop,status,LoadAllStatesAsync,FindSystemProxyInstanceAsync, and the crash-recovery / orphaned-system-proxy reconciliation added in thestop --forcefix) can act on — or refuse to act on — the wrong process.This is a pre-existing, low-probability correctness issue in the whole detached-instance design; it is independent of any single command.
Suggested fix
Store additional identity beyond the PID in the state file and verify it before treating a PID as "our" live instance. Options:
Process.StartTime) alongside the PID, and inIsProcessRunningcompare the running process's start time to the recorded value — a mismatch means the PID was reused and the record is stale.Process.StartTimeis available cross-platform in .NET and is the standard, low-cost way to disambiguate PID reuse.Notes
devproxy stop --forcecannot restore the system proxy after a crashed instance #1731 (devproxy stop --forcecannot restore the system proxy after a crashed instance). That fix relies onasSystemProxystate records to reconcile orphaned system-proxy registrations; PID-reuse hardening would make that reconciliation (and all liveness checks) more robust but is intentionally out of scope for that change.DevProxy/State/StateManager.cs(IsProcessRunning,LoadStateFromFileAsync,GetOrphanedSystemProxyStatesAsync),DevProxy/State/ProxyInstanceState.cs.