--- name: lnk1104-on-the-exe-you-are-producing-is-the-previous-runs-cell-holding-it description: LNK1104 "cannot open file -.exe>" during a rig iteration = the PREVIOUS run's test process still alive holding the exe, not a link/code fault metadata: type: feedback --- `LINK : fatal error LNK1104: cannot open file ...\target\debug\deps\-.exe` on the second edit of a rig fix reads as "my patch broke the link". It is a FILE LOCK: the previous run's role (hertz F19 run 2, 2026-09-07: role A pid 38124 spent its full 240 s WAIT printing NODE_UNAVAILABLE at a B that had died at a precondition assert) still holds the exe, and the new build cannot replace it. One pool, one rig at a time. **Why:** a two-role rig whose roles die asymmetrically leaves the survivor running to its deadline; a relaunch inside that deadline collides at the link step, and the error names the code you just touched. **How to apply:** before relaunching a rig into a pool, census Win32_Process by ExecutablePath under the worktree/pool and wait for holders=[] (chain the launch on the empty census, cap it, and GIVE UP loudly rather than launch held). A build.exit 101 whose text is LNK1104 on your own test exe is VOID, not a red — read the holder census before the diff. See [[a-nextest-timeout-does-not-kill-the-cells-children]], [[e2e-leaked-daemons-shared-box]].