WSL1 m4 configure stalls on NTFS oplock owned by MsSense; subsequent instance Stop wedges

### Windows Version

Microsoft Windows 10 Pro 22H2, build `10.0.19045.7548` (KB5099539)

### WSL Version

Store WSL `2.7.10.0` (stable)

### Are you using WSL 1 or WSL 2?

WSL 1. The affected distribution is Ubuntu 24.04; its registration flags are WSL1 and the host has firmware virtualization disabled.

### Distro Version

Ubuntu 24.04 LTS; `dash` 0.5.12-6ubuntu5; glibc 2.39.

### Other Software

- Microsoft Defender Antivirus platform `4.18.26060.3008`, signatures `1.455.277.0`
- Microsoft Defender for Endpoint sensor `MsSense.exe` `10.8830.27933.1000`
- GNU m4 `1.4.20`, SHA-256 `ac6989ee5d2aed81739780630cc2ce097e2a6546feb96a4a54db37d46a1452e4`
- No third-party antivirus/filesystem-filter driver is loaded in the current boot.

### Repro Steps

A low-parallelism ROCKNIX build reached the same `m4:host` boundary on three WSL1 attempts. The visible configure output stopped at:

```text
checking for a traditional french locale...
```

The official m4 1.4.20 `configure` script first runs several locale conftests, then executes `rm -fr conftest*`, and only after that prints the result. A missing `fr_FR` locale should therefore be a quick negative result; locale absence is not itself a credible indefinite wait.

I am not reproducing again on the production host because the current LX instance is still wedged. The current retained evidence is:

1. A live WSL1 pico process named `rm`, PID 1108, started at `2026-07-22T04:00:29.5743636Z` (`2026-07-21 23:00:29.574` CDT). It still has one thread in Windows `Wait/Executive`, zero CPU time, and no normal Win32 command line/path. Its original parent PID 5608 has exited.
2. NTFS Operational Event 152, record 618, occurred at `2026-07-22T04:04:29.5987978Z`—240.024 seconds after that `rm` start—and states:

```text
Time (seconds): 240
Owner Process: MsSense.exe
Breaking Process: rm
```

3. The immediately adjacent NTFS Event 152 record 619 names both owner and breaker as `MsSense.exe`.
4. The same Event 152 pair (`MsSense.exe` owner; breakers `rm` and `MsSense.exe`; 240 seconds) also occurred during the earlier WSL1 build incident on July 19.
5. The Event 152 schema contains process names but no PID, path, or volume. Therefore the exact 240-second correlation strongly associates the retained `rm`, but does not formally prove its argv/CWD or that it is m4's cleanup process. I am preserving this distinction.
6. Accessible retained logs show no Disk, StorPort, volume-manager, VHD, NTFS-corruption, or WHEA fault in either incident window. The host had about 10 GiB free RAM and hundreds of GiB free disk space.

Microsoft's oplock documentation says that when an incompatible operation breaks an oplock, the break-causing operation is pended; synchronous I/O blocks until the oplock owner acknowledges, and there is no timeout:
https://learn.microsoft.com/windows-hardware/drivers/ifs/breaking-oplocks

After the Linux/build stall, a later WSL instance Stop left `WslService` permanently `STOP_PENDING`. A user-mode minidump of the sole surviving WslService thread shows it blocked synchronously in `NtDeviceIoControlFile` on `\Device\lxss`, IOCTL `0x00220073`. The exact WSL 2.7.10 source maps this request to the WSL1 instance-state transition (`LXBUS_IOCTL_SET_INSTANCE_STATE`). The dump and its hashes are available privately; I am not posting it publicly.

### Expected Behavior

- `rm -fr conftest*` completes, or fails with a bounded error.
- A Defender/MsSense oplock break is acknowledged promptly.
- A WSL1 instance can always be terminated without leaving WslService in an unkillable `STOP_PENDING` state.

### Actual Behavior

The strongest current causal model is:

```text
m4 configure creates/executes conftest
-> configure starts cleanup rm
-> rm requests an NTFS operation incompatible with an oplock owned by MsSense
-> MsSense does not acknowledge the oplock break
-> NTFS pends the synchronous rm operation indefinitely
-> configure/build waits behind rm
-> later WSL1 instance teardown cannot terminate/rundown the stranded pico thread
-> WslService waits forever in the lxcore instance-state IOCTL
```

The NTFS owner/breaker event and the retained `rm` wait are direct host evidence. The still-unproven links are the exact file object/path and whether PID 1108 is m4's `rm -fr conftest*` rather than a nearby diagnostic command. A kernel dump/ETW trace with the private WSL symbols should settle that.

### Diagnostic Logs

I can privately provide:

- the WslService minidump and SHA-256;
- exact NTFS/Defender/System event XML and UTC timeline;
- WSL/Windows/Defender binary versions and hashes;
- source-level mapping of the m4 configure sequence and WSL Stop request;
- a redacted host evidence report.

Because the instance is already wedged, I have deliberately not run the standard WSL collection script: it invokes `wsl.exe` and would add another blocked client. Please advise the supported Windows-only WPR/kernel-dump capture for this terminal state, or confirm that the private artifacts should be emailed to `wsl-gh-logs@microsoft.com` with this issue number.

I am also migrating the build to a fresh WSL2 clone once firmware virtualization is enabled. That removes the WSL1 syscall-translation path and is the durable prevention, but it does not retrospectively fix or explain this WSL1/NTFS/MsSense deadlock.

Start with the WSL 2.7.10 source mapping for LXBUS_IOCTL_SET_INSTANCE_STATE and the retained WslService minidump showing the blocked NtDeviceIoControlFile call. Correlate the NTFS Event 152 records with a Windows Performance Recorder or kernel-dump trace, without running the standard WSL collection script on the wedged instance. Done means identifying the deadlock path and defining a bounded WSL1 teardown or oplock-break behavior.

Written by the indexing model from the issue text.