Windows: automatic filesystem tracking makes Git/MSYS sh.exe fail with MapViewOfFileEx error 487

Start with crates/fspy/src/windows/mod.rs and crates/fspy_preload_windows/src/windows/detours/create_process.rs, where the tracking DLL is injected into suspended processes and propagated to children. Then check ExecutionMode::build in crates/vt/src/session/execute/mod.rs to see when fspy is enabled. Reproduce with the probe files in the issue and vp run --cache probe. Done would mean Git/MSYS sh.exe starts cleanly under automatic tracking, verified by the probe exiting 0.

Summary

On Windows, a cache-enabled vp run using automatic filesystem tracking causes Git for Windows sh.exe to fail during startup with:

*** fatal error - MapViewOfFileEx 'shared.5'(0x11C, size 59320, m 0, created 0), Win32 error 487. Terminating.

The same Node program and shell succeed with caching disabled. Importantly, caching itself is not the incompatible part: a task with explicit inputs and outputs executes successfully and subsequently returns a cache hit, without the automatic tracking injection.

This reproduces in a standalone directory with no application code, test runner, dependencies, or parallel workers. It reproduces when launched from either PowerShell or Git Bash.

Environment

• Windows 11 Pro, build 26200
• Vite+ global and local CLI: 1.0.0
• Node.js: 26.10.0
• Git for Windows: 2.55.0.windows.3
• sh resolves to C:\Program Files\Git\usr\bin\sh.exe

These are the versions tested; I have not established the first affected release.

Standalone reproduction

Create these files in a fresh directory. An existing Windows Vite+ installation and Git for Windows on PATH are sufficient; no package installation is needed for this reproduction.

package.json

{
  "name": "msys-mapview-repro",
  "private": true,
  "scripts": {
    "probe": "node probe.cjs"
  }
}

pnpm-workspace.yaml

packages: []

vite.config.js

module.exports = {
  run: {
    cache: { scripts: true, tasks: true },
    tasks: {
      'probe:explicit': {
        command: 'node probe.cjs',
        cache: { input: ['probe.cjs', 'probe-input.txt'], output: [] },
      },
    },
  },
};

probe-input.txt

first-input

probe.cjs

const { spawnSync } = require('node:child_process');
console.log(JSON.stringify({
  node: process.version,
  FSPY: process.env.FSPY ?? null,
}));
let failures = 0;
for (const [label, command] of [
  ['direct', 'printf shell-ok'],
  ['nested', 'sh -c "printf nested-ok"'],
  ['forks', 'for i in 1 2 3; do sh -c "printf fork-ok"; done'],
]) {
  const result = spawnSync('sh', ['-c', command], {
    encoding: 'utf8',
    timeout: 10000,
  });
  console.log(JSON.stringify({
    label,
    status: result.status,
    error: result.error?.message,
    stdout: result.stdout,
    stderr: result.stderr,
  }));
  if (result.status !== 0 || result.stderr !== '') failures++;
}
process.exitCode = failures ? 1 : 0;

Run these commands from that directory:

node probe.cjs
vp run --no-cache probe
vp run --cache probe
vp run probe:explicit
vp run probe:explicit

Expected and actual behavior

Command	Observed result
node probe.cjs	All three shell launches succeed; FSPY is absent.
vp run --no-cache probe	All three shell launches succeed; FSPY is absent.
vp run --cache probe	FSPY=1; all three shell launches fail before their commands execute, with the MapViewOfFileEx error.
First vp run probe:explicit	All three shell launches succeed; FSPY is absent.
Second vp run probe:explicit	Successful output is replayed with cache hit.

The failing shell processes return 3221225794 (0xC0000142, DLL initialization failure). The probe therefore exits 1. A single spawnSync('sh', ['-c', 'printf shell-ok']) is sufficient to trigger the error; the other two cases are controls, not required concurrency or nesting.

Changing the explicitly declared probe-input.txt invalidates the explicit task cache and the task executes successfully again. The probe does not read this file: it is deliberately declared as a synthetic cache input to check invalidation.

Setting FSPY=1 manually while running the program directly also succeeds, so the environment marker alone is not the trigger.

Investigation

The A/B results isolate the automatic filesystem-tracking path. In the source inspected at revision 7d69d6577ecf6bd83deee32186de59918a712873:

• fspy/src/windows/mod.rs injects the tracking DLL into the suspended process using Detours.
• fspy_preload_windows/src/windows/detours/create_process.rs hooks process creation and propagates injection to child processes.
• vt/src/session/execute/mod.rs, ExecutionMode::build, enables fspy when either the input or output config includes automatic tracking. Explicit inputs and explicit outputs avoid that path while retaining caching.

MSYS is sensitive to its virtual-address layout and shared-memory mappings. That explains the class of failure, but I have not proven which allocation or hook causes the mapping failure inside the injected process. This report does not assume a particular native fix or claim that Windows Mandatory ASLR is the cause.

Impact and request

Cached commands that start Git/MSYS shell programs fail during child startup, even when the shell commands are trivial. Script and test harnesses that launch many such processes can emit many copies of the fatal error.

Disabling caching avoids the failure but loses cache replay. Explicit dependency declarations preserve caching and are a useful bridge, but require maintaining complete inputs and outputs. Please investigate compatibility between Windows automatic tracking/DLL injection and Git/MSYS startup, ideally retaining sound dependency tracking rather than silently skipping these processes.

---

AI attribution: This report was written by an AI coding assistant. The standalone reproduction and cache/no-cache comparisons were executed on the affected Windows machine; observations are distinguished above from the unverified native-level explanation.