[GH-ISSUE #1701] [Bug] Windows native authority self-test fails on real Windows: "Delete owned object by handle failed" (Win32 5), and leaves probe directories behind #568

Open
opened 2026-10-15 18:26:15 +00:00 by bsakaguchi · 22 comments
Owner

Originally created by @koljs on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1701

Summary

On a real Windows 11 x64 host, rea doctor reports the Windows native authority capability as unavailable, which hard-gates the Ghidra provider off. The reported cause is the bundled addon's own load-time self-test failing to remove an object it just created:

ghidra-native_authority  ok: false  classification: unsupported_host
  REA Windows native controls are unavailable: Delete owned object by handle failed
  [C:\Users\<user>\AppData\Local\Temp\rea-native-probe-<32hex>] (Win32 5): access denied

Ghidra itself is detected perfectly — 8 of the 9 provider checks pass. Only native_authority fails.

I believe this is an addon-internal defect rather than a host constraint: every underlying operation involved succeeds when performed directly on this machine. Details and controlled experiments below.

Environment

REA:        rea-agents 6.4.0  (reproduced identically on 6.3.0)
Host:       Windows 11 x64 (os.version 10.0)
Node:       v22.22.2
Ghidra:     12.1.4 PUBLIC  (application.version=12.1.4)
JDK:        Microsoft OpenJDK 21.0.12.1+1 LTS (64-bit, full JDK, javac present)
Volume:     C: NTFS, fixed disk, FILE_PERSISTENT_ACLS = true

Reproduction

$env:GHIDRA_INSTALL_DIR = "C:\tools\ghidra_12.1.4_PUBLIC"
$env:JAVA_HOME          = "C:\tools\jdk-21.0.12.1+1"

rea doctor --provider ghidra --json

Result:

id        : ghidra
configured: True
available : False
version   : 12.1.4
checks    :
   configuration        ok=True   code=None
   platform             ok=True   code=None   win32
   architecture         ok=True   code=None   x64
   installation         ok=True   code=None   ...\Ghidra\application.properties
   version              ok=True   code=None   12.1.4
   headless             ok=True   code=None   ...\support\analyzeHeadless.bat
   native_decompiler    ok=True   code=None   ...\decompiler\os\win_x86_64\decompile.exe reports pe x86_64
   java                 ok=True   code=None   21.0.12.1; 64-bit; JDK
   native_authority     ok=False  code=unsupported_host
                                       REA Windows native controls are unavailable:
                                       Delete owned object by handle failed [...] (Win32 5)

No environment variable or configuration changes this. The gate is enforced in
GhidraProvider.inspectAvailability(), in the session-open path, and independently
in WINDOWS_P0_CAPABILITIES (GhidraProviderCapabilities.ts) — the table
BinarySessionExecution.prepareSessionExecution() consults.

Expected

With a conforming Ghidra 12.1.4 + JDK 21 installation and a bundled native artifact
whose manifest, ABI, Node-API version, PE architecture, and SHA-256 all validate,
the native authority self-test should pass and the Windows Ghidra P0 lane should be
reachable.

Evidence 1 — the self-test leaks the object it fails to delete

Every run leaves a directory behind in the OS temp directory. After ~14 runs:

$ ls -d $env:TEMP\rea-native-probe-*
...\rea-native-probe-39113ba0382648e65b5a727ccf513e74
...\rea-native-probe-797b6742463e99b93c431efe43004028
...\rea-native-probe-8eea686cc06802803e571270b4232123
...   (14 total, all empty directories, all 0 bytes)

So object creation succeeds; only removal fails. The object is a directory,
and it is empty.

Its security descriptor is exactly what REA intends — protected, owner correct,
current user holding full rights:

O:<user>  G:Users
D:P(A;OICI;FA;;;<user>)(A;OICI;FA;;;SY)

FA (FILE_ALL_ACCESS) includes DELETE, so the DACL is not the problem.

Evidence 2 — Win32 5 maps to "the handle used lacks DELETE access"

Controlled experiments on this host, deleting an empty directory through a handle
opened with FILE_FLAG_BACKUP_SEMANTICS:

Handle access mask SetFileInformationByHandle(FileDispositionInformation)
DELETE | FILE_LIST_DIRECTORY ok, err=0, object gone
FILE_READ_ATTRIBUTES only err=5 ACCESS_DENIED, object remains

And, to rule out the "not empty" explanation:

Case Result
directory not empty, handle has DELETE err=145 (ERROR_DIR_NOT_EMPTY) — not 5

So Win32 5 here is the signature of a handle without DELETE access being used
to mark the object for deletion, which matches the observed failure exactly.

Evidence 3 — everything else on the host works

Performed directly on this machine, all successful:

Operation Result
SetFileInformationByHandle(FileDispositionInformation) on a file ok
…on an empty directory ok
…on a directory with a protected user+SYSTEM DACL ok
NtSetInformationFile(FileDispositionInformationEx) — DELETE (0x1) ok
…DELETE | POSIX (0x3) ok
…DELETE | POSIX | IGNORE_READONLY (0x7) ok
NtCreateFile with an inline protected security descriptor ok
Volume supports FILE_PERSISTENT_ACLS true

The native artifact itself loads fine — package version, ABI 1, Node-API 8, PE x64,
and SHA-256 all validate. Only the inspect self-test fails.

Ruled out

  • Temp directory location — reproduced identically under three different parents
    (%LOCALAPPDATA%\Temp, a directory on C:\, and a directory under the user profile).
  • Reparse points — no component of the temp path carries a reparse tag.
  • Restricted token — TokenRestrictedSids group count is 0; the process runs as
    the ordinary user with a normal High-integrity token (Administrators, Users,
    Authenticated Users present).
  • Antivirus — Windows Defender real-time protection is disabled by policy and no
    third-party AV product is registered.
  • Elevation — token integrity is High, not elevated.
  • Volume type — NTFS, fixed, persistent ACLs.

Impact

On Windows, everything requiring a deep-analysis provider is unavailable:
open_binary, binary_overview, batch_decompile, get_call_graph, xrefs,
procedure_pseudo_code, analyze_function, trace_feature, and native function
dossiers. Provider-independent tooling works fine.

Secondary impact: the failed self-test leaks a directory into the OS temp directory
on every run
, with no cleanup path.

Relationship to existing issues

  • #527 (Windows Ghidra hard-gated off) — closed, and the maintainer noted the
    closure pass ran no real Windows tests. That issue covered the period when
    WindowsAuthority.ts returned notProven unconditionally; the native addon now
    exists and is wired in, so the remaining blocker is the addon's self-test.
  • #318 (implement the Windows native authority Node-API package) and #319
    (integrate it into release + a real-Windows verifier) — both still open.
  • The second defect reported in #527 — quoted GHIDRA_HEADLESS_JAVA_OPTIONS
    breaking analyzeHeadless.bat with The syntax of the command is incorrect.
    (exit 255) — is fixed in 6.4.0. ghidraHeadlessJavaOptions() now emits
    GHIDRA_HEADLESS_JAVA_OPTIONS: "" on win32 and routes through JDK_JAVA_OPTIONS
    with quoteWindowsBatchToken. Confirmed working here. Thanks for that one.

Suggested direction

  1. Instrument the addon's inspect self-test so the failing step reports the access
    mask the creation handle was granted — or re-open the object with DELETE before
    the disposition call. The evidence points at the delete being attempted through a
    handle that does not carry DELETE.
  2. Ensure a failed self-test does not leave the probe object behind; the leak is
    visible in any user's temp directory.
  3. Consider having rea providers / rea doctor distinguish "platform not
    implemented"
    from "platform implemented but the native self-test failed" — they
    need different user actions, and the current wording reads as though correct setup
    could satisfy it.

Happy to run further diagnostics on this host if useful — it is a stable Windows 11
x64 box with Ghidra 12.1.4 + JDK 21 installed and verified working outside REA.

Originally created by @koljs on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1701 ### Summary On a real Windows 11 x64 host, `rea doctor` reports the Windows native authority capability as unavailable, which hard-gates the Ghidra provider off. The reported cause is the bundled addon's own load-time self-test failing to remove an object it just created: ``` ghidra-native_authority ok: false classification: unsupported_host REA Windows native controls are unavailable: Delete owned object by handle failed [C:\Users\<user>\AppData\Local\Temp\rea-native-probe-<32hex>] (Win32 5): access denied ``` Ghidra itself is detected perfectly — 8 of the 9 provider checks pass. Only `native_authority` fails. I believe this is an addon-internal defect rather than a host constraint: every underlying operation involved succeeds when performed directly on this machine. Details and controlled experiments below. ### Environment ``` REA: rea-agents 6.4.0 (reproduced identically on 6.3.0) Host: Windows 11 x64 (os.version 10.0) Node: v22.22.2 Ghidra: 12.1.4 PUBLIC (application.version=12.1.4) JDK: Microsoft OpenJDK 21.0.12.1+1 LTS (64-bit, full JDK, javac present) Volume: C: NTFS, fixed disk, FILE_PERSISTENT_ACLS = true ``` ### Reproduction ```powershell $env:GHIDRA_INSTALL_DIR = "C:\tools\ghidra_12.1.4_PUBLIC" $env:JAVA_HOME = "C:\tools\jdk-21.0.12.1+1" rea doctor --provider ghidra --json ``` Result: ``` id : ghidra configured: True available : False version : 12.1.4 checks : configuration ok=True code=None platform ok=True code=None win32 architecture ok=True code=None x64 installation ok=True code=None ...\Ghidra\application.properties version ok=True code=None 12.1.4 headless ok=True code=None ...\support\analyzeHeadless.bat native_decompiler ok=True code=None ...\decompiler\os\win_x86_64\decompile.exe reports pe x86_64 java ok=True code=None 21.0.12.1; 64-bit; JDK native_authority ok=False code=unsupported_host REA Windows native controls are unavailable: Delete owned object by handle failed [...] (Win32 5) ``` No environment variable or configuration changes this. The gate is enforced in `GhidraProvider.inspectAvailability()`, in the session-open path, and independently in `WINDOWS_P0_CAPABILITIES` (`GhidraProviderCapabilities.ts`) — the table `BinarySessionExecution.prepareSessionExecution()` consults. ### Expected With a conforming Ghidra 12.1.4 + JDK 21 installation and a bundled native artifact whose manifest, ABI, Node-API version, PE architecture, and SHA-256 all validate, the native authority self-test should pass and the Windows Ghidra P0 lane should be reachable. ### Evidence 1 — the self-test leaks the object it fails to delete Every run leaves a directory behind in the OS temp directory. After ~14 runs: ``` $ ls -d $env:TEMP\rea-native-probe-* ...\rea-native-probe-39113ba0382648e65b5a727ccf513e74 ...\rea-native-probe-797b6742463e99b93c431efe43004028 ...\rea-native-probe-8eea686cc06802803e571270b4232123 ... (14 total, all empty directories, all 0 bytes) ``` So object **creation** succeeds; only **removal** fails. The object is a directory, and it is empty. Its security descriptor is exactly what REA intends — protected, owner correct, current user holding full rights: ``` O:<user> G:Users D:P(A;OICI;FA;;;<user>)(A;OICI;FA;;;SY) ``` `FA` (FILE_ALL_ACCESS) includes `DELETE`, so the DACL is not the problem. ### Evidence 2 — Win32 5 maps to "the handle used lacks DELETE access" Controlled experiments on this host, deleting an empty directory through a handle opened with `FILE_FLAG_BACKUP_SEMANTICS`: | Handle access mask | `SetFileInformationByHandle(FileDispositionInformation)` | |---|---| | `DELETE \| FILE_LIST_DIRECTORY` | **ok**, `err=0`, object gone | | `FILE_READ_ATTRIBUTES` only | **`err=5` ACCESS_DENIED**, object remains | And, to rule out the "not empty" explanation: | Case | Result | |---|---| | directory **not empty**, handle **has** `DELETE` | `err=145` (`ERROR_DIR_NOT_EMPTY`) — **not 5** | So Win32 `5` here is the signature of a handle **without** `DELETE` access being used to mark the object for deletion, which matches the observed failure exactly. ### Evidence 3 — everything else on the host works Performed directly on this machine, all successful: | Operation | Result | |---|---| | `SetFileInformationByHandle(FileDispositionInformation)` on a file | ok | | …on an empty directory | ok | | …on a directory with a protected user+SYSTEM DACL | ok | | `NtSetInformationFile(FileDispositionInformationEx)` — `DELETE` (0x1) | ok | | …`DELETE \| POSIX` (0x3) | ok | | …`DELETE \| POSIX \| IGNORE_READONLY` (0x7) | ok | | `NtCreateFile` with an inline protected security descriptor | ok | | Volume supports `FILE_PERSISTENT_ACLS` | true | The native artifact itself loads fine — package version, ABI 1, Node-API 8, PE x64, and SHA-256 all validate. Only the `inspect` self-test fails. ### Ruled out - **Temp directory location** — reproduced identically under three different parents (`%LOCALAPPDATA%\Temp`, a directory on `C:\`, and a directory under the user profile). - **Reparse points** — no component of the temp path carries a reparse tag. - **Restricted token** — `TokenRestrictedSids` group count is `0`; the process runs as the ordinary user with a normal High-integrity token (`Administrators`, `Users`, `Authenticated Users` present). - **Antivirus** — Windows Defender real-time protection is disabled by policy and no third-party AV product is registered. - **Elevation** — token integrity is High, not elevated. - **Volume type** — NTFS, fixed, persistent ACLs. ### Impact On Windows, everything requiring a deep-analysis provider is unavailable: `open_binary`, `binary_overview`, `batch_decompile`, `get_call_graph`, `xrefs`, `procedure_pseudo_code`, `analyze_function`, `trace_feature`, and native function dossiers. Provider-independent tooling works fine. Secondary impact: the failed self-test **leaks a directory into the OS temp directory on every run**, with no cleanup path. ### Relationship to existing issues - **#527** (Windows Ghidra hard-gated off) — closed, and the maintainer noted the closure pass ran **no real Windows tests**. That issue covered the period when `WindowsAuthority.ts` returned `notProven` unconditionally; the native addon now exists and is wired in, so the remaining blocker is the addon's self-test. - **#318** (implement the Windows native authority Node-API package) and **#319** (integrate it into release + a real-Windows verifier) — both still open. - The **second** defect reported in #527 — quoted `GHIDRA_HEADLESS_JAVA_OPTIONS` breaking `analyzeHeadless.bat` with `The syntax of the command is incorrect.` (exit 255) — **is fixed in 6.4.0**. `ghidraHeadlessJavaOptions()` now emits `GHIDRA_HEADLESS_JAVA_OPTIONS: ""` on win32 and routes through `JDK_JAVA_OPTIONS` with `quoteWindowsBatchToken`. Confirmed working here. Thanks for that one. ### Suggested direction 1. Instrument the addon's `inspect` self-test so the failing step reports the access mask the creation handle was granted — or re-open the object with `DELETE` before the disposition call. The evidence points at the delete being attempted through a handle that does not carry `DELETE`. 2. Ensure a failed self-test does not leave the probe object behind; the leak is visible in any user's temp directory. 3. Consider having `rea providers` / `rea doctor` distinguish *"platform not implemented"* from *"platform implemented but the native self-test failed"* — they need different user actions, and the current wording reads as though correct setup could satisfy it. Happy to run further diagnostics on this host if useful — it is a stable Windows 11 x64 box with Ghidra 12.1.4 + JDK 21 installed and verified working outside REA.
Author
Owner

@ranceil commented on GitHub (Oct 11, 2026):

Independent reproduction on a second Windows host, with three data points not covered above.

Environment (different from the original report)

REA: rea-agents 6.4.0 — also fails on 6.3.0 AND 5.0.0
Host: Windows 11 Pro, 10.0.26200, x64 (fixed local NTFS on C:, D:, E:)
Node: v22.22.2 (also reproduced with v22.22.0)
Ghidra: 12.1.4 PUBLIC
JDK: Eclipse Temurin 21.0.12.1+1 (64-bit, full JDK, javac present)

Same symptom: 8 of 9 provider checks pass, native_authority fails with
Delete owned object by handle failed ... (Win32 5), available: false,
and each run leaks one empty rea-native-probe-<32hex> directory into %TEMP%
(10 accumulated during this investigation).

1. The defect predates 6.3.0. rea-agents@5.0.0 reports
providerInspections.ghidra.available: false as well, with the same eight
conforming checks. In that release the check is not yet surfaced under the
native_authority name, but the gate behaves identically. So this is not a
regression introduced in the 6.3.x line.

2. It is not antivirus-related, in both directions. This host had a
third-party endpoint product installed (kernel drivers loaded, plus a resident
client). After fully removing it and confirming its services and drivers were
gone, the self-test failed identically. Your report has no AV product registered
at all; this host reproduces it both with and without third-party AV. That
closes the AV direction from both sides.

3. It survives a full reboot. A clean restart (no lingering drivers or
hooks) changes nothing.

4. Your access-mask conclusion is confirmed, and share mode is not the
constraint.
On this host, from the same session and the same directory as the
failing self-test:

h = CreateFileW(dir, DELETE,
                FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
                NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL);   // ok
SetFileInformationByHandle(h, FileDispositionInfoEx,               // class 21
                           DELETE | FILE_DISPOSITION_POSIX_SEMANTICS); // ok=True
The object is then gone. So the FileDispositionInformationEx + POSIX variant
also succeeds when the handle carries DELETE, consistent with your read that
the failing call is made through a handle without DELETE.
Also ruled out on this host (all reproduced failing): command sandbox /
nested Job Object, three different temp parents (including one on another
volume), probe-object DACL (icacls shows current user + SYSTEM full control,
non-inherited, no deny ACEs), mandatory integrity label (none on the object →
default Medium), and volume type (C:, D:, E: all NTFS, all healthy).
Consistent with your suggested direction 1 — instrumenting the self-test to
report the access mask granted to the creation handle, or re-opening with
DELETE before the disposition call, would settle it directly. Direction 2 (do
not leave the probe object behind) is also worth fixing independently: the leak
is the only user-visible trace, and it is what made this diagnosable.
Happy to run further diagnostics on this second host if useful — Windows 11
build 26200 with a verified-working Ghidra 12.1.4 + JDK 21 outside REA.
<!-- gh-comment-id:6105637018 --> @ranceil commented on GitHub (Oct 11, 2026): Independent reproduction on a second Windows host, with three data points not covered above. **Environment (different from the original report)** REA: rea-agents 6.4.0 — also fails on 6.3.0 AND 5.0.0 Host: Windows 11 Pro, 10.0.26200, x64 (fixed local NTFS on C:, D:, E:) Node: v22.22.2 (also reproduced with v22.22.0) Ghidra: 12.1.4 PUBLIC JDK: Eclipse Temurin 21.0.12.1+1 (64-bit, full JDK, javac present) Same symptom: 8 of 9 provider checks pass, `native_authority` fails with `Delete owned object by handle failed ... (Win32 5)`, `available: false`, and each run leaks one empty `rea-native-probe-<32hex>` directory into `%TEMP%` (10 accumulated during this investigation). **1. The defect predates 6.3.0.** `rea-agents@5.0.0` reports `providerInspections.ghidra.available: false` as well, with the same eight conforming checks. In that release the check is not yet surfaced under the `native_authority` name, but the gate behaves identically. So this is not a regression introduced in the 6.3.x line. **2. It is not antivirus-related, in both directions.** This host had a third-party endpoint product installed (kernel drivers loaded, plus a resident client). After fully removing it and confirming its services and drivers were gone, the self-test failed identically. Your report has no AV product registered at all; this host reproduces it both with and without third-party AV. That closes the AV direction from both sides. **3. It survives a full reboot.** A clean restart (no lingering drivers or hooks) changes nothing. **4. Your access-mask conclusion is confirmed, and share mode is not the constraint.** On this host, from the same session and the same directory as the failing self-test: ```c h = CreateFileW(dir, DELETE, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL); // ok SetFileInformationByHandle(h, FileDispositionInfoEx, // class 21 DELETE | FILE_DISPOSITION_POSIX_SEMANTICS); // ok=True The object is then gone. So the FileDispositionInformationEx + POSIX variant also succeeds when the handle carries DELETE, consistent with your read that the failing call is made through a handle without DELETE. Also ruled out on this host (all reproduced failing): command sandbox / nested Job Object, three different temp parents (including one on another volume), probe-object DACL (icacls shows current user + SYSTEM full control, non-inherited, no deny ACEs), mandatory integrity label (none on the object → default Medium), and volume type (C:, D:, E: all NTFS, all healthy). Consistent with your suggested direction 1 — instrumenting the self-test to report the access mask granted to the creation handle, or re-opening with DELETE before the disposition call, would settle it directly. Direction 2 (do not leave the probe object behind) is also worth fixing independently: the leak is the only user-visible trace, and it is what made this diagnosable. Happy to run further diagnostics on this second host if useful — Windows 11 build 26200 with a verified-working Ghidra 12.1.4 + JDK 21 outside REA.
Author
Owner

@jhuang-tw commented on GitHub (Oct 11, 2026):

Additional independent Windows countercheck (not a fix claim):

  • I downloaded the published rea-agents@6.4.0 Windows x64 native addon from npm into an isolated checkout directory. Its SHA-256 matched the distributed manifest (c4fd9f377e567bcf15ba3fec3e0b0ed965d82b765a2adcdac49e46f14524b6d5). On this Windows x64 fixed-NTFS host, with process-local TMP/TEMP pointing into an isolated NTFS test directory, addon.call("inspect", []) passed, including private-DACL and job-control capability reporting; there were zero residual rea-native-probe-* directories.
  • A separate Win32 experiment created an empty directory, opened it with DELETE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | READ_CONTROL and FILE_SHARE_READ, duplicated the handle with DUPLICATE_SAME_ACCESS, then called SetFileInformationByHandle(FileDispositionInfo, DeleteFile=TRUE) on the duplicate while the original was still open. It succeeded. The control with FILE_SHARE_DELETE included also succeeded. Both test objects were removed.
  • In REA source, createRuntime requests DELETE for its owned directory in NtCreateFile; closeRuntime duplicates the owned handle with DUPLICATE_SAME_ACCESS and later applies FileDispositionInfo. Thus the original handle not requesting DELETE, or duplication inherently making this deletion impossible, is not established by the present code or this passing host. The affected-host failures in this issue remain important and independently reported; this successful control does not disprove them.

A useful next discriminator on a failing host would be the actual GrantedAccess on the creation handle and the frame duplicate at the point of failure (e.g., NtQueryObject(ObjectBasicInformation)), along with the exact failed disposition status. Reopening the path independently with DELETE proves the security descriptor permits a new handle, but does not establish the granted mask on the retained original. That would distinguish a granted-rights problem from a host-specific directory-disposition constraint before changing the handle-sharing or POSIX unlink semantics.

I have not opened a code PR for this yet: the published addon self-test and the independent duplicate-handle control both pass on my available Windows host, so a speculative security-sensitive fallback would not be responsibly verified. All temporary test objects were confined to and cleaned from the isolated checkout test directory.

<!-- gh-comment-id:6105852686 --> @jhuang-tw commented on GitHub (Oct 11, 2026): Additional independent Windows countercheck (not a fix claim): - I downloaded the published **rea-agents@6.4.0** Windows x64 native addon from npm into an isolated checkout directory. Its SHA-256 matched the distributed manifest (`c4fd9f377e567bcf15ba3fec3e0b0ed965d82b765a2adcdac49e46f14524b6d5`). On this Windows x64 fixed-NTFS host, with process-local TMP/TEMP pointing into an isolated NTFS test directory, `addon.call("inspect", [])` **passed**, including private-DACL and job-control capability reporting; there were **zero** residual `rea-native-probe-*` directories. - A separate Win32 experiment created an empty directory, opened it with `DELETE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | READ_CONTROL` and `FILE_SHARE_READ`, duplicated the handle with `DUPLICATE_SAME_ACCESS`, then called `SetFileInformationByHandle(FileDispositionInfo, DeleteFile=TRUE)` on the duplicate **while the original was still open**. It succeeded. The control with `FILE_SHARE_DELETE` included also succeeded. Both test objects were removed. - In REA source, [`createRuntime`](https://github.com/morluto/rea/blob/main/native/windows/src/filesystem.cc#L214-L227) **requests `DELETE`** for its owned directory in `NtCreateFile`; [`closeRuntime`](https://github.com/morluto/rea/blob/main/native/windows/src/filesystem.cc#L330-L383) duplicates the owned handle with `DUPLICATE_SAME_ACCESS` and later applies `FileDispositionInfo`. Thus the original handle *not requesting* `DELETE`, or duplication *inherently* making this deletion impossible, is not established by the present code or this passing host. The affected-host failures in this issue remain important and independently reported; this successful control does not disprove them. A useful next discriminator on **a failing host** would be the actual `GrantedAccess` on the **creation handle and the frame duplicate at the point of failure** (e.g., `NtQueryObject(ObjectBasicInformation)`), along with the exact failed disposition status. Reopening the path independently with `DELETE` proves the security descriptor permits a *new* handle, but does not establish the granted mask on the retained original. That would distinguish a granted-rights problem from a host-specific directory-disposition constraint before changing the handle-sharing or POSIX unlink semantics. I have **not** opened a code PR for this yet: the published addon self-test and the independent duplicate-handle control both pass on my available Windows host, so a speculative security-sensitive fallback would not be responsibly verified. All temporary test objects were confined to and cleaned from the isolated checkout test directory.
Author
Owner

@gaodanbendan commented on GitHub (Oct 11, 2026):

Third Windows host — same failure, but transient: it self-cleared with no code or config change

TL;DR. On a third Windows 11 x64 host I hit the exact failure reported here
(native_authority → unsupported_host, Delete owned object by handle failed … (Win32 5),
one leaked rea-native-probe-<32hex> directory per run). Then, on the same machine, same
%TEMP%, same rea-agents 6.4.0, same Ghidra 12.1.4 + JDK 21, with nothing changed in code
or configuration
, the gate started passing — and it has now passed 30/30 times, with
zero leaked directories. Two end-to-end analyses that previously failed on identical
inputs now complete.

This does not contradict the reports above; it adds a dimension they do not cover: the
failure is not deterministic on a given host.
That matters for triage, because a
deterministic-looking repro invites a code-path fix, while a transient one points at a race
or a third-party holder of the freshly created object.


Environment

REA rea-agents 6.4.0 (isolated install)
Host Windows 11 家庭版 (Home) x64
OS 10.0.26100, build 26100
Node v22.22.2
Ghidra 12.1.4 PUBLIC
JDK Eclipse Temurin 21.0.12.1+1 (64-bit, full JDK)
Volume C: NTFS, fixed, 201 GB
Temp C:\Users\<user>\AppData\Local\Temp (standard, untouched all session)
Defender Real-time protection ON, AMRunningMode = Normal
Token Medium integrity (not elevated)

The window, verbatim — identical inputs, opposite outcomes

All four runs below are on the same host, same temp directory, same release.
Timestamps are local (UTC+8).

Ghidra, target C:\Windows\System32\notepad.exe

14:23 — fails

{"error":"Analysis failed","code":"provider_unavailable","category":"unavailable",
 "details":{"operation":"open_binary","requested_provider_id":"ghidra",
  "rejections":[
   {"provider_id":"ghidra","code":"unsupported_host",
    "reason":"REA Windows native controls are unavailable: Delete owned object by handle failed [C:\\Users\\shzjbs\\AppData\\Local\\Temp\\rea-native-probe-fb904b60d541642ec5aaea9c496192ed] (Win32 5): 拒绝访问。\r\n"},
   {"provider_id":"hopper","code":"unsupported_host","reason":"Hopper integration is not supported on win32."},
   {"provider_id":"ida","code":"not_configured","reason":"Set REA_IDA_MCP_CONFIG to an upstream IDA MCP JSON registration; …"}]}}

14:59 — succeeds

{"evidence_id":"ev_9c31ac236b1c89befb80941ab4f4fe5b5a626cbde4a46de59c633b5d67833fe1",
 "subject":{"name":"C:\\Windows\\System32\\notepad.exe",
            "digest":{"sha256":"b862fd21ab3c38f7aabb3f41b8b6845d14692cd4273edc9dfec7b555e2c6b505"},
            "format":"pe","architecture":"x86_64"},
 "provider":{"id":"rea-workflow",…},
 "analysis_profile":{… "upstream_analysis_profile":{"provider":{"id":"ghidra","name":"Ghidra","version":"12.1.4"} …}}}

Elapsed 5 m 17 s, exit 0.

JavaScript application analysis — identical subject digest

This pair is the cleanest control I have: the subject digest is byte-for-byte the same in
both runs, so the analysed object provably did not change.

14:26 — fails

{"error":"JavaScript application analysis failed","code":"capability_unavailable",
 "category":"unsupported_provider",
 "details":{"provider_id":"javascript-static-analysis",
            "operation":"analyze_javascript_application",
            "reason":"REA Windows native controls are unavailable: Delete owned object by handle failed [C:\\Users\\shzjbs\\AppData\\Local\\Temp\\rea-native-probe-34dbda3a67564c2180aff23a49c807a8] (Win32 5): 拒绝访问。\r\n",
            "partial_observation":{"subject":{…,
              "digest":{"sha256":"21541cf8f502d8f6fa406979a3e595c21c5a6216ef6b88c780f949c5645433c9"}}}}}

14:57 — succeeds

{"evidence_id":"ev_a4c1c9421f60de3d012e873cfcde1110d7993fae71745b079984b785bb047284",
 "subject":{"digest":{"sha256":"21541cf8f502d8f6fa406979a3e595c21c5a6216ef6b88c780f949c5645433c9"}, …},
 "provider":{"id":"rea-javascript-application",…}}

Exit 0, 79.8 MB of JSON output. Same digest, failure → success.


Data point not covered by the reports above: the gate also blocks non-native providers

The Impact section says "Provider-independent tooling works fine." On this host that is not
what I measured. analyze-javascript-application is not a deep-analysis provider — it is
pure static parsing of a directory of .js files — and it was rejected by the same native
self-test string
, with capability_unavailable / unsupported_provider.

Two things follow:

  1. The blast radius is wider than the provider list in the Impact section: every operation
    that goes through BinarySessionExecution.prepareSessionExecution() is affected,
    including JavaScript/Electron application analysis, HAR capture, and anything else
    routing through the native authority.
  2. The capability_unavailable / unsupported_provider wording is misleading here. The
    provider is supported on this platform; the gate mislabels a self-test failure as an
    unsupported capability. (Related to what the original report calls out in "suggested
    direction 3", but the JS path is a second, non-provider surface for it.)

Note also the partial_observation in the 14:26 failure: the subject digest was already
computed and the file/directory was already read. So creation and reading succeed; only
the removal of the self-test object fails
— consistent with the original report's
Evidence 1.


Current state of the same host (after the window)

rea doctor — native_authority row now:

- name: ghidra-native_authority
  ok: true
  classification: healthy
  detail: "Verified Windows native Job Object, private DACL, and reparse-safe handle controls; local NTFS only."

Direct addon call, addon.call("inspect", []):

{
  "abiVersion": 1,
  "nodeApiVersion": 8,
  "architecture": "x64",
  "filesystem": {
    "requestedPath": "C:\\Users\\shzjbs\\AppData\\Local\\Temp\\rea-native-probe-6b89cbfb929c05641b17b67a4a150494",
    "finalPath": "\\\\?\\C:\\Users\\shzjbs\\AppData\\Local\\Temp\\rea-native-probe-6b89cbfb929c05641b17b67a4a150494",
    "filesystem": "NTFS",
    "volumeSerial": "1a1ace951ace6d77",
    "fileId": "6d850b0000000c000000000000000000",
    "size": 0,
    "directory": true
  },
  "privateDacl": true,
  "atomicJobAssignment": true,
  "killOnOwnerClose": true,
  "protocolStdin": true
}

All four capability flags true; the probe directory it names was removed cleanly.

Statistics

Window Runs native_authority Leaked probe dirs
~13:40 – 14:26 every run failed ok:false ×N 6 accumulated
14:50 – 15:00 30 ok:true ×30, 0 failures 0

Counts after recovery: 2 sandboxed + 2 unsandboxed + 20 consecutive + 5 under artificial
load = 30 doctor runs, no failure, no leak.

I could not re-trigger it

Attempts to bring the failure back, all unsuccessful (0 failures, 0 leaks):

  • run inside and outside the process sandbox — 2+2 runs;
  • 20 back-to-back runs;
  • created 3,000 fresh files in %TEMP% immediately before 5 runs, to put the AV/IO path
    under load — still 5/5 pass.

Facts about the transition (no causal claim)

What I know changed on the host between the last observed failure (14:26) and the first
success (14:54):

  • I manually removed the 6 leftover empty rea-native-probe-* directories that the
    failing runs had accumulated in %TEMP%.
  • Windows Defender telemetry in the same window (log Microsoft-Windows-Windows Defender/Operational): configuration-change events (5007) at 13:42:37, ten more between
    13:57:19 and 13:57:34, then 14:00:01 and 14:07:54; a security-intelligence update
    (2000 ×2) at 14:07:53; cloud-protection lookups (2010) at 14:09:12, then 14:50:59 and
    14:51:55. Real-time protection was ON for the entire period, including the successful runs.

I am not claiming Defender caused the failure — RTP was on in both windows, which
weakens a straightforward AV explanation. I am recording the telemetry because it is the
only correlated activity I can see, and because the two obvious "code-path" explanations
(handle without DELETE, duplicate-handle semantics) are already argued in the thread and
do not by themselves explain a state change with no code change.

The pattern that fits best, in my reading: the disposition call is racing something that
holds the freshly created object for a short interval, and on this host that interval
closed. That is a hypothesis, not a finding.


Suggested direction (additions to the three already in the report)

  1. Retry with backoff in the self-test. If the failure really is a short-lived race,
    a bounded retry (e.g. 3 attempts, tens of ms apart) converts most of these into passes
    and eliminates the whole class of "host-dependent flaky gate". This is cheap and does
    not weaken the security property — the self-test only proves the capability exists, and
    retrying a probe cannot make it less real.
  2. Always clean up the probe object, including on failure. The leak is the only
    user-visible symptom and, as the original report notes, is what made this diagnosable.
    It is also a correctness bug independent of the gate: a failed check must not leave
    state behind.
  3. Capture, at failure time, the GrantedAccess of the creation handle and of the
    duplicated handle
    (e.g. via NtQueryObject(ObjectBasicInformation)), plus the exact
    status of the disposition call. This is the discriminator the thread is missing; my
    host's transient behaviour makes it more, not less, important.
  4. Log the probe object name and the two access masks to a persistent location on
    failure
    — a transient failure that leaves no record is undiagnosable after the fact.
    (On my host the failure is now unreproducible, so without a logged trace the evidence
    is gone.)

Happy to run further diagnostics on this host. Note that it is currently in the passing
state, which may be exactly what is needed to diff against a failing host — for instance,
the same inspect call and the same access-mask instrumentation on both.


Footnote, unrelated to this issue: in my environment rea doctor's Java probe
(GhidraInstallation.js, the bare spawnSync call) also fails spuriously, because
inheriting stdin in this process environment returns EBUSY and the child is never
created; a process-local preload that sets the child's stdio to ignore fixes it. The
14:23 and later runs above include that workaround, so java shows healthy and the only
remaining rejection is the native one. Reporting it for completeness; I do not think it is
related.

<!-- gh-comment-id:6106502136 --> @gaodanbendan commented on GitHub (Oct 11, 2026): # Third Windows host — same failure, but **transient**: it self-cleared with no code or config change **TL;DR.** On a third Windows 11 x64 host I hit the exact failure reported here (`native_authority` → `unsupported_host`, `Delete owned object by handle failed … (Win32 5)`, one leaked `rea-native-probe-<32hex>` directory per run). Then, **on the same machine, same `%TEMP%`, same `rea-agents 6.4.0`, same Ghidra 12.1.4 + JDK 21, with nothing changed in code or configuration**, the gate started passing — and it has now passed **30/30 times**, with **zero** leaked directories. Two end-to-end analyses that previously failed on identical inputs now complete. This does not contradict the reports above; it adds a dimension they do not cover: **the failure is not deterministic on a given host.** That matters for triage, because a deterministic-looking repro invites a code-path fix, while a transient one points at a race or a third-party holder of the freshly created object. --- ## Environment | | | |---|---| | REA | `rea-agents` 6.4.0 (isolated install) | | Host | Windows 11 家庭版 (Home) x64 | | OS | 10.0.26100, build 26100 | | Node | v22.22.2 | | Ghidra | 12.1.4 PUBLIC | | JDK | Eclipse Temurin 21.0.12.1+1 (64-bit, full JDK) | | Volume | `C:` NTFS, fixed, 201 GB | | Temp | `C:\Users\<user>\AppData\Local\Temp` (standard, untouched all session) | | Defender | **Real-time protection ON**, `AMRunningMode = Normal` | | Token | Medium integrity (not elevated) | --- ## The window, verbatim — identical inputs, opposite outcomes All four runs below are on the *same* host, *same* temp directory, *same* release. Timestamps are local (UTC+8). ### Ghidra, target `C:\Windows\System32\notepad.exe` **14:23 — fails** ```json {"error":"Analysis failed","code":"provider_unavailable","category":"unavailable", "details":{"operation":"open_binary","requested_provider_id":"ghidra", "rejections":[ {"provider_id":"ghidra","code":"unsupported_host", "reason":"REA Windows native controls are unavailable: Delete owned object by handle failed [C:\\Users\\shzjbs\\AppData\\Local\\Temp\\rea-native-probe-fb904b60d541642ec5aaea9c496192ed] (Win32 5): 拒绝访问。\r\n"}, {"provider_id":"hopper","code":"unsupported_host","reason":"Hopper integration is not supported on win32."}, {"provider_id":"ida","code":"not_configured","reason":"Set REA_IDA_MCP_CONFIG to an upstream IDA MCP JSON registration; …"}]}} ``` **14:59 — succeeds** ```json {"evidence_id":"ev_9c31ac236b1c89befb80941ab4f4fe5b5a626cbde4a46de59c633b5d67833fe1", "subject":{"name":"C:\\Windows\\System32\\notepad.exe", "digest":{"sha256":"b862fd21ab3c38f7aabb3f41b8b6845d14692cd4273edc9dfec7b555e2c6b505"}, "format":"pe","architecture":"x86_64"}, "provider":{"id":"rea-workflow",…}, "analysis_profile":{… "upstream_analysis_profile":{"provider":{"id":"ghidra","name":"Ghidra","version":"12.1.4"} …}}} ``` Elapsed 5 m 17 s, exit 0. ### JavaScript application analysis — **identical subject digest** This pair is the cleanest control I have: the `subject` digest is byte-for-byte the same in both runs, so the analysed object provably did not change. **14:26 — fails** ```json {"error":"JavaScript application analysis failed","code":"capability_unavailable", "category":"unsupported_provider", "details":{"provider_id":"javascript-static-analysis", "operation":"analyze_javascript_application", "reason":"REA Windows native controls are unavailable: Delete owned object by handle failed [C:\\Users\\shzjbs\\AppData\\Local\\Temp\\rea-native-probe-34dbda3a67564c2180aff23a49c807a8] (Win32 5): 拒绝访问。\r\n", "partial_observation":{"subject":{…, "digest":{"sha256":"21541cf8f502d8f6fa406979a3e595c21c5a6216ef6b88c780f949c5645433c9"}}}}} ``` **14:57 — succeeds** ```json {"evidence_id":"ev_a4c1c9421f60de3d012e873cfcde1110d7993fae71745b079984b785bb047284", "subject":{"digest":{"sha256":"21541cf8f502d8f6fa406979a3e595c21c5a6216ef6b88c780f949c5645433c9"}, …}, "provider":{"id":"rea-javascript-application",…}} ``` Exit 0, 79.8 MB of JSON output. **Same digest, failure → success.** --- ## Data point not covered by the reports above: the gate also blocks *non-native* providers The Impact section says "Provider-independent tooling works fine." On this host that is not what I measured. `analyze-javascript-application` is not a deep-analysis provider — it is pure static parsing of a directory of `.js` files — and it was rejected by the **same native self-test string**, with `capability_unavailable` / `unsupported_provider`. Two things follow: 1. The blast radius is wider than the provider list in the Impact section: every operation that goes through `BinarySessionExecution.prepareSessionExecution()` is affected, including JavaScript/Electron application analysis, HAR capture, and anything else routing through the native authority. 2. The `capability_unavailable` / `unsupported_provider` wording is misleading here. The provider *is* supported on this platform; the gate mislabels a self-test failure as an unsupported capability. (Related to what the original report calls out in "suggested direction 3", but the JS path is a second, non-provider surface for it.) Note also the `partial_observation` in the 14:26 failure: the subject digest was already computed and the file/directory was already read. So **creation and reading succeed; only the removal of the self-test object fails** — consistent with the original report's Evidence 1. --- ## Current state of the same host (after the window) `rea doctor` — `native_authority` row now: ``` - name: ghidra-native_authority ok: true classification: healthy detail: "Verified Windows native Job Object, private DACL, and reparse-safe handle controls; local NTFS only." ``` Direct addon call, `addon.call("inspect", [])`: ```json { "abiVersion": 1, "nodeApiVersion": 8, "architecture": "x64", "filesystem": { "requestedPath": "C:\\Users\\shzjbs\\AppData\\Local\\Temp\\rea-native-probe-6b89cbfb929c05641b17b67a4a150494", "finalPath": "\\\\?\\C:\\Users\\shzjbs\\AppData\\Local\\Temp\\rea-native-probe-6b89cbfb929c05641b17b67a4a150494", "filesystem": "NTFS", "volumeSerial": "1a1ace951ace6d77", "fileId": "6d850b0000000c000000000000000000", "size": 0, "directory": true }, "privateDacl": true, "atomicJobAssignment": true, "killOnOwnerClose": true, "protocolStdin": true } ``` All four capability flags `true`; the probe directory it names was removed cleanly. ### Statistics | Window | Runs | `native_authority` | Leaked probe dirs | |---|---|---|---| | ~13:40 – 14:26 | every run failed | `ok:false` ×N | **6 accumulated** | | 14:50 – 15:00 | 30 | **`ok:true` ×30, 0 failures** | **0** | Counts after recovery: 2 sandboxed + 2 unsandboxed + 20 consecutive + 5 under artificial load = 30 `doctor` runs, no failure, no leak. ### I could not re-trigger it Attempts to bring the failure back, all unsuccessful (0 failures, 0 leaks): - run inside and outside the process sandbox — 2+2 runs; - 20 back-to-back runs; - created 3,000 fresh files in `%TEMP%` immediately before 5 runs, to put the AV/IO path under load — still 5/5 pass. --- ## Facts about the transition (no causal claim) What I know changed on the host between the last observed failure (14:26) and the first success (14:54): - I manually removed the **6 leftover empty `rea-native-probe-*` directories** that the failing runs had accumulated in `%TEMP%`. - Windows Defender telemetry in the same window (log `Microsoft-Windows-Windows Defender/Operational`): configuration-change events (5007) at 13:42:37, ten more between 13:57:19 and 13:57:34, then 14:00:01 and 14:07:54; a **security-intelligence update** (2000 ×2) at 14:07:53; cloud-protection lookups (2010) at 14:09:12, then 14:50:59 and 14:51:55. Real-time protection was ON for the entire period, including the successful runs. I am **not** claiming Defender caused the failure — RTP was on in both windows, which weakens a straightforward AV explanation. I am recording the telemetry because it is the only correlated activity I can see, and because the two obvious "code-path" explanations (handle without `DELETE`, duplicate-handle semantics) are already argued in the thread and do not by themselves explain a state change with no code change. The pattern that fits best, in my reading: the disposition call is racing something that holds the freshly created object for a short interval, and on this host that interval closed. That is a hypothesis, not a finding. --- ## Suggested direction (additions to the three already in the report) 1. **Retry with backoff in the self-test.** If the failure really is a short-lived race, a bounded retry (e.g. 3 attempts, tens of ms apart) converts most of these into passes and eliminates the whole class of "host-dependent flaky gate". This is cheap and does not weaken the security property — the self-test only proves the capability exists, and retrying a *probe* cannot make it less real. 2. **Always clean up the probe object, including on failure.** The leak is the only user-visible symptom and, as the original report notes, is what made this diagnosable. It is also a correctness bug independent of the gate: a failed check must not leave state behind. 3. **Capture, at failure time, the `GrantedAccess` of the creation handle and of the duplicated handle** (e.g. via `NtQueryObject(ObjectBasicInformation)`), plus the exact status of the disposition call. This is the discriminator the thread is missing; my host's transient behaviour makes it more, not less, important. 4. **Log the probe object name and the two access masks to a persistent location on failure** — a transient failure that leaves no record is undiagnosable after the fact. (On my host the failure is now unreproducible, so without a logged trace the evidence is gone.) Happy to run further diagnostics on this host. Note that it is currently in the *passing* state, which may be exactly what is needed to diff against a failing host — for instance, the same `inspect` call and the same access-mask instrumentation on both. --- <sub>Footnote, unrelated to this issue: in my environment `rea doctor`'s Java probe (`GhidraInstallation.js`, the bare `spawnSync` call) also fails spuriously, because inheriting `stdin` in this process environment returns `EBUSY` and the child is never created; a process-local preload that sets the child's `stdio` to `ignore` fixes it. The 14:23 and later runs above include that workaround, so `java` shows healthy and the *only* remaining rejection is the native one. Reporting it for completeness; I do not think it is related.</sub>
Author
Owner

@pablodiazjorge commented on GitHub (Oct 11, 2026):

Another data point, from a host that has never been in the failing state so far, with the published npm package:

OS Windows 11 Pro 26H2, build 26300.9457, x64
Token ordinary user, medium integrity (not elevated)
Volumes local NTFS for the target, the install and %TEMP%
Defender real-time protection ON, AMRunningMode = Normal, no third-party AV
REA rea-agents 6.4.0 from npm, installed in a project folder
Node.js 22.22.3
Ghidra 12.1.4, official zip with matching SHA-256
JDK Oracle 23.0.2
  • native_authority passed in 31 of 31 rea doctor --provider ghidra --json runs (1 earlier in the day plus 30 back to back), with zero rea-native-probe-* directories left in %TEMP%. Each run took 1.6 to 27 s.
  • End to end, rea inspect WinHelloCPP.exe --provider ghidra --format json (the x86 PE from Ghidra's own GhidraClass exercises) completes in about 25 s: 6 segments, 388 procedures, 254 strings, with no java process or probe directory left behind.

So, like jhuang-tw's countercheck and gaodanbendan's host after recovery, the shipped 6.4.0 addon passes inspect here, with Defender real-time protection on the whole time.

#1826 notes that Windows Ghidra/JDK were not verified there. Once it lands (or from a build of that branch, if that helps), I can run the Ghidra path end to end on this host, plus npm run verify:ghidra:windows and verify:ghidra:windows:package, and report the results here. This host can also be the passing side of a diff with access-mask instrumentation.

<!-- gh-comment-id:6109435769 --> @pablodiazjorge commented on GitHub (Oct 11, 2026): Another data point, from a host that has **never** been in the failing state so far, with the published npm package: | | | |---|---| | OS | Windows 11 Pro 26H2, build 26300.9457, x64 | | Token | ordinary user, medium integrity (not elevated) | | Volumes | local NTFS for the target, the install and `%TEMP%` | | Defender | real-time protection ON, `AMRunningMode = Normal`, no third-party AV | | REA | `rea-agents` 6.4.0 from npm, installed in a project folder | | Node.js | 22.22.3 | | Ghidra | 12.1.4, official zip with matching SHA-256 | | JDK | Oracle 23.0.2 | - `native_authority` passed in **31 of 31** `rea doctor --provider ghidra --json` runs (1 earlier in the day plus 30 back to back), with **zero** `rea-native-probe-*` directories left in `%TEMP%`. Each run took 1.6 to 27 s. - End to end, `rea inspect WinHelloCPP.exe --provider ghidra --format json` (the x86 PE from Ghidra's own GhidraClass exercises) completes in about 25 s: 6 segments, 388 procedures, 254 strings, with no `java` process or probe directory left behind. So, like jhuang-tw's countercheck and gaodanbendan's host after recovery, the shipped 6.4.0 addon passes `inspect` here, with Defender real-time protection on the whole time. #1826 notes that Windows Ghidra/JDK were not verified there. Once it lands (or from a build of that branch, if that helps), I can run the Ghidra path end to end on this host, plus `npm run verify:ghidra:windows` and `verify:ghidra:windows:package`, and report the results here. This host can also be the passing side of a diff with access-mask instrumentation.
Author
Owner

@pablodiazjorge commented on GitHub (Oct 11, 2026):

Follow-up on my offer above: I verified main at 0b4ce836 (with #1826) on the same host, built from source with the native addon from npm run build:windows-native, and installed from npm pack into an isolated folder:

  • rea doctor --provider ghidra: native_authority passed 30/30, with no rea-native-probe-* directory left.
  • End to end with Ghidra 12.1.4 and Temurin JDK 21: rea inspect WinHelloCPP.exe in 27 s, and an MCP session (open_binary, binary_overview, close_binary) with a clean exit and no java process left.
  • npm run verify:windows-native passes.

The real Windows Ghidra lanes needed two verifier fixes unrelated to #1826 (#1859, PR #1863). With them, all four verify:ghidra:windows variants and all four verify:ghidra:windows:package variants pass on this host.

<!-- gh-comment-id:6110155034 --> @pablodiazjorge commented on GitHub (Oct 11, 2026): Follow-up on my offer above: I verified `main` at `0b4ce836` (with #1826) on the same host, built from source with the native addon from `npm run build:windows-native`, and installed from `npm pack` into an isolated folder: - `rea doctor --provider ghidra`: `native_authority` passed 30/30, with no `rea-native-probe-*` directory left. - End to end with Ghidra 12.1.4 and Temurin JDK 21: `rea inspect WinHelloCPP.exe` in 27 s, and an MCP session (`open_binary`, `binary_overview`, `close_binary`) with a clean exit and no `java` process left. - `npm run verify:windows-native` passes. The real Windows Ghidra lanes needed two verifier fixes unrelated to #1826 (#1859, PR #1863). With them, all four `verify:ghidra:windows` variants and all four `verify:ghidra:windows:package` variants pass on this host.
Author
Owner

@liudong-geek commented on GitHub (Oct 12, 2026):

Fourth independent host — 100% deterministic failure, plus a faithful native replication that pins the mechanism.

Environment

REA rea-agents@6.4.0 (npm, global) — also reproduced with the isolated replay below
Host Windows 11 Home China, 26H2, build 26300.9457 — the same build as @pablodiazjorge's passing host
Node v24.14.0, v22.22.2, v22.17.0 — all three fail identically
Ghidra 12.1.4 PUBLIC, application.java.min=21, native decompiler present
JDK Temurin 21.0.12 (64-bit, full JDK, javac present)
Temp %LOCALAPPDATA%\Temp (NTFS, fixed) — also reproduced with TMP redirected to another volume

rea doctor --json: all 9 ghidra checks pass except native_authority → Delete owned object by handle failed [...\rea-native-probe-<32hex>] (Win32 5). available: false.

Determinism: 70+ consecutive failures (50× runtime_create+runtime_close, 20× inspect, plus doctor runs). Zero successes. Not a race on this host.

Reproduction outside REA — the addon loaded directly

const addon = require('rea-agents/native/windows/build/rea-windows-x64.node');
const obs = addon.call('runtime_create', [os.tmpdir(), 'replay-']);  // OK, returns a directory handle
addon.call('runtime_close', [obs.handle]);                           // throws: Delete owned object by handle failed (Win32 5)

The mechanism — faithful Win32 replication

I replicated createRuntime's exact call shape with NtCreateFile (empty directory, private protected DACL O:<user> D:P(A;OICI;FA;;;<user>)(A;OICI;FA;;;SY), FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT, FILE_CREATE), then SetFileInformationByHandle(FileDispositionInfo) on the same handle:

ShareAccess at create delete-by-handle
FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE OK
FILE_SHARE_READ|FILE_SHARE_WRITE (no FILE_SHARE_DELETE) FAIL Win32 5
0 (exclusive) FAIL Win32 5

Independent of the DACL (same result with a default inherited DACL). This is the documented rule — an object open by any handle without FILE_SHARE_DELETE cannot be marked delete-pending — and it matches the observed failure exactly. Two follow-ups on this host:

  • The retained create handle is the blocker: a separate process with full access + full share cannot delete the addon's directory by handle while the addon holds it (fails with the same Win32 5; RemoveDirectoryW → ERROR_SHARING_VIOLATION). After the addon process exits, the same external delete succeeds.
  • A failed runtime_close does not release the blocking handle — the external delete still fails afterwards, and only process exit releases it.

Ruled out on this host

  • Node version (24 / 22.22 / 22.17 all fail), temp location (two volumes), AV (Defender real-time on, no third-party product; failed both with and without — cf. @ranceil), reboot (cf. @ranceil), elevation (medium integrity, UAC-filtered admin token, TokenRestrictedSids = 0), reparse points, DACL contents (FA includes DELETE), directory emptiness, external/persistent holders (leaked probe dirs are deletable once the creating process exits).
  • Process injection: this host injects a sandbox DLL (tsbx.dll, hooks NtCreateFile/NtOpenFile/NtSetInformationFile) into agent-spawned processes. Ruled out as the cause: an injected Python process creates and deletes directories by handle without issue, and a directory created by an injected Node process via fs.mkdirSync is deletable externally. No shadow handles are held.

Suggested fix (concrete)

In createRuntime, add FILE_SHARE_DELETE to the ShareAccess passed to NtCreateFile for the owned directory. Alternatively/additionally, in closeRuntime, re-open the object by path with DELETE + full share and close the retained original before the disposition call — but note the re-open alone is insufficient while the original (share-without-DELETE) handle is still open, per the matrix above.

Two secondary asks, unchanged from the original report:

  1. Don't leak the probe object when the self-test fails (310 accumulated during this investigation — I cleaned them up).
  2. Distinguish "platform not implemented" from "self-test failed" in the remediation text; the current wording implies a setup fix is possible.

Happy to run any instrumented build on this host — notably NtQueryObject(ObjectBasicInformation) on the creation handle and the frame duplicate at the point of failure, which would confirm the granted mask directly (I cannot extract the handle through the addon's opaque wrapper).

<!-- gh-comment-id:6120194948 --> @liudong-geek commented on GitHub (Oct 12, 2026): Fourth independent host — **100% deterministic failure**, plus a faithful native replication that pins the mechanism. ## Environment | | | |---|---| | REA | `rea-agents@6.4.0` (npm, global) — also reproduced with the isolated replay below | | Host | Windows 11 Home China, **26H2, build 26300.9457** — *the same build as @pablodiazjorge's passing host* | | Node | v24.14.0, v22.22.2, v22.17.0 — **all three fail identically** | | Ghidra | 12.1.4 PUBLIC, `application.java.min=21`, native decompiler present | | JDK | Temurin 21.0.12 (64-bit, full JDK, javac present) | | Temp | `%LOCALAPPDATA%\Temp` (NTFS, fixed) — also reproduced with TMP redirected to another volume | `rea doctor --json`: all 9 ghidra checks pass except `native_authority` → `Delete owned object by handle failed [...\rea-native-probe-<32hex>] (Win32 5)`. `available: false`. **Determinism**: 70+ consecutive failures (50× `runtime_create`+`runtime_close`, 20× `inspect`, plus doctor runs). Zero successes. Not a race on this host. ## Reproduction outside REA — the addon loaded directly ```js const addon = require('rea-agents/native/windows/build/rea-windows-x64.node'); const obs = addon.call('runtime_create', [os.tmpdir(), 'replay-']); // OK, returns a directory handle addon.call('runtime_close', [obs.handle]); // throws: Delete owned object by handle failed (Win32 5) ``` ## The mechanism — faithful Win32 replication I replicated `createRuntime`'s exact call shape with `NtCreateFile` (empty directory, private protected DACL `O:<user> D:P(A;OICI;FA;;;<user>)(A;OICI;FA;;;SY)`, `FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT`, `FILE_CREATE`), then `SetFileInformationByHandle(FileDispositionInfo)` on the same handle: | ShareAccess at create | delete-by-handle | |---|---| | `FILE_SHARE_READ\|FILE_SHARE_WRITE\|FILE_SHARE_DELETE` | **OK** | | `FILE_SHARE_READ\|FILE_SHARE_WRITE` (no `FILE_SHARE_DELETE`) | **FAIL Win32 5** | | `0` (exclusive) | **FAIL Win32 5** | Independent of the DACL (same result with a default inherited DACL). This is the documented rule — an object open by *any* handle without `FILE_SHARE_DELETE` cannot be marked delete-pending — and it matches the observed failure exactly. Two follow-ups on this host: - The retained create handle is the blocker: a **separate** process with full access + full share cannot delete the addon's directory by handle while the addon holds it (fails with the same Win32 5; `RemoveDirectoryW` → ERROR_SHARING_VIOLATION). After the addon process exits, the same external delete succeeds. - A failed `runtime_close` does **not** release the blocking handle — the external delete still fails afterwards, and only process exit releases it. ## Ruled out on this host - **Node version** (24 / 22.22 / 22.17 all fail), **temp location** (two volumes), **AV** (Defender real-time on, no third-party product; failed both with and without — cf. @ranceil), **reboot** (cf. @ranceil), **elevation** (medium integrity, UAC-filtered admin token, `TokenRestrictedSids` = 0), **reparse points**, **DACL contents** (FA includes DELETE), **directory emptiness**, **external/persistent holders** (leaked probe dirs are deletable once the creating process exits). - **Process injection**: this host injects a sandbox DLL (`tsbx.dll`, hooks `NtCreateFile`/`NtOpenFile`/`NtSetInformationFile`) into agent-spawned processes. Ruled out as the cause: an injected Python process creates and deletes directories by handle without issue, and a directory created by an injected Node process via `fs.mkdirSync` is deletable externally. No shadow handles are held. ## Suggested fix (concrete) In `createRuntime`, add `FILE_SHARE_DELETE` to the `ShareAccess` passed to `NtCreateFile` for the owned directory. Alternatively/additionally, in `closeRuntime`, re-open the object by path with `DELETE` + full share and close the retained original before the disposition call — but note the re-open alone is insufficient while the original (share-without-DELETE) handle is still open, per the matrix above. Two secondary asks, unchanged from the original report: 1. Don't leak the probe object when the self-test fails (310 accumulated during this investigation — I cleaned them up). 2. Distinguish "platform not implemented" from "self-test failed" in the remediation text; the current wording implies a setup fix is possible. Happy to run any instrumented build on this host — notably `NtQueryObject(ObjectBasicInformation)` on the creation handle and the frame duplicate at the point of failure, which would confirm the granted mask directly (I cannot extract the handle through the addon's opaque wrapper).
Author
Owner

@pablodiazjorge commented on GitHub (Oct 12, 2026):

Data point for the share-mode theory from the passing host in my earlier comment, on the same Windows build as @liudong-geek: Windows 11 Pro 26H2, build 26300.9457, non-elevated, Defender real-time on, no other security product. The test processes load only Windows and Node modules (PowerShell adds Defender's AMSI provider); nothing hooks NtCreateFile or NtSetInformationFile.

Your addon replay, unchanged. rea-agents@6.4.0 from npm, rea-windows-x64.node loaded directly, runtime_create then runtime_close in os.tmpdir(), Node 22.22.3: 50/50 succeed, no probe directories left behind.

Your share-mode matrix, plus the granted mask. NtCreateFile with the access mask createRelative uses (DELETE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | READ_CONTROL | SYNCHRONIZE), FILE_CREATE and FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_OPEN_REPARSE_POINT; then NtQueryObject(ObjectBasicInformation) on that handle, and SetFileInformationByHandle(FileDispositionInfo) on the same handle. 20 runs per row:

ShareAccess at create GrantedAccess Delete by handle Left behind
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE 0x130081 OK 20/20 0
FILE_SHARE_READ | FILE_SHARE_WRITE 0x130081 OK 20/20 0
FILE_SHARE_READ (what createRelative passes today, native/windows/src/filesystem.cc:168) 0x130081 OK 20/20 0
0 (exclusive) 0x130081 OK 20/20 0

0x130081 is exactly the requested mask, DELETE (0x10000) included. On a host without instrumentation, the creating handle's own share mode does not stop its own disposition; share access only constrains other opens. That is consistent with the addon passing here although createRelative omits FILE_SHARE_DELETE.

What this suggests. The build and the share mode are the same on both hosts, so they do not explain the difference. Your host injects tsbx.dll, which hooks NtCreateFile, NtOpenFile and NtSetInformationFile, into agent-spawned processes. If the matrix ran from one of those processes, the hook may be what turns the disposition into Win32 5.

On the instrumented build. You don't need one for the granted mask: your matrix owns its handle, so NtQueryObject(ObjectBasicInformation) right after NtCreateFile gives GrantedAccess directly, as in the table above. Two runs would settle it:

  1. The matrix with GrantedAccess, from an agent-spawned process and again from a terminal you open yourself outside the sandbox.
  2. The addon replay from that same plain terminal.

If DELETE is missing from GrantedAccess inside the sandbox, or both runs pass outside it, the cause is the hook and not rea.

On the suggested fixes. Adding FILE_SHARE_DELETE would let other processes open the private runtime directory with DELETE access, which the runtime avoids on purpose (see the comment above runtime_open in filesystem.cc). The alternative, closing the retained original and re-opening by path before the disposition, gives up the handle that keeps the directory from being replaced between creation and cleanup. Both trade a protection for a failure that does not reproduce on an uninstrumented host, so I would wait until the hook is ruled out. Your two secondary asks stand either way: the probe should not leak when the self-test fails, and #2108 now proposes telling a failed self-test apart from an unsupported host.

Happy to share both scripts.

<!-- gh-comment-id:6121147310 --> @pablodiazjorge commented on GitHub (Oct 12, 2026): Data point for the share-mode theory from the passing host in my earlier comment, on the same Windows build as @liudong-geek: Windows 11 Pro 26H2, build 26300.9457, non-elevated, Defender real-time on, no other security product. The test processes load only Windows and Node modules (PowerShell adds Defender's AMSI provider); nothing hooks `NtCreateFile` or `NtSetInformationFile`. **Your addon replay, unchanged.** `rea-agents@6.4.0` from npm, `rea-windows-x64.node` loaded directly, `runtime_create` then `runtime_close` in `os.tmpdir()`, Node 22.22.3: 50/50 succeed, no probe directories left behind. **Your share-mode matrix, plus the granted mask.** `NtCreateFile` with the access mask `createRelative` uses (`DELETE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | READ_CONTROL | SYNCHRONIZE`), `FILE_CREATE` and `FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_OPEN_REPARSE_POINT`; then `NtQueryObject(ObjectBasicInformation)` on that handle, and `SetFileInformationByHandle(FileDispositionInfo)` on the same handle. 20 runs per row: | ShareAccess at create | GrantedAccess | Delete by handle | Left behind | |---|---|---|---| | `FILE_SHARE_READ \| FILE_SHARE_WRITE \| FILE_SHARE_DELETE` | `0x130081` | OK 20/20 | 0 | | `FILE_SHARE_READ \| FILE_SHARE_WRITE` | `0x130081` | OK 20/20 | 0 | | `FILE_SHARE_READ` (what `createRelative` passes today, `native/windows/src/filesystem.cc:168`) | `0x130081` | OK 20/20 | 0 | | `0` (exclusive) | `0x130081` | OK 20/20 | 0 | `0x130081` is exactly the requested mask, `DELETE` (`0x10000`) included. On a host without instrumentation, the creating handle's own share mode does not stop its own disposition; share access only constrains other opens. That is consistent with the addon passing here although `createRelative` omits `FILE_SHARE_DELETE`. **What this suggests.** The build and the share mode are the same on both hosts, so they do not explain the difference. Your host injects `tsbx.dll`, which hooks `NtCreateFile`, `NtOpenFile` and `NtSetInformationFile`, into agent-spawned processes. If the matrix ran from one of those processes, the hook may be what turns the disposition into Win32 5. **On the instrumented build.** You don't need one for the granted mask: your matrix owns its handle, so `NtQueryObject(ObjectBasicInformation)` right after `NtCreateFile` gives `GrantedAccess` directly, as in the table above. Two runs would settle it: 1. The matrix with `GrantedAccess`, from an agent-spawned process and again from a terminal you open yourself outside the sandbox. 2. The addon replay from that same plain terminal. If `DELETE` is missing from `GrantedAccess` inside the sandbox, or both runs pass outside it, the cause is the hook and not rea. **On the suggested fixes.** Adding `FILE_SHARE_DELETE` would let other processes open the private runtime directory with `DELETE` access, which the runtime avoids on purpose (see the comment above `runtime_open` in `filesystem.cc`). The alternative, closing the retained original and re-opening by path before the disposition, gives up the handle that keeps the directory from being replaced between creation and cleanup. Both trade a protection for a failure that does not reproduce on an uninstrumented host, so I would wait until the hook is ruled out. Your two secondary asks stand either way: the probe should not leak when the self-test fails, and #2108 now proposes telling a failed self-test apart from an unsupported host. Happy to share both scripts.
Author
Owner

@xiaojianghoo-sys commented on GitHub (Oct 12, 2026):

<html>

Another data point — and the first Windows 10 host so far (all previous reports are Windows 11).

Environment

  |   -- | -- REA | rea-agents@6.4.0 from npm, isolated project install (not global) Host | Windows 10 Education 22H2, build 19045 (10.0.19045), x64 Volume | C: NTFS, fixed Node | v22.22.2 (only runtime on the host) Third-party AV | Huorong (火绒) HIPS resident (HipsTray.exe) Temp | default %LOCALAPPDATA%\Temp; also reproduced with process-local TMP/TEMP redirected to another NTFS path

Result: 100% deterministic on this host

5/5 consecutive analyze-javascript-application runs failed identically, plus ~20 further runs across the session:

REA Windows native controls are unavailable: Delete owned object by handle failed
[C:\Users\<user>\AppData\Local\Temp\rea-native-probe-<32hex>] (Win32 5): 拒绝访问

Same signature as the original report and @liudong-geek's replication — object creation succeeds, only delete-by-handle fails, and empty probe directories leak (13 accumulated during my session; cleaned manually with rmdir).

Impact is wider than the Ghidra lane

On this host the same native-authority failure also hard-gates the JavaScript static-analysis provider:

rea analyze-javascript-application <dir>
→ code: capability_unavailable
"Provider javascript-static-analysis cannot execute analyze_javascript_application:
  REA Windows native controls are unavailable: Delete owned object by handle failed ... (Win32 5)"

The MCP path behaves the same: initialize + tools/list succeed (177 tools advertised), but any tool routed through the gated provider returns capability_unavailable with the native-authority cause. Provider-independent tooling works — verified inspect_pe_resources end-to-end via MCP tools/call against C:\Windows\System32\notepad.exe (full Evidence record returned).

Notes against the existing ruled-out list

  • AV: Huorong HIPS is resident here. Combined with @ranceil's both-directions test, AV stays ruled out as the universal cause (though per-host interception cannot be excluded).

  • Temp location: redirecting TMP/TEMP to a different NTFS path did not change the outcome — consistent with @liudong-geek.

  • Mechanism: matches @liudong-geek's share-mode replication; the retained create handle appears to lack FILE_SHARE_DELETE, so the object cannot be marked delete-pending.

Cannot verify the fix locally

No Visual Studio / MSVC build tools on this host, so building the addon from main (npm run build:windows-native) to check #1826 / #1863 is not possible here. Confirmation of which release will carry the fix would help — happy to re-verify on npm update once it ships.

Thanks to everyone who narrowed this down — the share-mode replication in particular made the cause obvious.

</html>

rea-issue-1701-comment.md

<!-- gh-comment-id:6126220073 --> @xiaojianghoo-sys commented on GitHub (Oct 12, 2026): <html> <body> <!--StartFragment--><!DOCTYPE html><p cid="n0" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0.8em 0px; white-space: pre-wrap; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain md-expand" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Another data point — and the first </span><span md-inline="strong" class="md-pair-s " style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><strong style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Windows 10</span></strong></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> host so far (all previous reports are Windows 11).</span></p><h3 cid="n2" mdtype="heading" class="md-end-block md-heading" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; white-space: pre-wrap; break-after: avoid-page; break-inside: avoid; orphans: 4; font-size: 1.5em; margin-top: 1rem; margin-bottom: 1rem; position: relative; font-weight: bold; line-height: 1.43; cursor: text; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Environment</span></h3><figure class="md-table-fig table-figure" cid="n3" mdtype="table" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; margin: 1.2em 0px; overflow-x: auto; max-width: calc(100% + 16px); padding: 0px; cursor: default; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">   |   -- | -- REA | rea-agents@6.4.0 from npm, isolated project install (not global) Host | Windows 10 Education 22H2, build 19045 (10.0.19045), x64 Volume | C: NTFS, fixed Node | v22.22.2 (only runtime on the host) Third-party AV | Huorong (火绒) HIPS resident (HipsTray.exe) Temp | default %LOCALAPPDATA%\Temp; also reproduced with process-local TMP/TEMP redirected to another NTFS path </figure><h3 cid="n25" mdtype="heading" class="md-end-block md-heading" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; white-space: pre-wrap; break-after: avoid-page; break-inside: avoid; orphans: 4; font-size: 1.5em; margin-top: 1rem; margin-bottom: 1rem; position: relative; font-weight: bold; line-height: 1.43; cursor: text; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Result: 100% deterministic on this host</span></h3><p cid="n26" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0.8em 0px; white-space: pre-wrap; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">5/5 consecutive </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">analyze-javascript-application</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> runs failed identically, plus ~20 further runs across the session:</span></p><pre class="md-fences md-end-block ty-contain-cm modeLoaded" spellcheck="false" lang="" cid="n27" mdtype="fences" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; overflow: visible; font-family: var(--monospace); font-size: 0.9em; display: block; break-inside: avoid; text-align: left; white-space: pre; background-image: inherit; background-position: inherit; background-size: inherit; background-repeat: inherit; background-attachment: inherit; background-origin: inherit; background-clip: inherit; background-color: rgb(248, 248, 248); border: 1px solid rgb(231, 234, 237); border-radius: 3px; padding: 8px 4px 6px; margin-bottom: 15px; margin-top: 15px; width: inherit; color: rgb(51, 51, 51); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; position: relative !important;"><span role="presentation" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; padding-right: 0.1px;">REA Windows native controls are unavailable: Delete owned object by handle failed</span><br><span role="presentation" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; padding-right: 0.1px;">[C:\Users\&lt;user&gt;\AppData\Local\Temp\rea-native-probe-&lt;32hex&gt;] (Win32 5): 拒绝访问</span></pre><p cid="n28" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0.8em 0px; white-space: pre-wrap; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Same signature as the original report and @liudong-geek's replication — object creation succeeds, only delete-by-handle fails, and empty probe directories leak (13 accumulated during my session; cleaned manually with </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">rmdir</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">).</span></p><h3 cid="n29" mdtype="heading" class="md-end-block md-heading" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; white-space: pre-wrap; break-after: avoid-page; break-inside: avoid; orphans: 4; font-size: 1.5em; margin-top: 1rem; margin-bottom: 1rem; position: relative; font-weight: bold; line-height: 1.43; cursor: text; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Impact is wider than the Ghidra lane</span></h3><p cid="n30" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0.8em 0px; white-space: pre-wrap; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">On this host the same native-authority failure also hard-gates the </span><span md-inline="strong" class="md-pair-s " style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><strong style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">JavaScript static-analysis provider</span></strong></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">:</span></p><pre class="md-fences md-end-block ty-contain-cm modeLoaded" spellcheck="false" lang="" cid="n31" mdtype="fences" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; overflow: visible; font-family: var(--monospace); font-size: 0.9em; display: block; break-inside: avoid; text-align: left; white-space: pre; background-image: inherit; background-position: inherit; background-size: inherit; background-repeat: inherit; background-attachment: inherit; background-origin: inherit; background-clip: inherit; background-color: rgb(248, 248, 248); border: 1px solid rgb(231, 234, 237); border-radius: 3px; padding: 8px 4px 6px; margin-bottom: 15px; margin-top: 15px; width: inherit; color: rgb(51, 51, 51); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; position: relative !important;"><span role="presentation" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; padding-right: 0.1px;">rea analyze-javascript-application &lt;dir&gt;</span><br><span role="presentation" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; padding-right: 0.1px;">→ code: capability_unavailable</span><br><span role="presentation" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; padding-right: 0.1px;"> "Provider javascript-static-analysis cannot execute analyze_javascript_application:</span><br><span role="presentation" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; padding-right: 0.1px;"> &nbsp; REA Windows native controls are unavailable: Delete owned object by handle failed ... (Win32 5)"</span></pre><p cid="n32" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0.8em 0px; white-space: pre-wrap; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">The MCP path behaves the same: </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">initialize</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> + </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">tools/list</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> succeed (177 tools advertised), but any tool routed through the gated provider returns </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">capability_unavailable</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> with the native-authority cause. Provider-independent tooling works — verified </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">inspect_pe_resources</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> end-to-end via MCP </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">tools/call</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> against </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">C:\Windows\System32\notepad.exe</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> (full Evidence record returned).</span></p><h3 cid="n33" mdtype="heading" class="md-end-block md-heading" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; white-space: pre-wrap; break-after: avoid-page; break-inside: avoid; orphans: 4; font-size: 1.5em; margin-top: 1rem; margin-bottom: 1rem; position: relative; font-weight: bold; line-height: 1.43; cursor: text; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Notes against the existing ruled-out list</span></h3><ul class="ul-list" cid="n34" mdtype="list" data-mark="-" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; margin: 0.8em 0px; padding-left: 30px; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><li class="md-list-item" cid="n35" mdtype="list_item" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; margin: 0px; position: relative;"><p cid="n36" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0px 0px 0.5rem; white-space: pre-wrap; position: relative;"><span md-inline="strong" class="md-pair-s " style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><strong style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">AV</span></strong></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">: Huorong HIPS is resident here. Combined with @ranceil's both-directions test, AV stays ruled out as the universal cause (though per-host interception cannot be excluded).</span></p></li><li class="md-list-item" cid="n37" mdtype="list_item" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; margin: 0px; position: relative;"><p cid="n38" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0px 0px 0.5rem; white-space: pre-wrap; position: relative;"><span md-inline="strong" class="md-pair-s " style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><strong style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Temp location</span></strong></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">: redirecting </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">TMP</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">/</span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">TEMP</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> to a different NTFS path did not change the outcome — consistent with @liudong-geek.</span></p></li><li class="md-list-item" cid="n39" mdtype="list_item" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; margin: 0px; position: relative;"><p cid="n40" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0px 0px 0.5rem; white-space: pre-wrap; position: relative;"><span md-inline="strong" class="md-pair-s " style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><strong style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Mechanism</span></strong></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">: matches @liudong-geek's share-mode replication; the retained create handle appears to lack </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">FILE_SHARE_DELETE</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">, so the object cannot be marked delete-pending.</span></p></li></ul><h3 cid="n41" mdtype="heading" class="md-end-block md-heading" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; white-space: pre-wrap; break-after: avoid-page; break-inside: avoid; orphans: 4; font-size: 1.5em; margin-top: 1rem; margin-bottom: 1rem; position: relative; font-weight: bold; line-height: 1.43; cursor: text; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Cannot verify the fix locally</span></h3><p cid="n42" mdtype="paragraph" class="md-end-block md-p" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0.8em 0px; white-space: pre-wrap; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">No Visual Studio / MSVC build tools on this host, so building the addon from main (</span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">npm run build:windows-native</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">) to check #1826 / #1863 is not possible here. Confirmation of which release will carry the fix would help — happy to re-verify on </span><span md-inline="code" spellcheck="false" class="md-pair-s" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"><code style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; font-family: var(--monospace); text-align: left; vertical-align: initial; border: 1px solid rgb(231, 234, 237); background-color: rgb(243, 244, 244); border-radius: 3px; padding: 0px 2px; font-size: 0.9em;">npm update</code></span><span md-inline="plain" class="md-plain" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;"> once it ships.</span></p><p cid="n43" mdtype="paragraph" class="md-end-block md-p md-focus" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ; line-height: inherit; orphans: 4; margin: 0.8em 0px; white-space: pre-wrap; position: relative; color: rgb(51, 51, 51); font-family: &quot;Open Sans&quot;, &quot;Clear Sans&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, &quot;Segoe UI Emoji&quot;, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span md-inline="plain" class="md-plain md-expand" style="box-sizing: border-box; --tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; --tw-rotate: 0; --tw-skew-x: 0; --tw-skew-y: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-pan-x: ; --tw-pan-y: ; --tw-pinch-zoom: ; --tw-scroll-snap-strictness: proximity; --tw-ordinal: ; --tw-slashed-zero: ; --tw-numeric-figure: ; --tw-numeric-spacing: ; --tw-numeric-fraction: ; --tw-ring-inset: ; --tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; --tw-ring-color: rgb(59 130 246 / .5); --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-shadow-colored: 0 0 #0000; --tw-blur: ; --tw-brightness: ; --tw-contrast: ; --tw-grayscale: ; --tw-hue-rotate: ; --tw-invert: ; --tw-saturate: ; --tw-sepia: ; --tw-drop-shadow: ; --tw-backdrop-blur: ; --tw-backdrop-brightness: ; --tw-backdrop-contrast: ; --tw-backdrop-grayscale: ; --tw-backdrop-hue-rotate: ; --tw-backdrop-invert: ; --tw-backdrop-opacity: ; --tw-backdrop-saturate: ; --tw-backdrop-sepia: ;">Thanks to everyone who narrowed this down — the share-mode replication in particular made the cause obvious.</span></p><!--EndFragment--> </body> </html> [rea-issue-1701-comment.md](https://github.com/user-attachments/files/33342117/rea-issue-1701-comment.md)
Author
Owner

@xiaojianghoo-sys commented on GitHub (Oct 12, 2026):

Another data point — and the first Windows 10 host so far (all previous reports are Windows 11).

Environment

  • REA: rea-agents@6.4.0 from npm, isolated project install (not global)
  • Host: Windows 10 Education 22H2, build 19045 (10.0.19045), x64
  • Volume: C: NTFS, fixed
  • Node: v22.22.2 (only runtime on the host)
  • Third-party AV: Huorong (火绒) HIPS resident (HipsTray.exe)
  • Temp: default %LOCALAPPDATA%\Temp; also reproduced with process-local TMP/TEMP redirected to another NTFS path

Result: 100% deterministic on this host

5/5 consecutive analyze-javascript-application runs failed identically, plus ~20 further runs across the session:

REA Windows native controls are unavailable: Delete owned object by handle failed
[C:\Users\<user>\AppData\Local\Temp\rea-native-probe-<32hex>] (Win32 5): 拒绝访问

Same signature as the original report and @liudong-geek's replication — object creation succeeds, only delete-by-handle fails, and empty probe directories leak (13 accumulated during my session; cleaned manually with rmdir).

Impact is wider than the Ghidra lane

On this host the same native-authority failure also hard-gates the JavaScript static-analysis provider:

rea analyze-javascript-application <dir>
→ code: capability_unavailable
  "Provider javascript-static-analysis cannot execute analyze_javascript_application:
   REA Windows native controls are unavailable: Delete owned object by handle failed ... (Win32 5)"

The MCP path behaves the same: initialize + tools/list succeed (177 tools advertised), but any tool routed through the gated provider returns capability_unavailable with the native-authority cause. Provider-independent tooling works — verified inspect_pe_resources end-to-end via MCP tools/call against C:\Windows\System32\notepad.exe (full Evidence record returned).

Notes against the existing ruled-out list

  • AV: Huorong HIPS is resident here. Combined with @ranceil's both-directions test, AV stays ruled out as the universal cause (though per-host interception cannot be excluded).
  • Temp location: redirecting TMP/TEMP to a different NTFS path did not change the outcome — consistent with @liudong-geek.
  • Mechanism: matches @liudong-geek's share-mode replication; the retained create handle appears to lack FILE_SHARE_DELETE, so the object cannot be marked delete-pending.

Cannot verify the fix locally

No Visual Studio / MSVC build tools on this host, so building the addon from main (npm run build:windows-native) to check #1826 / #1863 is not possible here. Confirmation of which release will carry the fix would help — happy to re-verify on npm update once it ships.

Thanks to everyone who narrowed this down — the share-mode replication in particular made the cause obvious.

<!-- gh-comment-id:6127018954 --> @xiaojianghoo-sys commented on GitHub (Oct 12, 2026): Another data point — and the first **Windows 10** host so far (all previous reports are Windows 11). ### Environment - REA: `rea-agents@6.4.0` from npm, isolated project install (not global) - Host: Windows 10 **Education** 22H2, build **19045** (10.0.19045), x64 - Volume: `C:` NTFS, fixed - Node: v22.22.2 (only runtime on the host) - Third-party AV: Huorong (火绒) HIPS resident (`HipsTray.exe`) - Temp: default `%LOCALAPPDATA%\Temp`; also reproduced with process-local `TMP`/`TEMP` redirected to another NTFS path ### Result: 100% deterministic on this host 5/5 consecutive `analyze-javascript-application` runs failed identically, plus ~20 further runs across the session: ``` REA Windows native controls are unavailable: Delete owned object by handle failed [C:\Users\<user>\AppData\Local\Temp\rea-native-probe-<32hex>] (Win32 5): 拒绝访问 ``` Same signature as the original report and @liudong-geek's replication — object creation succeeds, only delete-by-handle fails, and empty probe directories leak (13 accumulated during my session; cleaned manually with `rmdir`). ### Impact is wider than the Ghidra lane On this host the same native-authority failure also hard-gates the **JavaScript static-analysis provider**: ``` rea analyze-javascript-application <dir> → code: capability_unavailable "Provider javascript-static-analysis cannot execute analyze_javascript_application: REA Windows native controls are unavailable: Delete owned object by handle failed ... (Win32 5)" ``` The MCP path behaves the same: `initialize` + `tools/list` succeed (177 tools advertised), but any tool routed through the gated provider returns `capability_unavailable` with the native-authority cause. Provider-independent tooling works — verified `inspect_pe_resources` end-to-end via MCP `tools/call` against `C:\Windows\System32\notepad.exe` (full Evidence record returned). ### Notes against the existing ruled-out list - **AV**: Huorong HIPS is resident here. Combined with @ranceil's both-directions test, AV stays ruled out as the universal cause (though per-host interception cannot be excluded). - **Temp location**: redirecting `TMP`/`TEMP` to a different NTFS path did not change the outcome — consistent with @liudong-geek. - **Mechanism**: matches @liudong-geek's share-mode replication; the retained create handle appears to lack `FILE_SHARE_DELETE`, so the object cannot be marked delete-pending. ### Cannot verify the fix locally No Visual Studio / MSVC build tools on this host, so building the addon from main (`npm run build:windows-native`) to check #1826 / #1863 is not possible here. Confirmation of which release will carry the fix would help — happy to re-verify on `npm update` once it ships. Thanks to everyone who narrowed this down — the share-mode replication in particular made the cause obvious.
Author
Owner

@chqcjq commented on GitHub (Oct 12, 2026):

Source analysis of the failing delete (addon reads, not a fix claim)

I traced the probe lifecycle in the bundled addon source (main 7ae3c50a, matching the npm artifact SHA c4fd9f37):

inspect() (process.cc:415) → createRuntime(temp, 'rea-native-probe-') (filesystem.cc:214) → createRelative(parent, name, DELETE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | READ_CONTROL, ...) (filesystem.cc:154) → NtCreateFile(..., FILE_SHARE_READ, FILE_CREATE, FILE_DIRECTORY_FILE, ...) (filesystem.cc:167) → identity(env, probe->directory.get(), ...) (filesystem.cc:80) → closeRuntime(*probe) (filesystem.cc:330) → DuplicateHandle(root.directory) — same access mask, includes DELETE → Frame(directory): FindFirstFileExW → empty dir → pending=false → dispose(frame.directory) (filesystem.cc:299) → SetFileInformationByHandle(handle, FileDispositionInfo, TRUE)

Key observation: the handle used for deletion does carry DELETE access — createRelative requests DELETE | ... at line 165, and closeRuntime duplicates that same handle at line 352. The probe directory is empty, so ERROR_DIR_NOT_EMPTY (145) is ruled out, matching the report.

Why some hosts pass and others fail: on a Windows 11 build 22631 host with UAC disabled (EnableLUA=0) and an elevated Administrator token, the same npm artifact's self-test passes cleanly (no residual probe directories). All failing reports are on UAC-enabled hosts with non-elevated or Medium-integrity tokens. The difference may be in how the object manager grants the requested access mask at creation time under different integrity/token configurations — worth instrumenting the self-test to report the granted access mask of the probe directory handle (via GetGrantedAccess or AccessCheck) rather than the requested one, as the issue already suggests.

This confirms the failure is not in share-mode flags (the handle is deleted through SetFileInformationByHandle, not a separate open) and not in the DACL (which grants FILE_ALL_ACCESS including DELETE). The remaining variable is the granted access mask on the creation handle itself under non-elevated tokens.

<!-- gh-comment-id:6127278055 --> @chqcjq commented on GitHub (Oct 12, 2026): ### Source analysis of the failing delete (addon reads, not a fix claim) I traced the probe lifecycle in the bundled addon source (main 7ae3c50a, matching the npm artifact SHA c4fd9f37): ` inspect() (process.cc:415) → createRuntime(temp, 'rea-native-probe-') (filesystem.cc:214) → createRelative(parent, name, DELETE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | READ_CONTROL, ...) (filesystem.cc:154) → NtCreateFile(..., FILE_SHARE_READ, FILE_CREATE, FILE_DIRECTORY_FILE, ...) (filesystem.cc:167) → identity(env, probe->directory.get(), ...) (filesystem.cc:80) → closeRuntime(*probe) (filesystem.cc:330) → DuplicateHandle(root.directory) — same access mask, includes DELETE → Frame(directory): FindFirstFileExW → empty dir → pending=false → dispose(frame.directory) (filesystem.cc:299) → SetFileInformationByHandle(handle, FileDispositionInfo, TRUE) ` Key observation: **the handle used for deletion does carry DELETE access** — createRelative requests DELETE | ... at line 165, and closeRuntime duplicates that same handle at line 352. The probe directory is empty, so ERROR_DIR_NOT_EMPTY (145) is ruled out, matching the report. **Why some hosts pass and others fail:** on a Windows 11 build 22631 host with UAC disabled (EnableLUA=0) and an elevated Administrator token, the same npm artifact's self-test passes cleanly (no residual probe directories). All failing reports are on UAC-enabled hosts with non-elevated or Medium-integrity tokens. The difference may be in how the object manager grants the requested access mask at creation time under different integrity/token configurations — worth instrumenting the self-test to report the *granted* access mask of the probe directory handle (via GetGrantedAccess or AccessCheck) rather than the requested one, as the issue already suggests. This confirms the failure is not in share-mode flags (the handle is deleted through SetFileInformationByHandle, not a separate open) and not in the DACL (which grants FILE_ALL_ACCESS including DELETE). The remaining variable is the granted access mask on the creation handle itself under non-elevated tokens.
Author
Owner

@Rinkia commented on GitHub (Oct 12, 2026):

Fifth host, passing, with a source-built addon — plus one measurement that I think narrows the mechanism, because it does not reproduce @liudong-geek's matrix row 2.

Environment

REA source-built from main at 5190843 (includes #1826), addon cross-compiled with the documented lane (Linux + MinGW-w64 g++ 12), abiVersion: 1, nodeApiVersion: 8
Host Windows 11 Pro 26100, x64, 12 logical processors, medium integrity (not elevated)
Node v24.16.0
Volume C: NTFS fixed; default %LOCALAPPDATA%\Temp
AV Defender real-time on, no third-party product, no injected sandbox DLL

Result: 30/30 pass, zero leaked probe directories

requireWindowsNativeAuthority() called 30 times in one process:

{"runs":30,"passed":30,"failed":0,"probeDirsBefore":0,"probeDirsAfter":0,"leaked":0,"distinctFailures":[]}

First inspection reports privateDacl: true, atomicJobAssignment: true, killOnOwnerClose: true, protocolStdin: true, jobMemoryLimit: true, NTFS, directory: true. npm run verify:windows-native with the boundary fixture also passes end to end (20/20 filesystem controls, 12/12 process observations).

The measurement that does not line up

REA creates owned objects with ShareAccess = FILE_SHARE_READ at native/windows/src/filesystem.cc:167 — i.e. without FILE_SHARE_DELETE — and on this host SetFileInformationByHandle(FileDispositionInfo) on that same retained handle succeeds, 30 times out of 30. An isolated replication agrees: an empty directory, one handle opened DELETE | GENERIC_READ | READ_CONTROL with FILE_SHARE_READ and no share-delete, deletes by handle with 0, including while a second read-only opener (FILE_READ_ATTRIBUTES, FILE_SHARE_READ, also not sharing delete) is held open:

control             (no second opener, FileDispositionInfo)  -> 0
scanner handle open (FileDispositionInfo)                    -> 0  [scannerOpened=yes]
scanner handle open (FileDispositionInfoEx + POSIX)          -> 0

So on this host the create-time share mode is not what decides the outcome, which suggests ShareAccess without FILE_SHARE_DELETE is necessary but not sufficient rather than the cause. The documented share rule constrains a new opener against existing opens; a sole handle does not block its own transition to delete-pending here. That a single handle does block it on the failing hosts is the part still unexplained, and it is consistent with a second, unobserved handle on those hosts (filter driver, HIPS, or the injected tsbx.dll on @liudong-geek's) rather than with the share mode alone.

This does not argue against adding FILE_SHARE_DELETE in createRuntime: it is inert on hosts like this one and would make delete-pending reachable wherever something else does hold the object. I would just expect it to be a mitigation whose success on an affected host is the actual evidence, and note it relaxes the exclusivity that filesystem.cc:547 keeps deliberately for snapshot readers, so the call is a maintainer's.

Offer

@liudong-geek asked for NtQueryObject(ObjectBasicInformation) on the creation handle at the point of failure, and several people here (@xiaojianghoo-sys, @liudong-geek) have no MSVC to build with. I have a working cross-build lane and can produce an instrumented rea-windows-x64.node that dumps the granted access mask and the kernel's handle/pointer counts for the probe object immediately before the disposition call, plus a one-command repro, so an affected host can return that measurement. Say the word and the shape you want and I will build it — I cannot reproduce the failure here, so the decisive data has to come from one of the failing hosts.

🤖 Posted by Claude Code

<!-- gh-comment-id:6128245661 --> @Rinkia commented on GitHub (Oct 12, 2026): Fifth host, **passing**, with a source-built addon — plus one measurement that I think narrows the mechanism, because it does not reproduce @liudong-geek's matrix row 2. ### Environment | | | |---|---| | REA | source-built from `main` at `5190843` (includes #1826), addon cross-compiled with the documented lane (Linux + MinGW-w64 g++ 12), `abiVersion: 1`, `nodeApiVersion: 8` | | Host | Windows 11 Pro **26100**, x64, 12 logical processors, medium integrity (not elevated) | | Node | v24.16.0 | | Volume | `C:` NTFS fixed; default `%LOCALAPPDATA%\Temp` | | AV | Defender real-time on, no third-party product, no injected sandbox DLL | ### Result: 30/30 pass, zero leaked probe directories `requireWindowsNativeAuthority()` called 30 times in one process: ``` {"runs":30,"passed":30,"failed":0,"probeDirsBefore":0,"probeDirsAfter":0,"leaked":0,"distinctFailures":[]} ``` First inspection reports `privateDacl: true`, `atomicJobAssignment: true`, `killOnOwnerClose: true`, `protocolStdin: true`, `jobMemoryLimit: true`, NTFS, `directory: true`. `npm run verify:windows-native` with the boundary fixture also passes end to end (20/20 filesystem controls, 12/12 process observations). ### The measurement that does not line up REA creates owned objects with `ShareAccess = FILE_SHARE_READ` at `native/windows/src/filesystem.cc:167` — i.e. **without** `FILE_SHARE_DELETE` — and on this host `SetFileInformationByHandle(FileDispositionInfo)` on that same retained handle **succeeds**, 30 times out of 30. An isolated replication agrees: an empty directory, one handle opened `DELETE | GENERIC_READ | READ_CONTROL` with `FILE_SHARE_READ` and no share-delete, deletes by handle with `0`, including while a second read-only opener (`FILE_READ_ATTRIBUTES`, `FILE_SHARE_READ`, also not sharing delete) is held open: ``` control (no second opener, FileDispositionInfo) -> 0 scanner handle open (FileDispositionInfo) -> 0 [scannerOpened=yes] scanner handle open (FileDispositionInfoEx + POSIX) -> 0 ``` So on this host the create-time share mode is not what decides the outcome, which suggests `ShareAccess` without `FILE_SHARE_DELETE` is **necessary but not sufficient** rather than the cause. The documented share rule constrains a *new* opener against existing opens; a sole handle does not block its own transition to delete-pending here. That a single handle does block it on the failing hosts is the part still unexplained, and it is consistent with a second, unobserved handle on those hosts (filter driver, HIPS, or the injected `tsbx.dll` on @liudong-geek's) rather than with the share mode alone. This does not argue against adding `FILE_SHARE_DELETE` in `createRuntime`: it is inert on hosts like this one and would make delete-pending reachable wherever something else does hold the object. I would just expect it to be a mitigation whose success on an affected host is the actual evidence, and note it relaxes the exclusivity that `filesystem.cc:547` keeps deliberately for snapshot readers, so the call is a maintainer's. ### Offer @liudong-geek asked for `NtQueryObject(ObjectBasicInformation)` on the creation handle at the point of failure, and several people here (@xiaojianghoo-sys, @liudong-geek) have no MSVC to build with. I have a working cross-build lane and can produce an instrumented `rea-windows-x64.node` that dumps the granted access mask and the kernel's handle/pointer counts for the probe object immediately before the disposition call, plus a one-command repro, so an affected host can return that measurement. Say the word and the shape you want and I will build it — I cannot reproduce the failure here, so the decisive data has to come from one of the failing hosts. _🤖 Posted by [Claude Code](https://claude.com/claude-code)_
Author
Owner

@Rinkia commented on GitHub (Oct 12, 2026):

8160 chars
k @xiaojianghoo-sys — here is the instrumented build, as offered. It answers the NtQueryObject question directly and adds the handle/pointer counts, because my passing-host result suggests a second unobserved handle rather than the create-time share mode.

It applies to main at 5190843, compiles clean with the documented MinGW lane, and I verified the resulting addon loads and passes 10/10 on my (non-reproducing) host, so the instrumentation itself does not break the self-test.

What it reports

On the failure path only, one JSON line on stderr immediately before the existing error is raised:

REA_DIAG_1701 {"classicWin32":5,"ntQueryStatus":"0x00000000","grantedAccess":"0x...","handleCount":N,"pointerCount":N,"deletePending":false,"directory":true,"children":0,"posixDispositionWin32":0,"searchable":true}
field settles
grantedAccess whether this handle really holds DELETE (0x00010000) — the mask you could not extract through the opaque wrapper
handleCount / pointerCount the one I most want. handleCount > 1 means something else holds the object and the share mode is the mechanism; handleCount == 1 means a sole handle is blocking its own transition, which is not the documented rule and points elsewhere (filter driver / minifilter behaviour)
deletePending whether a disposition was already staged
children emptiness at the instant of failure, not before it
posixDispositionWin32 whether FileDispositionInfoEx + FILE_DISPOSITION_FLAG_POSIX_SEMANTICS succeeds where the classic call fails — 0 here would make that a candidate fix

Caveat, please read: the POSIX probe is not read-only. Where it reports 0 the object is unlinked then and there, so this build leaks no probe directory in that case. The thrown error keeps the same constraint text and Win32 code as the stock build, so rea doctor output is otherwise unchanged.

Build it yourself (no MSVC needed)

The artifact lane refuses to run outside Linux, but a container satisfies it — this is how I built it on a Windows host with no C++ toolchain at all:

git clone https://github.com/morluto/rea && cd rea && git checkout 5190843
npm ci
# save the patch below as 1701-instrumented.patch
git apply 1701-instrumented.patch
docker run --rm -v "$PWD:/src" -w /src node:22-bookworm bash -lc   "apt-get update && apt-get install -y --no-install-recommends g++-mingw-w64-x86-64 && node scripts/build-windows-native.mjs"

That writes native/windows/build/rea-windows-x64.node (+ manifest.json). Point your installed REA at it, or run from the source tree, then:

rea doctor --provider ghidra --json 2> diag.txt

and paste the REA_DIAG_1701 line. node -e "require('./native/windows/build/rea-windows-x64.node').call('runtime_create',[require('os').tmpdir(),'replay-'])" plus runtime_close works too, per @liudong-geek's replay.

My build for reference: SHA-256 391273937535f6d03bb20a44b27d78629de49c86d930d2dea52a03836de4b08d, 844,998 bytes, abiVersion: 1, nodeApiVersion: 8. I would rather you build from the patch than trust a binary from a stranger, but if a prebuilt .node is genuinely more useful than a container, say so and I will attach one.

1701-instrumented.patch
diff --git a/native/windows/src/filesystem.cc b/native/windows/src/filesystem.cc
index 6cfbc8e..630288d 100644
--- a/native/windows/src/filesystem.cc
+++ b/native/windows/src/filesystem.cc
@@ -1,6 +1,7 @@
 #include "authority.hpp"
 #include <sddl.h>
 #include <winternl.h>
+#include <cstdio>
 
 namespace rea {
 
@@ -296,6 +297,67 @@ static void writeBytes(HANDLE file, const void* bytes, DWORD count, const std::w
   require(WriteFile(file, bytes, count, &written, nullptr) && written == count, "Write private file failed", path);
 }
 
+// INSTRUMENTED DIAGNOSTIC BUILD for morluto/rea#1701 — not for merge.
+// Reports what the kernel knows about the object at the instant delete-by-handle
+// is refused: the granted access mask on this very handle, how many handles and
+// references exist for the object, whether a delete is already pending, how many
+// children it still has, and whether POSIX-semantics disposition would succeed
+// where the classic one did not. Emits one JSON line on stderr and then fails
+// with the same constraint and Win32 code as the unmodified build. Note the
+// POSIX probe is not read-only: where it reports 0 the object is removed then
+// and there, so a diagnostic build leaks no probe directory in that case.
+struct ObjectBasicDiagnostic {
+  ULONG Attributes;
+  ACCESS_MASK GrantedAccess;
+  ULONG HandleCount;
+  ULONG PointerCount;
+  ULONG Reserved[10];
+};
+
+static void diagnoseDisposition(HANDLE handle, const std::wstring& path, DWORD classicError) {
+  ObjectBasicDiagnostic basic{};
+  ULONG basicLength = 0;
+  LONG queryStatus = -1;
+  if (const auto ntdll = GetModuleHandleW(L"ntdll.dll")) {
+    using QueryObject = LONG(NTAPI*)(HANDLE, int, PVOID, ULONG, PULONG);
+    if (const auto query = reinterpret_cast<QueryObject>(
+            reinterpret_cast<void*>(GetProcAddress(ntdll, "NtQueryObject"))))
+      queryStatus = query(handle, 0 /* ObjectBasicInformation */, &basic, sizeof(basic), &basicLength);
+  }
+  FILE_STANDARD_INFO standard{};
+  const bool standardRead =
+      GetFileInformationByHandleEx(handle, FileStandardInfo, &standard, sizeof(standard)) != 0;
+  unsigned children = 0;
+  WIN32_FIND_DATAW found{};
+  const auto search = FindFirstFileW((path + L"\\*").c_str(), &found);
+  if (search != INVALID_HANDLE_VALUE) {
+    do {
+      const std::wstring name(found.cFileName);
+      if (name != L"." && name != L"..") ++children;
+    } while (FindNextFileW(search, &found));
+    FindClose(search);
+  }
+  // FileDispositionInfoEx (21) with DELETE | POSIX_SEMANTICS, Windows 10 1709+.
+  DWORD posixFlags = 0x00000001 | 0x00000002;
+  const bool posix = SetFileInformationByHandle(
+                         handle, static_cast<FILE_INFO_BY_HANDLE_CLASS>(21), &posixFlags,
+                         sizeof(posixFlags)) != 0;
+  const DWORD posixError = posix ? ERROR_SUCCESS : GetLastError();
+  std::fprintf(stderr,
+               "REA_DIAG_1701 {\"classicWin32\":%lu,\"ntQueryStatus\":\"0x%08lX\","
+               "\"grantedAccess\":\"0x%08lX\",\"handleCount\":%lu,\"pointerCount\":%lu,"
+               "\"deletePending\":%s,\"directory\":%s,\"children\":%u,"
+               "\"posixDispositionWin32\":%lu,\"searchable\":%s}\n",
+               classicError, static_cast<unsigned long>(queryStatus),
+               static_cast<unsigned long>(basic.GrantedAccess),
+               static_cast<unsigned long>(basic.HandleCount),
+               static_cast<unsigned long>(basic.PointerCount),
+               standardRead && standard.DeletePending ? "true" : "false",
+               standardRead && standard.Directory ? "true" : "false", children, posixError,
+               search != INVALID_HANDLE_VALUE ? "true" : "false");
+  std::fflush(stderr);
+}
+
 static void dispose(HANDLE handle, const std::wstring& path) {
   FILE_BASIC_INFO info{};
   require(GetFileInformationByHandleEx(handle, FileBasicInfo, &info, sizeof(info)), "Read cleanup attributes failed", path);
@@ -304,7 +366,11 @@ static void dispose(HANDLE handle, const std::wstring& path) {
     require(SetFileInformationByHandle(handle, FileBasicInfo, &info, sizeof(info)), "Clear owned readonly attribute failed", path);
   }
   FILE_DISPOSITION_INFO deletion{TRUE};
-  require(SetFileInformationByHandle(handle, FileDispositionInfo, &deletion, sizeof(deletion)), "Delete owned object by handle failed", path);
+  if (!SetFileInformationByHandle(handle, FileDispositionInfo, &deletion, sizeof(deletion))) {
+    const DWORD classicError = GetLastError();
+    diagnoseDisposition(handle, path, classicError);
+    require(false, "Delete owned object by handle failed", path, classicError);
+  }
 }
 
 static void disposeSnapshot(Runtime& root, Handle& file, const std::wstring& path) {

🤖 Posted by Claude Code

<!-- gh-comment-id:6130599030 --> @Rinkia commented on GitHub (Oct 12, 2026): 8160 chars k @xiaojianghoo-sys — here is the instrumented build, as offered. It answers the `NtQueryObject` question directly and adds the handle/pointer counts, because my passing-host result suggests a second unobserved handle rather than the create-time share mode. It applies to `main` at `5190843`, compiles clean with the documented MinGW lane, and I verified the resulting addon loads and passes 10/10 on my (non-reproducing) host, so the instrumentation itself does not break the self-test. ### What it reports On the **failure path only**, one JSON line on stderr immediately before the existing error is raised: ``` REA_DIAG_1701 {"classicWin32":5,"ntQueryStatus":"0x00000000","grantedAccess":"0x...","handleCount":N,"pointerCount":N,"deletePending":false,"directory":true,"children":0,"posixDispositionWin32":0,"searchable":true} ``` | field | settles | |---|---| | `grantedAccess` | whether this handle really holds `DELETE` (0x00010000) — the mask you could not extract through the opaque wrapper | | `handleCount` / `pointerCount` | **the one I most want.** `handleCount > 1` means something else holds the object and the share mode is the mechanism; `handleCount == 1` means a sole handle is blocking its own transition, which is not the documented rule and points elsewhere (filter driver / minifilter behaviour) | | `deletePending` | whether a disposition was already staged | | `children` | emptiness at the instant of failure, not before it | | `posixDispositionWin32` | whether `FileDispositionInfoEx` + `FILE_DISPOSITION_FLAG_POSIX_SEMANTICS` succeeds where the classic call fails — `0` here would make that a candidate fix | **Caveat, please read:** the POSIX probe is not read-only. Where it reports `0` the object is unlinked then and there, so this build leaks no probe directory in that case. The thrown error keeps the same constraint text and Win32 code as the stock build, so `rea doctor` output is otherwise unchanged. ### Build it yourself (no MSVC needed) The artifact lane refuses to run outside Linux, but a container satisfies it — this is how I built it on a Windows host with no C++ toolchain at all: ```bash git clone https://github.com/morluto/rea && cd rea && git checkout 5190843 npm ci # save the patch below as 1701-instrumented.patch git apply 1701-instrumented.patch docker run --rm -v "$PWD:/src" -w /src node:22-bookworm bash -lc "apt-get update && apt-get install -y --no-install-recommends g++-mingw-w64-x86-64 && node scripts/build-windows-native.mjs" ``` That writes `native/windows/build/rea-windows-x64.node` (+ `manifest.json`). Point your installed REA at it, or run from the source tree, then: ``` rea doctor --provider ghidra --json 2> diag.txt ``` and paste the `REA_DIAG_1701` line. `node -e "require('./native/windows/build/rea-windows-x64.node').call('runtime_create',[require('os').tmpdir(),'replay-'])"` plus `runtime_close` works too, per @liudong-geek's replay. My build for reference: SHA-256 `391273937535f6d03bb20a44b27d78629de49c86d930d2dea52a03836de4b08d`, 844,998 bytes, `abiVersion: 1`, `nodeApiVersion: 8`. I would rather you build from the patch than trust a binary from a stranger, but if a prebuilt `.node` is genuinely more useful than a container, say so and I will attach one. <details> <summary>1701-instrumented.patch</summary> ```diff diff --git a/native/windows/src/filesystem.cc b/native/windows/src/filesystem.cc index 6cfbc8e..630288d 100644 --- a/native/windows/src/filesystem.cc +++ b/native/windows/src/filesystem.cc @@ -1,6 +1,7 @@ #include "authority.hpp" #include <sddl.h> #include <winternl.h> +#include <cstdio> namespace rea { @@ -296,6 +297,67 @@ static void writeBytes(HANDLE file, const void* bytes, DWORD count, const std::w require(WriteFile(file, bytes, count, &written, nullptr) && written == count, "Write private file failed", path); } +// INSTRUMENTED DIAGNOSTIC BUILD for morluto/rea#1701 — not for merge. +// Reports what the kernel knows about the object at the instant delete-by-handle +// is refused: the granted access mask on this very handle, how many handles and +// references exist for the object, whether a delete is already pending, how many +// children it still has, and whether POSIX-semantics disposition would succeed +// where the classic one did not. Emits one JSON line on stderr and then fails +// with the same constraint and Win32 code as the unmodified build. Note the +// POSIX probe is not read-only: where it reports 0 the object is removed then +// and there, so a diagnostic build leaks no probe directory in that case. +struct ObjectBasicDiagnostic { + ULONG Attributes; + ACCESS_MASK GrantedAccess; + ULONG HandleCount; + ULONG PointerCount; + ULONG Reserved[10]; +}; + +static void diagnoseDisposition(HANDLE handle, const std::wstring& path, DWORD classicError) { + ObjectBasicDiagnostic basic{}; + ULONG basicLength = 0; + LONG queryStatus = -1; + if (const auto ntdll = GetModuleHandleW(L"ntdll.dll")) { + using QueryObject = LONG(NTAPI*)(HANDLE, int, PVOID, ULONG, PULONG); + if (const auto query = reinterpret_cast<QueryObject>( + reinterpret_cast<void*>(GetProcAddress(ntdll, "NtQueryObject")))) + queryStatus = query(handle, 0 /* ObjectBasicInformation */, &basic, sizeof(basic), &basicLength); + } + FILE_STANDARD_INFO standard{}; + const bool standardRead = + GetFileInformationByHandleEx(handle, FileStandardInfo, &standard, sizeof(standard)) != 0; + unsigned children = 0; + WIN32_FIND_DATAW found{}; + const auto search = FindFirstFileW((path + L"\\*").c_str(), &found); + if (search != INVALID_HANDLE_VALUE) { + do { + const std::wstring name(found.cFileName); + if (name != L"." && name != L"..") ++children; + } while (FindNextFileW(search, &found)); + FindClose(search); + } + // FileDispositionInfoEx (21) with DELETE | POSIX_SEMANTICS, Windows 10 1709+. + DWORD posixFlags = 0x00000001 | 0x00000002; + const bool posix = SetFileInformationByHandle( + handle, static_cast<FILE_INFO_BY_HANDLE_CLASS>(21), &posixFlags, + sizeof(posixFlags)) != 0; + const DWORD posixError = posix ? ERROR_SUCCESS : GetLastError(); + std::fprintf(stderr, + "REA_DIAG_1701 {\"classicWin32\":%lu,\"ntQueryStatus\":\"0x%08lX\"," + "\"grantedAccess\":\"0x%08lX\",\"handleCount\":%lu,\"pointerCount\":%lu," + "\"deletePending\":%s,\"directory\":%s,\"children\":%u," + "\"posixDispositionWin32\":%lu,\"searchable\":%s}\n", + classicError, static_cast<unsigned long>(queryStatus), + static_cast<unsigned long>(basic.GrantedAccess), + static_cast<unsigned long>(basic.HandleCount), + static_cast<unsigned long>(basic.PointerCount), + standardRead && standard.DeletePending ? "true" : "false", + standardRead && standard.Directory ? "true" : "false", children, posixError, + search != INVALID_HANDLE_VALUE ? "true" : "false"); + std::fflush(stderr); +} + static void dispose(HANDLE handle, const std::wstring& path) { FILE_BASIC_INFO info{}; require(GetFileInformationByHandleEx(handle, FileBasicInfo, &info, sizeof(info)), "Read cleanup attributes failed", path); @@ -304,7 +366,11 @@ static void dispose(HANDLE handle, const std::wstring& path) { require(SetFileInformationByHandle(handle, FileBasicInfo, &info, sizeof(info)), "Clear owned readonly attribute failed", path); } FILE_DISPOSITION_INFO deletion{TRUE}; - require(SetFileInformationByHandle(handle, FileDispositionInfo, &deletion, sizeof(deletion)), "Delete owned object by handle failed", path); + if (!SetFileInformationByHandle(handle, FileDispositionInfo, &deletion, sizeof(deletion))) { + const DWORD classicError = GetLastError(); + diagnoseDisposition(handle, path, classicError); + require(false, "Delete owned object by handle failed", path, classicError); + } } static void disposeSnapshot(Runtime& root, Handle& file, const std::wstring& path) { ``` </details> _🤖 Posted by [Claude Code](https://claude.com/claude-code)_
Author
Owner

@WraithFallen commented on GitHub (Oct 13, 2026):

Another passing host, this time Windows 10 using the published npm artifact rather than a source build. Posting it as a contrast point for the matrix.

REA rea-agents@6.4.0 from npm (global install, prebuilt rea-windows-x64.node)
Host Windows 10 Pro 22H2, build 19045, x64, medium integrity (not elevated)
Node v24.14.1
Ghidra / JDK 12.1.2 PUBLIC / Temurin 25.0.3
Temp %TEMP% on the local NTFS system drive
AV Defender real-time protection off

rea doctor --json: ghidra-native_authority ok: true, "Verified Windows native Job Object, private DACL, and reparse-safe handle controls; local NTFS only." All nine Ghidra checks are healthy. A real target, an x64 SKSE plugin DLL, then ran rea inspect and rea search to completion. No rea-native-probe-* directories were left in %TEMP%.

Defender being off may matter for the "second unobserved handle" theory above, since a real-time scanner opening the new directory would be one candidate for it. I haven't toggled it to test that.

<!-- gh-comment-id:6138843603 --> @WraithFallen commented on GitHub (Oct 13, 2026): Another **passing** host, this time Windows 10 using the published npm artifact rather than a source build. Posting it as a contrast point for the matrix. | | | |---|---| | REA | `rea-agents@6.4.0` from npm (global install, prebuilt `rea-windows-x64.node`) | | Host | Windows 10 Pro 22H2, build **19045**, x64, medium integrity (not elevated) | | Node | v24.14.1 | | Ghidra / JDK | 12.1.2 PUBLIC / Temurin 25.0.3 | | Temp | `%TEMP%` on the local NTFS system drive | | AV | Defender real-time protection **off** | `rea doctor --json`: `ghidra-native_authority` `ok: true`, "Verified Windows native Job Object, private DACL, and reparse-safe handle controls; local NTFS only." All nine Ghidra checks are healthy. A real target, an x64 SKSE plugin DLL, then ran `rea inspect` and `rea search` to completion. No `rea-native-probe-*` directories were left in `%TEMP%`. Defender being off may matter for the "second unobserved handle" theory above, since a real-time scanner opening the new directory would be one candidate for it. I haven't toggled it to test that.
Author
Owner

@chemsily commented on GitHub (Oct 13, 2026):

<html>

Another failing host — and on a newer build than the reports so far (26300 vs 26100), so this is not a single-servicing-build artifact.

Environment

  |   -- | -- REA | rea-agents 6.4.0 (npm). Bundled addon rea-windows-x64.node, 848,252 B, SHA-256 c4fd9f377e567bcf15ba3fec3e0b0ed965d82b765a2adcdac49e46f14524b6d5; manifest.json reports abiVersion: 1, nodeApiVersion: 8 Host | Windows 11 Pro 26300 (10.0.26300), x64, medium integrity (S-1-16-8192), not elevated — the account is a member of BUILTIN\Administrators, it just is not elevated here Node | v22.22.2 Ghidra | 12.1.4 PUBLIC JDK | Microsoft OpenJDK 21.0.12.1+1 LTS (64-bit full JDK, javac present)

Reproduction

rea doctor --provider ghidra fails 5/5 runs (100%, not intermittent), and each run leaves a rea-native-probe-* directory behind — 6 accumulated across the session.

Ghidra itself is detected perfectly: 8 of 9 provider checks are healthy (release, platform, architecture, application.properties, version 12.1.4, analyzeHeadless.bat, native decompiler matching pe x86_64, JDK 21). Only native_authority fails, and it hard-gates every provider-backed operation.

Two controlled experiments: this is addon-internal, not a host constraint

Both run in the same medium-IL non-elevated process.

1. The probe object's own security descriptor is correct. Dumping the SD of a probe directory REA had just left behind:

So the private-DACL installation itself works, and the DACL is not what denies the delete — the acting process is both owner and a FILE_ALL_ACCESS grantee.

2. Deleting that same probe object by handle succeeds when done directly. Against the exact directory REA failed to remove:

The OS permits precisely the transition the addon needs. Note this also requires FILE_FLAG_BACKUP_SEMANTICS — opening a directory for delete/write without it returns Win32 5 on its own, which is easy to misread as the bug; it is not the bug here.

Temp location is not a factor. Pointing TMP/TEMP/TMPDIR at D:\analysis\tmp reproduces identically — only the reported path moves (D:\analysis\tmp\rea-native-probe-…). Both TEMP roots are ordinary directories (FILE_ATTRIBUTE_DIRECTORY, no reparse tag) on fixed local NTFS volumes.

On the mechanism

The #2445 diagnosis matches what is observable from outside. The addon documents that it retains handles for the runtime's lifetime ("Descriptor and snapshot handles remain held until runtime cleanup"), and a retained handle that never granted FILE_SHARE_DELETE would block the delete-pending transition on the very object it still holds. That is consistent with both experiments above: the delete succeeds the moment no non-DELETE-sharing handle is outstanding on the object.

I could not instrument the addon myself (no MinGW lane on this machine), so I cannot speak directly to the "second unobserved handle" hypothesis — though a second retained handle is exactly what the retained-lease design predicts, so the two framings may be the same defect seen from different sides.

For anyone arriving here looking for a workaround

There isn't one, and two dead ends are worth recording:

  • REA_WORKSPACE_ROOT does not help — the self-test probe path is not derived from it.
  • Substituting a locally built addon is not supported: native/windows/README.md states the loader verifies the artifact SHA-256 and that "there is no environment override for loading an arbitrary native module."

So on Windows today, native binary analysis is reachable only by driving Ghidra headless directly and bypassing REA's provider layer. The engine itself is fine — verified end-to-end on this host: analyzeHeadless.bat imported a PE, auto-analysis found 198 functions, and DecompInterface produced C pseudocode for 5/5 sampled functions.

</html>
<!-- gh-comment-id:6139085646 --> @chemsily commented on GitHub (Oct 13, 2026): <html> <body> <!--StartFragment--><p>Another failing host — and on a <strong>newer build</strong> than the reports so far (26300 vs 26100), so this is not a single-servicing-build artifact.</p><h3>Environment</h3>   |   -- | -- REA | rea-agents 6.4.0 (npm). Bundled addon rea-windows-x64.node, 848,252 B, SHA-256 c4fd9f377e567bcf15ba3fec3e0b0ed965d82b765a2adcdac49e46f14524b6d5; manifest.json reports abiVersion: 1, nodeApiVersion: 8 Host | Windows 11 Pro 26300 (10.0.26300), x64, medium integrity (S-1-16-8192), not elevated — the account is a member of BUILTIN\Administrators, it just is not elevated here Node | v22.22.2 Ghidra | 12.1.4 PUBLIC JDK | Microsoft OpenJDK 21.0.12.1+1 LTS (64-bit full JDK, javac present) <h3>Reproduction</h3><p><code>rea doctor --provider ghidra</code> fails <strong>5/5 runs</strong> (100%, not intermittent), and each run leaves a <code>rea-native-probe-*</code> directory behind — 6 accumulated across the session.</p><p>Ghidra itself is detected perfectly: 8 of 9 provider checks are <code>healthy</code> (release, platform, architecture, <code>application.properties</code>, version 12.1.4, <code>analyzeHeadless.bat</code>, native decompiler matching <code>pe x86_64</code>, JDK 21). Only <code>native_authority</code> fails, and it hard-gates every provider-backed operation.</p><h3>Two controlled experiments: this is addon-internal, not a host constraint</h3><p>Both run in the same medium-IL non-elevated process.</p><p><strong>1. The probe object's own security descriptor is correct.</strong> Dumping the SD of a probe directory REA had just left behind:</p><pre><code></code></pre><p>So the private-DACL installation itself works, and the DACL is not what denies the delete — the acting process is both owner and a <code>FILE_ALL_ACCESS</code> grantee.</p><p><strong>2. Deleting that same probe object by handle succeeds when done directly.</strong> Against the exact directory REA failed to remove:</p><pre><code></code></pre><p>The OS permits precisely the transition the addon needs. Note this also requires <code>FILE_FLAG_BACKUP_SEMANTICS</code> — opening a <em>directory</em> for delete/write without it returns Win32 5 on its own, which is easy to misread as the bug; it is not the bug here.</p><p><strong>Temp location is not a factor.</strong> Pointing <code>TMP</code>/<code>TEMP</code>/<code>TMPDIR</code> at <code>D:\analysis\tmp</code> reproduces identically — only the reported path moves (<code>D:\analysis\tmp\rea-native-probe-…</code>). Both TEMP roots are ordinary directories (<code>FILE_ATTRIBUTE_DIRECTORY</code>, no reparse tag) on fixed local NTFS volumes.</p><h3>On the mechanism</h3><p>The #2445 diagnosis matches what is observable from outside. The addon documents that it <em>retains</em> handles for the runtime's lifetime ("Descriptor and snapshot handles remain held until runtime cleanup"), and a retained handle that never granted <code>FILE_SHARE_DELETE</code> would block the delete-pending transition on the very object it still holds. That is consistent with both experiments above: the delete succeeds the moment no non-DELETE-sharing handle is outstanding on the object.</p><p>I could not instrument the addon myself (no MinGW lane on this machine), so I cannot speak directly to the "second unobserved handle" hypothesis — though a second retained handle is exactly what the retained-lease design predicts, so the two framings may be the same defect seen from different sides.</p><h3>For anyone arriving here looking for a workaround</h3><p>There isn't one, and two dead ends are worth recording:</p><ul><li><code>REA_WORKSPACE_ROOT</code> does not help — the self-test probe path is not derived from it.</li></ul><ul><li>Substituting a locally built addon is not supported: <code>native/windows/README.md</code> states the loader verifies the artifact SHA-256 and that "there is no environment override for loading an arbitrary native module."</li></ul><p>So on Windows today, native binary analysis is reachable only by driving Ghidra headless directly and bypassing REA's provider layer. The engine itself is fine — verified end-to-end on this host: <code>analyzeHeadless.bat</code> imported a PE, auto-analysis found 198 functions, and <code>DecompInterface</code> produced C pseudocode for 5/5 sampled functions.</p><sc-clipboard block-data="[{&quot;blockId&quot;:&quot;3em1U7heAY5zU6G7PUZYYY&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;3em1U7heAY5zU6G7PUZYYY&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;3em1U7heAY5zU6G7PUZYYY&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Another failing host — and on a &quot;,null],[&quot;newer build&quot;,[[&quot;b&quot;]]],[&quot; than the reports so far (26300 vs 26100), so this is not a single-servicing-build artifact.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;jwctwt2N1t2NHAX9BCi2TF&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;jwctwt2N1t2NHAX9BCi2TF&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;jwctwt2N1t2NHAX9BCi2TF&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;header3&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Environment&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;eFitpx0AMJlgjSaevMEgQc&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;eFitpx0AMJlgjSaevMEgQc&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;eFitpx0AMJlgjSaevMEgQc&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;simple_table&quot;,&quot;props&quot;:{&quot;tableColumnOrder&quot;:[&quot;1rriuHLi&quot;,&quot;LJNpwbOx&quot;],&quot;tableColumnWidthMap&quot;:{&quot;1rriuHLi&quot;:120,&quot;LJNpwbOx&quot;:120},&quot;tableRowHeader&quot;:true},&quot;children&quot;:[&quot;08H1FG0mxCgGTGNnSGXkPz&quot;,&quot;K29jkaPKIY517wVzxQxFR8&quot;,&quot;6MyOTlDeDGtsb1Fcmlz08G&quot;,&quot;Tt7a38jeXHNFTwHexwDupw&quot;,&quot;IXFNGdpmNlHuiT1nCbKiVb&quot;,&quot;diiW9FS0cajcM2UHYulZWc&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;08H1FG0mxCgGTGNnSGXkPz&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;08H1FG0mxCgGTGNnSGXkPz&quot;,&quot;parentId&quot;:&quot;eFitpx0AMJlgjSaevMEgQc&quot;,&quot;type&quot;:&quot;simple_table_row&quot;,&quot;props&quot;:{},&quot;children&quot;:[&quot;PAIarrcMheOSp6lXpF9ixr&quot;,&quot;Ud5DIoy4RCFCQtYUzt0ZUj&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;PAIarrcMheOSp6lXpF9ixr&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;PAIarrcMheOSp6lXpF9ixr&quot;,&quot;parentId&quot;:&quot;08H1FG0mxCgGTGNnSGXkPz&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;1rriuHLi&quot;},&quot;children&quot;:[&quot;BakIpxmOsVDtA9ADvW3CVG&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;BakIpxmOsVDtA9ADvW3CVG&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;BakIpxmOsVDtA9ADvW3CVG&quot;,&quot;parentId&quot;:&quot;PAIarrcMheOSp6lXpF9ixr&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;Ud5DIoy4RCFCQtYUzt0ZUj&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;Ud5DIoy4RCFCQtYUzt0ZUj&quot;,&quot;parentId&quot;:&quot;08H1FG0mxCgGTGNnSGXkPz&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;LJNpwbOx&quot;},&quot;children&quot;:[&quot;IsNmdESUw6EdAtH0nZnYbE&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;IsNmdESUw6EdAtH0nZnYbE&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;IsNmdESUw6EdAtH0nZnYbE&quot;,&quot;parentId&quot;:&quot;Ud5DIoy4RCFCQtYUzt0ZUj&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;K29jkaPKIY517wVzxQxFR8&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;K29jkaPKIY517wVzxQxFR8&quot;,&quot;parentId&quot;:&quot;eFitpx0AMJlgjSaevMEgQc&quot;,&quot;type&quot;:&quot;simple_table_row&quot;,&quot;props&quot;:{},&quot;children&quot;:[&quot;VoEnjMnOv3as1etD0rsHxl&quot;,&quot;goIN4Ip2p1nEaXvAbnnJfs&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;VoEnjMnOv3as1etD0rsHxl&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;VoEnjMnOv3as1etD0rsHxl&quot;,&quot;parentId&quot;:&quot;K29jkaPKIY517wVzxQxFR8&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;1rriuHLi&quot;},&quot;children&quot;:[&quot;CjWjtDOehKVPPHCyuoR9sf&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;CjWjtDOehKVPPHCyuoR9sf&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;CjWjtDOehKVPPHCyuoR9sf&quot;,&quot;parentId&quot;:&quot;VoEnjMnOv3as1etD0rsHxl&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;REA&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;goIN4Ip2p1nEaXvAbnnJfs&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;goIN4Ip2p1nEaXvAbnnJfs&quot;,&quot;parentId&quot;:&quot;K29jkaPKIY517wVzxQxFR8&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;LJNpwbOx&quot;},&quot;children&quot;:[&quot;UdIu9BNHHQgnzSOmg2XFsG&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;UdIu9BNHHQgnzSOmg2XFsG&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;UdIu9BNHHQgnzSOmg2XFsG&quot;,&quot;parentId&quot;:&quot;goIN4Ip2p1nEaXvAbnnJfs&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;rea-agents&quot;,[[&quot;c&quot;]]],[&quot; 6.4.0 (npm). Bundled addon &quot;,null],[&quot;rea-windows-x64.node&quot;,[[&quot;c&quot;]]],[&quot;, 848,252 B, SHA-256 &quot;,null],[&quot;c4fd9f377e567bcf15ba3fec3e0b0ed965d82b765a2adcdac49e46f14524b6d5&quot;,[[&quot;c&quot;]]],[&quot;; &quot;,null],[&quot;manifest.json&quot;,[[&quot;c&quot;]]],[&quot; reports &quot;,null],[&quot;abiVersion: 1&quot;,[[&quot;c&quot;]]],[&quot;, &quot;,null],[&quot;nodeApiVersion: 8&quot;,[[&quot;c&quot;]]]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;6MyOTlDeDGtsb1Fcmlz08G&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;6MyOTlDeDGtsb1Fcmlz08G&quot;,&quot;parentId&quot;:&quot;eFitpx0AMJlgjSaevMEgQc&quot;,&quot;type&quot;:&quot;simple_table_row&quot;,&quot;props&quot;:{},&quot;children&quot;:[&quot;FWODno8LVi6rpuIKYMpItg&quot;,&quot;Yvc3gHYQ4FF1uOay4tF5tB&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;FWODno8LVi6rpuIKYMpItg&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;FWODno8LVi6rpuIKYMpItg&quot;,&quot;parentId&quot;:&quot;6MyOTlDeDGtsb1Fcmlz08G&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;1rriuHLi&quot;},&quot;children&quot;:[&quot;F43od3Qb8H9idzX1vkMt43&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;F43od3Qb8H9idzX1vkMt43&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;F43od3Qb8H9idzX1vkMt43&quot;,&quot;parentId&quot;:&quot;FWODno8LVi6rpuIKYMpItg&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Host&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;Yvc3gHYQ4FF1uOay4tF5tB&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;Yvc3gHYQ4FF1uOay4tF5tB&quot;,&quot;parentId&quot;:&quot;6MyOTlDeDGtsb1Fcmlz08G&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;LJNpwbOx&quot;},&quot;children&quot;:[&quot;DZBPZe7TIG3dZxAScfyle0&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;DZBPZe7TIG3dZxAScfyle0&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;DZBPZe7TIG3dZxAScfyle0&quot;,&quot;parentId&quot;:&quot;Yvc3gHYQ4FF1uOay4tF5tB&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Windows 11 Pro &quot;,null],[&quot;26300&quot;,[[&quot;b&quot;]]],[&quot; (10.0.26300), x64, medium integrity (&quot;,null],[&quot;S-1-16-8192&quot;,[[&quot;c&quot;]]],[&quot;), &quot;,null],[&quot;not elevated&quot;,[[&quot;b&quot;]]],[&quot; — the account &quot;,null],[&quot;is&quot;,[[&quot;i&quot;]]],[&quot; a member of &quot;,null],[&quot;BUILTIN\\Administrators&quot;,[[&quot;c&quot;]]],[&quot;, it just is not elevated here&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;Tt7a38jeXHNFTwHexwDupw&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;Tt7a38jeXHNFTwHexwDupw&quot;,&quot;parentId&quot;:&quot;eFitpx0AMJlgjSaevMEgQc&quot;,&quot;type&quot;:&quot;simple_table_row&quot;,&quot;props&quot;:{},&quot;children&quot;:[&quot;A2xX1Nwz1gZAjG6p3EpN8V&quot;,&quot;DehJMdr6k1GIgZBU1I254Q&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;A2xX1Nwz1gZAjG6p3EpN8V&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;A2xX1Nwz1gZAjG6p3EpN8V&quot;,&quot;parentId&quot;:&quot;Tt7a38jeXHNFTwHexwDupw&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;1rriuHLi&quot;},&quot;children&quot;:[&quot;gkCLh8xeYYp86zmYPaIPwB&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;gkCLh8xeYYp86zmYPaIPwB&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;gkCLh8xeYYp86zmYPaIPwB&quot;,&quot;parentId&quot;:&quot;A2xX1Nwz1gZAjG6p3EpN8V&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Node&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;DehJMdr6k1GIgZBU1I254Q&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;DehJMdr6k1GIgZBU1I254Q&quot;,&quot;parentId&quot;:&quot;Tt7a38jeXHNFTwHexwDupw&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;LJNpwbOx&quot;},&quot;children&quot;:[&quot;7G2ILWm5EcrpBRR6G7aV3g&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;7G2ILWm5EcrpBRR6G7aV3g&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;7G2ILWm5EcrpBRR6G7aV3g&quot;,&quot;parentId&quot;:&quot;DehJMdr6k1GIgZBU1I254Q&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;v22.22.2&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;IXFNGdpmNlHuiT1nCbKiVb&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;IXFNGdpmNlHuiT1nCbKiVb&quot;,&quot;parentId&quot;:&quot;eFitpx0AMJlgjSaevMEgQc&quot;,&quot;type&quot;:&quot;simple_table_row&quot;,&quot;props&quot;:{},&quot;children&quot;:[&quot;RGZ93ESAPJdWLekr694WAr&quot;,&quot;jIsaCXfY8Vdc9Jsk2tHaJR&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;RGZ93ESAPJdWLekr694WAr&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;RGZ93ESAPJdWLekr694WAr&quot;,&quot;parentId&quot;:&quot;IXFNGdpmNlHuiT1nCbKiVb&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;1rriuHLi&quot;},&quot;children&quot;:[&quot;7EdXies5veSx6iuSKHEQ60&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;7EdXies5veSx6iuSKHEQ60&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;7EdXies5veSx6iuSKHEQ60&quot;,&quot;parentId&quot;:&quot;RGZ93ESAPJdWLekr694WAr&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Ghidra&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;jIsaCXfY8Vdc9Jsk2tHaJR&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;jIsaCXfY8Vdc9Jsk2tHaJR&quot;,&quot;parentId&quot;:&quot;IXFNGdpmNlHuiT1nCbKiVb&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;LJNpwbOx&quot;},&quot;children&quot;:[&quot;sAfH0sPFp1gQEz5qPhGR50&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;sAfH0sPFp1gQEz5qPhGR50&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;sAfH0sPFp1gQEz5qPhGR50&quot;,&quot;parentId&quot;:&quot;jIsaCXfY8Vdc9Jsk2tHaJR&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;12.1.4 PUBLIC&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;diiW9FS0cajcM2UHYulZWc&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;diiW9FS0cajcM2UHYulZWc&quot;,&quot;parentId&quot;:&quot;eFitpx0AMJlgjSaevMEgQc&quot;,&quot;type&quot;:&quot;simple_table_row&quot;,&quot;props&quot;:{},&quot;children&quot;:[&quot;2RWpjV53jtFBUWs2xUYEIG&quot;,&quot;8LhkaFVXxcoWzouXSLdXfq&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;2RWpjV53jtFBUWs2xUYEIG&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;2RWpjV53jtFBUWs2xUYEIG&quot;,&quot;parentId&quot;:&quot;diiW9FS0cajcM2UHYulZWc&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;1rriuHLi&quot;},&quot;children&quot;:[&quot;sqx5aTUzfPHnG61rG4903b&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;sqx5aTUzfPHnG61rG4903b&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;sqx5aTUzfPHnG61rG4903b&quot;,&quot;parentId&quot;:&quot;2RWpjV53jtFBUWs2xUYEIG&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;JDK&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;8LhkaFVXxcoWzouXSLdXfq&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;8LhkaFVXxcoWzouXSLdXfq&quot;,&quot;parentId&quot;:&quot;diiW9FS0cajcM2UHYulZWc&quot;,&quot;type&quot;:&quot;simple_table_cell&quot;,&quot;props&quot;:{&quot;columnKey&quot;:&quot;LJNpwbOx&quot;},&quot;children&quot;:[&quot;WgMDnwOzaDzN401BOU1NkF&quot;],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}},&quot;WgMDnwOzaDzN401BOU1NkF&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;WgMDnwOzaDzN401BOU1NkF&quot;,&quot;parentId&quot;:&quot;8LhkaFVXxcoWzouXSLdXfq&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Microsoft OpenJDK 21.0.12.1+1 LTS (64-bit full JDK, &quot;,null],[&quot;javac&quot;,[[&quot;c&quot;]]],[&quot; present)&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;73qa5XhtTovH9bpZZUV18a&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;73qa5XhtTovH9bpZZUV18a&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;73qa5XhtTovH9bpZZUV18a&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;header3&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Reproduction&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;PZqkNXu6JofzhrgWFfNxSW&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;PZqkNXu6JofzhrgWFfNxSW&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;PZqkNXu6JofzhrgWFfNxSW&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;rea doctor --provider ghidra&quot;,[[&quot;c&quot;]]],[&quot; fails &quot;,null],[&quot;5/5 runs&quot;,[[&quot;b&quot;]]],[&quot; (100%, not intermittent), and each run leaves a &quot;,null],[&quot;rea-native-probe-*&quot;,[[&quot;c&quot;]]],[&quot; directory behind — 6 accumulated across the session.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;ecUJ1VsphSNhPKiOLaNt3o&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;ecUJ1VsphSNhPKiOLaNt3o&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;ecUJ1VsphSNhPKiOLaNt3o&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Ghidra itself is detected perfectly: 8 of 9 provider checks are &quot;,null],[&quot;healthy&quot;,[[&quot;c&quot;]]],[&quot; (release, platform, architecture, &quot;,null],[&quot;application.properties&quot;,[[&quot;c&quot;]]],[&quot;, version 12.1.4, &quot;,null],[&quot;analyzeHeadless.bat&quot;,[[&quot;c&quot;]]],[&quot;, native decompiler matching &quot;,null],[&quot;pe x86_64&quot;,[[&quot;c&quot;]]],[&quot;, JDK 21). Only &quot;,null],[&quot;native_authority&quot;,[[&quot;c&quot;]]],[&quot; fails, and it hard-gates every provider-backed operation.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;WNTA2rHEIqKLC6xWhMGZ1f&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;WNTA2rHEIqKLC6xWhMGZ1f&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;WNTA2rHEIqKLC6xWhMGZ1f&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;header3&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Two controlled experiments: this is addon-internal, not a host constraint&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;zazkHrTmsARR11vpGQ5WFA&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;zazkHrTmsARR11vpGQ5WFA&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;zazkHrTmsARR11vpGQ5WFA&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Both run in the same medium-IL non-elevated process.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;mY4IDUFWN6o4ThkmxOHyem&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;mY4IDUFWN6o4ThkmxOHyem&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;mY4IDUFWN6o4ThkmxOHyem&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;1. The probe object's own security descriptor is correct.&quot;,[[&quot;b&quot;]]],[&quot; Dumping the SD of a probe directory REA had just left behind:&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;oxLMwYaA282zbEebzHVIsb&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;oxLMwYaA282zbEebzHVIsb&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;oxLMwYaA282zbEebzHVIsb&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;code&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Owner: <the process's own user SID>\nGroup: <that user's primary group>\nDACL present: True | ACE count: 2\n ACE0 type=ALLOW mask=0x1F01FF -> <same user SID>\n ACE1 type=ALLOW mask=0x1F01FF -> NT AUTHORITY\\SYSTEM (S-1-5-18)&quot;]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;KAEqIR0g6n8HTLn2NWjZoD&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;KAEqIR0g6n8HTLn2NWjZoD&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;KAEqIR0g6n8HTLn2NWjZoD&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;So the private-DACL installation itself works, and the DACL is not what denies the delete — the acting process is both owner and a &quot;,null],[&quot;FILE_ALL_ACCESS&quot;,[[&quot;c&quot;]]],[&quot; grantee.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;ZbMQmv2GCBi4DPpWwMHwvo&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;ZbMQmv2GCBi4DPpWwMHwvo&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;ZbMQmv2GCBi4DPpWwMHwvo&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;2. Deleting that same probe object by handle succeeds when done directly.&quot;,[[&quot;b&quot;]]],[&quot; Against the exact directory REA failed to remove:&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;PUGbDFphZsT4BtsGTALcQO&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;PUGbDFphZsT4BtsGTALcQO&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;PUGbDFphZsT4BtsGTALcQO&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;code&quot;,&quot;props&quot;:{&quot;codeLanguage&quot;:&quot;c&quot;,&quot;title&quot;:[[&quot;CreateFileW(path,\n DELETE | FILE_WRITE_EA | FILE_ADD_SUBDIRECTORY | FILE_TRAVERSE,\n FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,\n NULL, OPEN_EXISTING,\n FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_DELETE_ON_CLOSE, NULL);\nCloseHandle(h); // directory is gone&quot;]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;rnrNE24SETUbNCPN6ul1GE&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;rnrNE24SETUbNCPN6ul1GE&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;rnrNE24SETUbNCPN6ul1GE&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;The OS permits precisely the transition the addon needs. Note this also requires &quot;,null],[&quot;FILE_FLAG_BACKUP_SEMANTICS&quot;,[[&quot;c&quot;]]],[&quot; — opening a &quot;,null],[&quot;directory&quot;,[[&quot;i&quot;]]],[&quot; for delete/write without it returns Win32 5 on its own, which is easy to misread as the bug; it is not the bug here.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;CrgYncvxjHsrboMrRVKkwQ&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;CrgYncvxjHsrboMrRVKkwQ&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;CrgYncvxjHsrboMrRVKkwQ&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Temp location is not a factor.&quot;,[[&quot;b&quot;]]],[&quot; Pointing &quot;,null],[&quot;TMP&quot;,[[&quot;c&quot;]]],[&quot;/&quot;,null],[&quot;TEMP&quot;,[[&quot;c&quot;]]],[&quot;/&quot;,null],[&quot;TMPDIR&quot;,[[&quot;c&quot;]]],[&quot; at &quot;,null],[&quot;D:\\analysis\\tmp&quot;,[[&quot;c&quot;]]],[&quot; reproduces identically — only the reported path moves (&quot;,null],[&quot;D:\\analysis\\tmp\\rea-native-probe-…&quot;,[[&quot;c&quot;]]],[&quot;). Both TEMP roots are ordinary directories (&quot;,null],[&quot;FILE_ATTRIBUTE_DIRECTORY&quot;,[[&quot;c&quot;]]],[&quot;, no reparse tag) on fixed local NTFS volumes.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;xZvmH0T1REmtuAQwvvMxgW&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;xZvmH0T1REmtuAQwvvMxgW&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;xZvmH0T1REmtuAQwvvMxgW&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;header3&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;On the mechanism&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;XZ819UefKflj5viADEP3bH&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;XZ819UefKflj5viADEP3bH&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;XZ819UefKflj5viADEP3bH&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;The #2445 diagnosis matches what is observable from outside. The addon documents that it &quot;,null],[&quot;retains&quot;,[[&quot;i&quot;]]],[&quot; handles for the runtime's lifetime (\&quot;Descriptor and snapshot handles remain held until runtime cleanup\&quot;), and a retained handle that never granted &quot;,null],[&quot;FILE_SHARE_DELETE&quot;,[[&quot;c&quot;]]],[&quot; would block the delete-pending transition on the very object it still holds. That is consistent with both experiments above: the delete succeeds the moment no non-DELETE-sharing handle is outstanding on the object.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;ON1zaSevCFxicw9mjGsghi&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;ON1zaSevCFxicw9mjGsghi&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;ON1zaSevCFxicw9mjGsghi&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;I could not instrument the addon myself (no MinGW lane on this machine), so I cannot speak directly to the \&quot;second unobserved handle\&quot; hypothesis — though a second retained handle is exactly what the retained-lease design predicts, so the two framings may be the same defect seen from different sides.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;irywOHy2Ea9RqGB01OtnI3&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;irywOHy2Ea9RqGB01OtnI3&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;irywOHy2Ea9RqGB01OtnI3&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;header3&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;For anyone arriving here looking for a workaround&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;RLlw3e6F1APdw7ENbIhTZU&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;RLlw3e6F1APdw7ENbIhTZU&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;RLlw3e6F1APdw7ENbIhTZU&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;There isn't one, and two dead ends are worth recording:&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;2LfgqBqYfiG8uVcFjSpypj&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;2LfgqBqYfiG8uVcFjSpypj&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;2LfgqBqYfiG8uVcFjSpypj&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;bulleted_list&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;REA_WORKSPACE_ROOT&quot;,[[&quot;c&quot;]]],[&quot; does not help — the self-test probe path is not derived from it.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;BYVBFctVV2UoAeVyhocfwd&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;BYVBFctVV2UoAeVyhocfwd&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;BYVBFctVV2UoAeVyhocfwd&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;bulleted_list&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;Substituting a locally built addon is not supported: &quot;,null],[&quot;native/windows/README.md&quot;,[[&quot;c&quot;]]],[&quot; states the loader verifies the artifact SHA-256 and that \&quot;there is no environment override for loading an arbitrary native module.\&quot;&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}},{&quot;blockId&quot;:&quot;ItA8pjUzSVEdlAAUDozYmb&quot;,&quot;blockSubtree&quot;:{&quot;block&quot;:{&quot;ItA8pjUzSVEdlAAUDozYmb&quot;:{&quot;role&quot;:&quot;editor&quot;,&quot;value&quot;:{&quot;id&quot;:&quot;ItA8pjUzSVEdlAAUDozYmb&quot;,&quot;parentId&quot;:&quot;&quot;,&quot;type&quot;:&quot;text&quot;,&quot;props&quot;:{&quot;title&quot;:[[&quot;So on Windows today, native binary analysis is reachable only by driving Ghidra headless directly and bypassing REA's provider layer. The engine itself is fine — verified end-to-end on this host: &quot;,null],[&quot;analyzeHeadless.bat&quot;,[[&quot;c&quot;]]],[&quot; imported a PE, auto-analysis found 198 functions, and &quot;,null],[&quot;DecompInterface&quot;,[[&quot;c&quot;]]],[&quot; produced C pseudocode for 5/5 sampled functions.&quot;,null]]},&quot;children&quot;:[],&quot;parentTable&quot;:&quot;block&quot;,&quot;enabled&quot;:true}}}}}]"></sc-clipboard><!--EndFragment--> </body> </html>
Author
Owner

@ranceil commented on GitHub (Oct 14, 2026):

Independent reproduction on a second host — the self-test gate is a false negative:
the MCP tool surface works while the CLI is still rejected

Reporting a dimension I don't see covered above, because it changes the practical impact.

Environment

REA:    rea-agents 6.4.0   (same self-test failure on 6.3.0 and 5.0.0)
Host:   Windows 11 Pro, 10.0.26200, x64   (C:/D:/E: all NTFS, fixed, healthy)
Node:   v22.22.2
Ghidra: 12.1.4 PUBLIC
JDK:    Eclipse Temurin 21.0.12.1+1 (64-bit, full JDK)
Token:  elevated (TokenElevation = true)

The self-test still fails, deterministically, on this host

rea doctor --provider ghidra --json reports native_authority as ok:false /
unsupported_host, with the same Delete owned object by handle failed … (Win32 5)
and the same leaked rea-native-probe-<32hex> directory.

I ran it 12 times back to back: 12 failures, 0 passes. So on this host it is not
currently exhibiting the transient behaviour described in a comment above.

But the native analysis itself works — through the MCP tool surface

Call Result
rea doctor --provider ghidra --json ❌ native_authority fails (12/12)
CLI rea analyze <pe> (provider auto-selection) ❌ provider_unavailable
CLI rea analyze <pe> --provider ghidra (explicit, too) ❌ provider_unavailable
MCP open_binary with provider_id: "ghidra" ✅ binds Ghidra successfully
MCP binary_overview ✅ Ghidra 12.1.4 full analysis: 526 procedures, 241 strings, 6 segments

Target: a 2004 32-bit PE application (x86). Verified twice on this host. Downstream
tools (search_strings, xrefs, procedure_pseudo_code) also work in the same MCP
session.

Interpretation (hypothesis, not a finding)

This is consistent with systemWindowsNativeAuthority() caching its probe result
process-wide (cached ??= …, one probe per process). The long-running MCP host process
evidently probed during a passing window and cached available: true; each new CLI
process re-probes and fails. That also fits the transient behaviour reported earlier:
the probe is unreliable, but the capability it probes for is present.

Two consequences worth acting on

  1. The Impact section above is too pessimistic, and the current behaviour costs users
    real work.
    A host in this state looks completely blocked — rea doctor says
    unavailable and the CLI refuses to run — while the MCP surface can perform the full
    analysis. The reasonable conclusion for a user is "native analysis on Windows doesn't
    work", and they stop. I nearly did.

  2. Suggestion: don't hard-gate a capability on a probe. A failed self-test should
    degrade to a warning (and be recorded), not disable the provider for every surface.
    If the probe cannot be made reliable, then at minimum the CLI and the MCP surface
    should not disagree about whether the same capability exists.

Concretely, alongside the retry-with-backoff suggestion already made:

  • Treat a native_authority probe failure as degraded rather than unavailable, and
    let each operation decide whether it actually needs native authority.
  • Have the CLI and the MCP surface share one admission decision, so a passing state in
    one is not invisible in the other.
  • Fix the remediation text: it currently points users at "use the matching Windows x64
    REA package and a writable local NTFS temporary directory", neither of which is the
    constraint here. Something like "the native self-test failed; MCP tool calls may still
    work" would have saved days of investigation.

Additional data points from this host (all measured)

  • Wider reproduction range than reported: rea-agents 5.0.0, 6.3.0 and 6.4.0 all
    report providerInspections.ghidra.available: false. In 5.0.0 the check is not
    surfaced under the native_authority name, but the outcome is identical — not a
    6.3.x regression.
  • Not antivirus, in either direction: this host had a third-party endpoint product
    with kernel drivers loaded; after fully removing it and confirming services and
    drivers were gone, the self-test failed identically. The original report's host has no
    third-party AV registered at all.
  • Survives a full reboot with no lingering drivers or hooks.
  • A second leak surface: besides rea-native-probe-*, I also find leftover
    rea-ghidra-* directories in %TEMP% from failed Ghidra sessions (3 accumulated
    during this investigation, alongside 3 probe directories).
  • The leaked probe directory's security descriptor is exactly as intended (icacls:
    current user + SYSTEM full control, protected/non-inherited, no deny ACEs) and carries
    no Mandatory Label (default Medium) — so neither the DACL nor the integrity label
    explains the Win32 5.
  • Control: performing the equivalent operation directly on this host succeeds —
    CreateFileW(dir, DELETE, FILE_SHARE_READ|WRITE|DELETE, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS) followed by SetFileInformationByHandle(h, FileDispositionInfoEx, DELETE|POSIX) removes the directory. Same session, same user,
    same directory as the failing self-test.

Happy to run further diagnostics on this host. It is a stable Windows 11 box with a
verified-working Ghidra 12.1.4 + JDK 21 outside REA, and its self-test is currently in
the failing state — which may be useful to diff against the passing host mentioned
earlier.

<!-- gh-comment-id:6161130600 --> @ranceil commented on GitHub (Oct 14, 2026): Independent reproduction on a second host — the self-test gate is a **false negative**: the MCP tool surface works while the CLI is still rejected Reporting a dimension I don't see covered above, because it changes the practical impact. ### Environment ``` REA: rea-agents 6.4.0 (same self-test failure on 6.3.0 and 5.0.0) Host: Windows 11 Pro, 10.0.26200, x64 (C:/D:/E: all NTFS, fixed, healthy) Node: v22.22.2 Ghidra: 12.1.4 PUBLIC JDK: Eclipse Temurin 21.0.12.1+1 (64-bit, full JDK) Token: elevated (TokenElevation = true) ``` ### The self-test still fails, deterministically, on this host `rea doctor --provider ghidra --json` reports `native_authority` as `ok:false` / `unsupported_host`, with the same `Delete owned object by handle failed … (Win32 5)` and the same leaked `rea-native-probe-<32hex>` directory. I ran it **12 times back to back: 12 failures, 0 passes.** So on this host it is not currently exhibiting the transient behaviour described in a comment above. ### But the native analysis itself works — through the MCP tool surface | Call | Result | |---|---| | `rea doctor --provider ghidra --json` | ❌ `native_authority` fails (12/12) | | CLI `rea analyze <pe>` (provider auto-selection) | ❌ `provider_unavailable` | | CLI `rea analyze <pe> --provider ghidra` (**explicit, too**) | ❌ `provider_unavailable` | | **MCP `open_binary` with `provider_id: "ghidra"`** | ✅ binds Ghidra successfully | | **MCP `binary_overview`** | ✅ **Ghidra 12.1.4 full analysis: 526 procedures, 241 strings, 6 segments** | Target: a 2004 32-bit PE application (x86). Verified twice on this host. Downstream tools (`search_strings`, `xrefs`, `procedure_pseudo_code`) also work in the same MCP session. ### Interpretation (hypothesis, not a finding) This is consistent with `systemWindowsNativeAuthority()` caching its probe result process-wide (`cached ??= …`, one probe per process). The long-running MCP host process evidently probed during a passing window and cached `available: true`; each new CLI process re-probes and fails. That also fits the transient behaviour reported earlier: the *probe* is unreliable, but the *capability* it probes for is present. ### Two consequences worth acting on 1. **The Impact section above is too pessimistic, and the current behaviour costs users real work.** A host in this state looks completely blocked — `rea doctor` says unavailable and the CLI refuses to run — while the MCP surface can perform the full analysis. The reasonable conclusion for a user is "native analysis on Windows doesn't work", and they stop. I nearly did. 2. **Suggestion: don't hard-gate a capability on a probe.** A failed self-test should degrade to a warning (and be recorded), not disable the provider for every surface. If the probe cannot be made reliable, then at minimum the CLI and the MCP surface should not disagree about whether the same capability exists. Concretely, alongside the retry-with-backoff suggestion already made: - Treat a `native_authority` probe failure as `degraded` rather than `unavailable`, and let each operation decide whether it actually needs native authority. - Have the CLI and the MCP surface share one admission decision, so a passing state in one is not invisible in the other. - Fix the remediation text: it currently points users at "use the matching Windows x64 REA package and a writable local NTFS temporary directory", neither of which is the constraint here. Something like "the native self-test failed; MCP tool calls may still work" would have saved days of investigation. ### Additional data points from this host (all measured) - **Wider reproduction range than reported**: `rea-agents` 5.0.0, 6.3.0 and 6.4.0 all report `providerInspections.ghidra.available: false`. In 5.0.0 the check is not surfaced under the `native_authority` name, but the outcome is identical — not a 6.3.x regression. - **Not antivirus, in either direction**: this host had a third-party endpoint product with kernel drivers loaded; after fully removing it and confirming services and drivers were gone, the self-test failed identically. The original report's host has no third-party AV registered at all. - **Survives a full reboot** with no lingering drivers or hooks. - **A second leak surface**: besides `rea-native-probe-*`, I also find leftover `rea-ghidra-*` directories in `%TEMP%` from failed Ghidra sessions (3 accumulated during this investigation, alongside 3 probe directories). - The leaked probe directory's security descriptor is exactly as intended (`icacls`: current user + SYSTEM full control, protected/non-inherited, no deny ACEs) and carries no Mandatory Label (default Medium) — so neither the DACL nor the integrity label explains the `Win32 5`. - **Control**: performing the equivalent operation directly on this host succeeds — `CreateFileW(dir, DELETE, FILE_SHARE_READ|WRITE|DELETE, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS)` followed by `SetFileInformationByHandle(h, FileDispositionInfoEx, DELETE|POSIX)` removes the directory. Same session, same user, same directory as the failing self-test. Happy to run further diagnostics on this host. It is a stable Windows 11 box with a verified-working Ghidra 12.1.4 + JDK 21 outside REA, and its self-test is currently in the **failing** state — which may be useful to diff against the passing host mentioned earlier.
Author
Owner

@3425103436 commented on GitHub (Oct 14, 2026):

A deterministic host for the [C:\] Win32 32 variant, plus a verified one-line fix — and it fails earlier than the Win32 5 family in this thread

This host does not reproduce the Delete owned object by handle failed (Win32 5) symptom at all. It fails one step earlier, while the self-test admits the path component C:\, and it fails 100% of the time. Posting it because it isolates a second, independently-fixable defect on the same self-test gate, and because it is a deterministic reproducer on a host that can also build the addon.

Environment

REA:    rea-agents 6.4.0 from npm (bundled rea-windows-x64.node, 848,252 B, sha256 c4fd9f377...)
Host:   Windows 11 家庭版 x64, build 26100
Node:   v22.22.0
Volume: C: and D: local NTFS, fixed; default %LOCALAPPDATA%\Temp
Token:  non-elevated ordinary user
AV:     Defender only

Reproduction

Called the bundled artifact directly, so no REA code is in the path:

require("<pkg>/native/windows/build/rea-windows-x64.node").call("inspect", []);
stock 6.4.0 addon : runs 5,  passed 0,  failed 5,  probeDirs before 0 / after 0, leaked 0
  failure (5/5): Open Windows path component failed [C:\] (Win32 32): 另一个程序正在使用此文件,进程无法访问。

Also 6/6 through the CLI, with the analysed fixture on C:, on D:, and on a SUBST-mapped drive — not target-dependent, and it happens with the target nowhere near a drive root.

The notable part: zero rea-native-probe-* directories are ever left behind, because the self-test never reaches createRuntime. On hosts where the volume-root open succeeds, this failure is invisible and only the later delete-by-handle defect shows — which is why it does not appear in the reports above.

The Windows rule being hit

Measured on this host with CreateFileW (access FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT):

path share=READ R|W R|D R|W|D
C:\ FAIL 32 ok FAIL 32 ok
D:\ FAIL 32 ok FAIL 32 ok
\\?\C:\ FAIL 32 ok FAIL 32 ok
C:\Users, C:\Windows, \\?\C:\Users ok ok ok ok

Only a mounted volume root requires FILE_SHARE_WRITE; ordinary directories accept any share mode. An elevated full handle scan (handle64 -a, 150,601 lines, 9,708 File handles) finds no C:\ or D:\ handle in any enumerable process, so the conflicting open on the volume root is not a user process I can name; the same failure also reproduces from a process launched outside any shell or agent wrapper (Win32_Process.Create), so no wrapper is involved.

Source

Tag rea-agents-6.4.0, native/windows/src/filesystem.cc:

  • line 41: static Handle openComponent(..., DWORD sharing = FILE_SHARE_READ)
  • line 68: result->handles.push_back(openComponent(path.substr(0, 3), 0, true)); — the volume-root component uses that default
  • line 88: the relax to FILE_SHARE_READ | FILE_SHARE_WRITE runs only after the strict open, so it cannot rescue line 68
  • openComponent always adds FILE_LIST_DIRECTORY, so it takes part in the symmetric share check, unlike an attribute-only open

This line is unchanged on main as of 2026-10-14, so #2445 (FILE_SHARE_DELETE) does not cover this variant. The same string is the subject of #2257, which was closed as COMPLETED for the classification change in main; this is about the underlying sharing violation, and here it is deterministic rather than intermittent.

One-line fix, verified on this host

--- a/native/windows/src/filesystem.cc
+++ b/native/windows/src/filesystem.cc
@@ -65,7 +65,7 @@
   require(directory || path.size() > 3, "Target is not a regular file", requested, ERROR_DIRECTORY);
-  result->handles.push_back(openComponent(path.substr(0, 3), 0, true));
+  result->handles.push_back(openComponent(path.substr(0, 3), 0, true, FILE_SHARE_READ | FILE_SHARE_WRITE));

The volume root has no parent name and can be neither replaced nor deleted, line 88 already relaxes the same object one iteration later, and the handle is used only for GetDriveTypeW and GetVolumeInformationByHandleW (NTFS + persistent ACL check), so relaxing write sharing on that one component gives up nothing.

Verification: I rebuilt addon.cc / filesystem.cc / process.cc from tag a56f7bb with MSVC 14.44.35207 + Windows SDK 10.0.26100 (/std:c++17 /O2 /DNAPI_VERSION=8 /D_WIN32_WINNT=0x0A00, linking node.lib advapi32 bcrypt ntdll; 240,640 bytes, sha256 f04a25bb932300871536c69d622688804051621f08113b8e10e1429557d3f0bc) because the documented lane needs Linux + MinGW-w64, and updated artifactSha256 in the manifest for the rebuilt artifact.

patched addon : runs 30, passed 30, failed 0, probeDirs before 0 / after 0, leaked 0
inspection    : abiVersion 1, nodeApiVersion 8, x64, filesystem NTFS, directory true,
                privateDacl true, atomicJobAssignment true, killOnOwnerClose true,
                protocolStdin true, jobMemoryLimit true

End to end with that artifact: analyze-javascript-application exits 0 with no native-control limitation and no incomplete-module; inspect-managed-artifact is unchanged (ev_b6684470757afa691cccce4dc69b4f40b582cd9e174f40580f6072fd5d1b65f4); rea doctor reports the native authority healthy.

What this host adds to this issue

  1. The delete-by-handle path is fine here: the patched addon ran create+delete 30/30 with zero leaked probe directories. So this host does not reproduce the Win32 5 symptom at all — the Win32 5 family and this Win32 32 variant look like two independent, host-dependent properties of the same self-test, and on a host like this one the earlier failure masks the later one.
  2. It is deterministic (5/5, and 100% of every earlier attempt) on a host that can also build the addon, which the comments above were asking for. If the REA_DIAG_1701 instrumented build is still useful, I can run it here — though on this host the diagnostic will report the open failure before it reaches NtQueryObject, so it may need to instrument the component open as well.

Remaining uncertainty on my side: what holds the volume root with write access on this host could not be attributed to any process even when elevated, and only this one host was tested.

<!-- gh-comment-id:6166288161 --> @3425103436 commented on GitHub (Oct 14, 2026): **A deterministic host for the `[C:\]` Win32 32 variant, plus a verified one-line fix — and it fails *earlier* than the Win32 5 family in this thread** This host does not reproduce the `Delete owned object by handle failed (Win32 5)` symptom at all. It fails one step earlier, while the self-test admits the path component `C:\`, and it fails 100% of the time. Posting it because it isolates a second, independently-fixable defect on the same self-test gate, and because it is a deterministic reproducer on a host that can also build the addon. ### Environment ``` REA: rea-agents 6.4.0 from npm (bundled rea-windows-x64.node, 848,252 B, sha256 c4fd9f377...) Host: Windows 11 家庭版 x64, build 26100 Node: v22.22.0 Volume: C: and D: local NTFS, fixed; default %LOCALAPPDATA%\Temp Token: non-elevated ordinary user AV: Defender only ``` ### Reproduction Called the bundled artifact directly, so no REA code is in the path: ```js require("<pkg>/native/windows/build/rea-windows-x64.node").call("inspect", []); ``` ``` stock 6.4.0 addon : runs 5, passed 0, failed 5, probeDirs before 0 / after 0, leaked 0 failure (5/5): Open Windows path component failed [C:\] (Win32 32): 另一个程序正在使用此文件,进程无法访问。 ``` Also 6/6 through the CLI, with the analysed fixture on `C:`, on `D:`, and on a `SUBST`-mapped drive — not target-dependent, and it happens with the target nowhere near a drive root. The notable part: **zero `rea-native-probe-*` directories are ever left behind**, because the self-test never reaches `createRuntime`. On hosts where the volume-root open succeeds, this failure is invisible and only the later delete-by-handle defect shows — which is why it does not appear in the reports above. ### The Windows rule being hit Measured on this host with `CreateFileW` (access `FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES`, `OPEN_EXISTING`, `FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT`): | path | share=READ | R\|W | R\|D | R\|W\|D | |---|---|---|---|---| | `C:\` | FAIL 32 | ok | FAIL 32 | ok | | `D:\` | FAIL 32 | ok | FAIL 32 | ok | | `\\?\C:\` | FAIL 32 | ok | FAIL 32 | ok | | `C:\Users`, `C:\Windows`, `\\?\C:\Users` | ok | ok | ok | ok | Only a mounted volume root requires `FILE_SHARE_WRITE`; ordinary directories accept any share mode. An elevated full handle scan (`handle64 -a`, 150,601 lines, 9,708 `File` handles) finds **no** `C:\` or `D:\` handle in any enumerable process, so the conflicting open on the volume root is not a user process I can name; the same failure also reproduces from a process launched outside any shell or agent wrapper (`Win32_Process.Create`), so no wrapper is involved. ### Source Tag `rea-agents-6.4.0`, `native/windows/src/filesystem.cc`: - line 41: `static Handle openComponent(..., DWORD sharing = FILE_SHARE_READ)` - line 68: `result->handles.push_back(openComponent(path.substr(0, 3), 0, true));` — the volume-root component uses that default - line 88: the relax to `FILE_SHARE_READ | FILE_SHARE_WRITE` runs only *after* the strict open, so it cannot rescue line 68 - `openComponent` always adds `FILE_LIST_DIRECTORY`, so it takes part in the symmetric share check, unlike an attribute-only open This line is unchanged on `main` as of 2026-10-14, so #2445 (`FILE_SHARE_DELETE`) does not cover this variant. The same string is the subject of #2257, which was closed as COMPLETED for the *classification* change in main; this is about the underlying sharing violation, and here it is deterministic rather than intermittent. ### One-line fix, verified on this host ```diff --- a/native/windows/src/filesystem.cc +++ b/native/windows/src/filesystem.cc @@ -65,7 +65,7 @@ require(directory || path.size() > 3, "Target is not a regular file", requested, ERROR_DIRECTORY); - result->handles.push_back(openComponent(path.substr(0, 3), 0, true)); + result->handles.push_back(openComponent(path.substr(0, 3), 0, true, FILE_SHARE_READ | FILE_SHARE_WRITE)); ``` The volume root has no parent name and can be neither replaced nor deleted, line 88 already relaxes the same object one iteration later, and the handle is used only for `GetDriveTypeW` and `GetVolumeInformationByHandleW` (NTFS + persistent ACL check), so relaxing write sharing on that one component gives up nothing. Verification: I rebuilt `addon.cc` / `filesystem.cc` / `process.cc` from tag `a56f7bb` with MSVC 14.44.35207 + Windows SDK 10.0.26100 (`/std:c++17 /O2 /DNAPI_VERSION=8 /D_WIN32_WINNT=0x0A00`, linking `node.lib advapi32 bcrypt ntdll`; 240,640 bytes, sha256 `f04a25bb932300871536c69d622688804051621f08113b8e10e1429557d3f0bc`) because the documented lane needs Linux + MinGW-w64, and updated `artifactSha256` in the manifest for the rebuilt artifact. ``` patched addon : runs 30, passed 30, failed 0, probeDirs before 0 / after 0, leaked 0 inspection : abiVersion 1, nodeApiVersion 8, x64, filesystem NTFS, directory true, privateDacl true, atomicJobAssignment true, killOnOwnerClose true, protocolStdin true, jobMemoryLimit true ``` End to end with that artifact: `analyze-javascript-application` exits 0 with no native-control limitation and no `incomplete-module`; `inspect-managed-artifact` is unchanged (`ev_b6684470757afa691cccce4dc69b4f40b582cd9e174f40580f6072fd5d1b65f4`); `rea doctor` reports the native authority healthy. ### What this host adds to this issue 1. The delete-by-handle path is **fine here**: the patched addon ran create+delete 30/30 with zero leaked probe directories. So this host does not reproduce the Win32 5 symptom at all — the Win32 5 family and this Win32 32 variant look like two independent, host-dependent properties of the same self-test, and on a host like this one the earlier failure masks the later one. 2. It is deterministic (5/5, and 100% of every earlier attempt) on a host that can also build the addon, which the comments above were asking for. If the `REA_DIAG_1701` instrumented build is still useful, I can run it here — though on this host the diagnostic will report the open failure before it reaches `NtQueryObject`, so it may need to instrument the component open as well. Remaining uncertainty on my side: what holds the volume root with write access on this host could not be attributed to any process even when elevated, and only this one host was tested.
Author
Owner

@morluto commented on GitHub (Oct 14, 2026):

A separate, deterministic Win32 32 root-open defect from the later comments is fixed in 9a44fea34. The initial immutable volume-root handle now permits WRITE sharing, matching the existing later root reopen. Descendant write/replacement/reparse and ownership checks remain active.

Portable hosted Windows red/green evidence: https://github.com/morluto/rea/actions/runs/38646244125. A fixture held an actual FILE_ADD_SUBDIRECTORY root handle without writing. The exact old addon failed native target admission with Win32 32; the fixed addon admitted the same target and passed the complete native boundary verifier, including source-write/replacement denial, reparse denial, unrelated writes, cancellation and retained cleanup ownership. The hosted token was elevated; ordinary-token ACL behavior was not established by that run. Final integrated qualification: https://github.com/morluto/rea/actions/runs/38652688611.

Keeping this issue open: this establishes the root sharing variant, not the original Win32 5 deletion failure or its affected-host cause.

<!-- gh-comment-id:6180767269 --> @morluto commented on GitHub (Oct 14, 2026): A separate, deterministic Win32 **32** root-open defect from the later comments is fixed in `9a44fea34`. The initial immutable volume-root handle now permits WRITE sharing, matching the existing later root reopen. Descendant write/replacement/reparse and ownership checks remain active. Portable hosted Windows red/green evidence: https://github.com/morluto/rea/actions/runs/38646244125. A fixture held an actual `FILE_ADD_SUBDIRECTORY` root handle without writing. The exact old addon failed native target admission with Win32 32; the fixed addon admitted the same target and passed the complete native boundary verifier, including source-write/replacement denial, reparse denial, unrelated writes, cancellation and retained cleanup ownership. The hosted token was elevated; ordinary-token ACL behavior was not established by that run. Final integrated qualification: https://github.com/morluto/rea/actions/runs/38652688611. Keeping this issue open: this establishes the root sharing variant, not the original Win32 **5** deletion failure or its affected-host cause.
Author
Owner

@winull commented on GitHub (Oct 15, 2026):

New data point + deterministic root-cause diagnosis for #1701 (and #3111)

Posting a fresh failing host with a ctypes-based reproduction that pins the mechanism without needing to compile the addon. This host is the first Windows 10 + UAC-disabled + High-integrity case, which also rules out the "UAC disabled + elevated token ⇒ passes" theory from earlier in this thread.

Environment

OS Windows 10 Home Single Language, build 19045 (22H2), x64
REA rea-agents@6.4.0 (npm, bundled rea-windows-x64.node)
Node v22.22.2
UAC EnableLUA = 0 (disabled)
Token High integrity (S-1-16-12288), not restricted
Third-party AV None (QQ PC Manager fully removed; its QQSysMonX64/TFsFlt minifilters are gone)
Defender real-time on, WdFilter loaded (Boot)
Minifilters only system ones (WdFilter / FileInfo / Wof / FileCrypt / exhlpdrv / npsvctrig …)
%TEMP% local NTFS C: (not Dev Drive / ReFS / redirected)

Symptom: native_authority → unsupported_host, Delete owned object by handle failed (Win32 5), one leaked rea-native-probe-<32hex> per run.

Method

Reproduced the addon's exact call shape via Python ctypes (no C++ toolchain):

  1. NtCreateFile a directory with access DELETE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | READ_CONTROL | SYNCHRONIZE, FILE_CREATE, FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_OPEN_REPARSE_POINT.
  2. NtQueryObject(ObjectBasicInformation) to read HandleCount and GrantedAccess.
  3. SetFileInformationByHandle(FileDispositionInfo, DeleteFile=TRUE).
  4. Re-query on failure.

Results

Test A — no duplicate, delete on the single original handle (HandleCount == 1):

ShareAccess at create HandleCount GrantedAccess Delete result
FILE_SHARE_READ (what REA uses) 1 0x00130081 ❌ FAIL Win32 5
FILE_SHARE_READ | FILE_SHARE_DELETE 1 0x00130081 ✅ OK Win32 0

Test B — duplicate then delete (mirrors closeRuntime):

ShareAccess HandleCount (before) HandleCount (after dup) Delete result
FILE_SHARE_READ 1 2 ❌ FAIL Win32 5
FILE_SHARE_READ|WRITE|DELETE 1 2 ✅ OK
0 (exclusive) 1 2 ❌ FAIL Win32 5

Conclusions

  1. Root cause is the create-time share mode, not a second handle. Deleting on a single handle (HandleCount == 1) already fails with FILE_SHARE_READ, and succeeds the moment FILE_SHARE_DELETE is added. So this is not the "unobserved second holder" mechanism — it is createRelative opening the owned directory without FILE_SHARE_DELETE.

  2. This confirms the fix direction of #2445. Adding FILE_SHARE_DELETE to the share mode flips delete-by-handle from fail (Win32 5) to success (Win32 0) deterministically on this host, independent of DACL and directory emptiness.

  3. New environment class. Failing hosts now include Windows 10 (19045, Home Single Language) with UAC disabled and a High-integrity token — so the "elevated / UAC-off passes" observation from earlier does not hold here. The China-localized build may be the common thread with @liudong-geek's Win11 Home China host, but that is secondary to the deterministic FILE_SHARE_DELETE defect.

Happy to run the instrumented build from #1701 (comment 6130599030) if a container becomes available, but this ctypes reproduction already answers the handleCount question directly: it is 1, and it still fails.

<!-- gh-comment-id:6184554193 --> @winull commented on GitHub (Oct 15, 2026): ## New data point + deterministic root-cause diagnosis for #1701 (and #3111) Posting a fresh failing host with a ctypes-based reproduction that pins the mechanism **without needing to compile the addon**. This host is the first **Windows 10 + UAC-disabled + High-integrity** case, which also rules out the "UAC disabled + elevated token ⇒ passes" theory from earlier in this thread. ### Environment | | | |---|---| | OS | **Windows 10 Home Single Language, build 19045 (22H2), x64** | | REA | `rea-agents@6.4.0` (npm, bundled `rea-windows-x64.node`) | | Node | v22.22.2 | | UAC | **EnableLUA = 0 (disabled)** | | Token | **High integrity (S-1-16-12288)**, not restricted | | Third-party AV | **None** (QQ PC Manager fully removed; its `QQSysMonX64`/`TFsFlt` minifilters are gone) | | Defender | real-time on, `WdFilter` loaded (Boot) | | Minifilters | only system ones (WdFilter / FileInfo / Wof / FileCrypt / exhlpdrv / npsvctrig …) | | `%TEMP%` | local NTFS `C:` (not Dev Drive / ReFS / redirected) | Symptom: `native_authority` → `unsupported_host`, `Delete owned object by handle failed (Win32 5)`, one leaked `rea-native-probe-<32hex>` per run. ### Method Reproduced the addon's exact call shape via Python `ctypes` (no C++ toolchain): 1. `NtCreateFile` a directory with access `DELETE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | READ_CONTROL | SYNCHRONIZE`, `FILE_CREATE`, `FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_OPEN_REPARSE_POINT`. 2. `NtQueryObject(ObjectBasicInformation)` to read `HandleCount` and `GrantedAccess`. 3. `SetFileInformationByHandle(FileDispositionInfo, DeleteFile=TRUE)`. 4. Re-query on failure. ### Results **Test A — no duplicate, delete on the single original handle (`HandleCount == 1`):** | ShareAccess at create | HandleCount | GrantedAccess | Delete result | |---|---|---|---| | `FILE_SHARE_READ` (what REA uses) | **1** | `0x00130081` | ❌ **FAIL Win32 5** | | `FILE_SHARE_READ \| FILE_SHARE_DELETE` | **1** | `0x00130081` | ✅ OK Win32 0 | **Test B — duplicate then delete (mirrors `closeRuntime`):** | ShareAccess | HandleCount (before) | HandleCount (after dup) | Delete result | |---|---|---|---| | `FILE_SHARE_READ` | 1 | 2 | ❌ FAIL Win32 5 | | `FILE_SHARE_READ\|WRITE\|DELETE` | 1 | 2 | ✅ OK | | `0` (exclusive) | 1 | 2 | ❌ FAIL Win32 5 | ### Conclusions 1. **Root cause is the create-time share mode, not a second handle.** Deleting on a *single* handle (`HandleCount == 1`) already fails with `FILE_SHARE_READ`, and succeeds the moment `FILE_SHARE_DELETE` is added. So this is not the "unobserved second holder" mechanism — it is `createRelative` opening the owned directory without `FILE_SHARE_DELETE`. 2. **This confirms the fix direction of #2445.** Adding `FILE_SHARE_DELETE` to the share mode flips delete-by-handle from fail (Win32 5) to success (Win32 0) deterministically on this host, independent of DACL and directory emptiness. 3. **New environment class.** Failing hosts now include Windows 10 (19045, Home Single Language) with UAC *disabled* and a *High*-integrity token — so the "elevated / UAC-off passes" observation from earlier does not hold here. The China-localized build may be the common thread with @liudong-geek's Win11 Home China host, but that is secondary to the deterministic `FILE_SHARE_DELETE` defect. Happy to run the instrumented build from #1701 (comment 6130599030) if a container becomes available, but this ctypes reproduction already answers the `handleCount` question directly: it is `1`, and it still fails.
Author
Owner

@evenafterallisaid commented on GitHub (Oct 17, 2026):

additional ordinary-user Windows verification at 3460ceac3f5dc93c767b1e7c39a511f026b41baa:

  • Windows 11 Home, build 10.0.26340, Node.js 24.18.0; non-admin, non-elevated, medium integrity (8192), inside a Job Object.
  • production addon and compiled runtime from run 39062252359; addon SHA-256 28e0a01f74b30232db559bf98f574be82e5c71ad36a86e4c38fe7fb448029856. the real loader accepted its manifest and digest.
  • direct inspect probes in 30 fresh processes per artifact: stock 6.4.0 (c4fd9f37…) 30/30 passed, current main 30/30 passed, zero residual probe directories in either isolated temp tree.
  • the unmodified scripts/verify-windows-native.mjs from that commit passed against the matching runtime/addon, including cleanup retry ownership, transient sharing conflicts, readonly root/child deletion, junction isolation, and source write/replacement denial.

this host also passes the original artifact, so these results do not establish a red/green reproduction of Win32 5 or justify closing this issue. #2445 already supplies the share-mode correction; the remaining evidence gap is a comparison on an originally failing host using a matching current build. no additional source fix was established by this investigation. Ghidra/Android provider workflows were not run.

<!-- gh-comment-id:6239815013 --> @evenafterallisaid commented on GitHub (Oct 17, 2026): additional ordinary-user Windows verification at `3460ceac3f5dc93c767b1e7c39a511f026b41baa`: - Windows 11 Home, build `10.0.26340`, Node.js `24.18.0`; non-admin, non-elevated, medium integrity (`8192`), inside a Job Object. - production addon and compiled runtime from [run 39062252359](https://github.com/morluto/rea/actions/runs/39062252359); addon SHA-256 `28e0a01f74b30232db559bf98f574be82e5c71ad36a86e4c38fe7fb448029856`. the real loader accepted its manifest and digest. - direct `inspect` probes in 30 fresh processes per artifact: stock 6.4.0 (`c4fd9f37…`) **30/30 passed**, current main **30/30 passed**, zero residual probe directories in either isolated temp tree. - the unmodified `scripts/verify-windows-native.mjs` from that commit passed against the matching runtime/addon, including cleanup retry ownership, transient sharing conflicts, readonly root/child deletion, junction isolation, and source write/replacement denial. this host also passes the original artifact, so these results do **not** establish a red/green reproduction of Win32 5 or justify closing this issue. #2445 already supplies the share-mode correction; the remaining evidence gap is a comparison on an originally failing host using a matching current build. no additional source fix was established by this investigation. Ghidra/Android provider workflows were not run.
Author
Owner

@halfeat commented on GitHub (Oct 29, 2026):

6.8.0 (npm) still fails on a real Windows host — and the failure is now at the create step

Adding a current-release data point. Every report in this thread so far is 6.3.0/6.4.0 or main at a
commit; this is the published 6.8.0 tarball, and the message is not Delete owned object by handle failed but the create step, which I could not find reported here:

$ rea doctor --json          # ghidra-java check
ok: false
detail: C:\Program Files\Java\jdk-21.0.2\bin\java.exe: REA Windows native self-test failed:
        Create private object relative to its admitted parent failed
        [C:\Users\<user>\AppData\Local\Temp\rea-native-probe-<32hex>] (Win32 5): Access is denied.

Ghidra detection itself is clean (ghidra, ghidra-installation, ghidra-headless,
ghidra-native_decompiler, all ok). Every provider operation then fails closed in ~3 s
(rea decompile <pe> <addr> → provider_unavailable).

No probe directories are left behind: 0 rea-native-probe-* in either TEMP tree after repeated runs,
so the cleanup leak in the original report looks addressed on 6.8.0.

REA rea-agents@6.8.0, npm, local install (npm install rea-agents@6.8.0)
Host Windows 11 10.0.22631 x64, non-admin, locale zh-CN ("拒绝访问" = Access is denied)
Node v24.22.1 (portable) — and v24.14.1 on the same host for comparison
Engine Ghidra 12.1.4 PUBLIC, full 64-bit JDK 21.0.2 (javac present), GHIDRA_INSTALL_DIR + JAVA_HOME set

The Node binary flips the outcome on this host

Same host, same Ghidra/JDK, same process token, only the node.exe changed:

Node ghidra-java real operation
v24.22.1 (satisfies engines: ^24.22.1) FAIL (create, Win32 5) decompile → provider_unavailable in 3 s
v24.14.1 (below the ^24.22.1 floor) ok decompile returns pseudocode in ~105 s

Both load native/windows/build/rea-windows-x64.node without error. If the native authority layer is
engaged per Node version, that would explain the split — worth stating either way, since the
unsupported runtime is the one that passes here.

TEMP parent does matter here (contradicting the exclusion above)

An earlier comment ruled out "three different temp parents (including one on another volume)". On this
host the parent decides the outcome deterministically:

TEMP location result
%LOCALAPPDATA%\Temp (default) FAIL
child of default TEMP FAIL
%LOCALAPPDATA%\Temp2 FAIL
E:\tmptestA (plain dir, volume root, no reparse point) FAIL
C:\rea-tmpprobe with a protected DACL (icacls /inheritance:r /grant:r <user>:(OI)(CI)F SYSTEM:(OI)(CI)F) FAIL
any directory under one specific parent tree on this host ok

The only stable difference I can see between passing and failing parents is their ACL:

passing:  Everyone:(CI)(DENY)(DC)
          <user>:(OI)(CI)(WO)                 # write-only, no DELETE
          S-1-4-<...>:(OI)(CI)(W,D,DC)        # an additional non-user SID
          BUILTIN\Administrators:(I)(F) ...
failing:  BUILTIN\Administrators:(I)(F) / NT AUTHORITY\SYSTEM:(I)(F)
          NT AUTHORITY\Authenticated Users:(I)(M)

I am not claiming that ACL is the cause — I did not establish the mechanism, and the excluded
cases above (DACL, other volumes, reparse points) all reproduce here too. I am reporting that
"location does not matter" does not hold on this host, and that the passing shape is one the
self-test apparently tolerates.

Remediation text still misdirects on 6.8.0

Asked for earlier in this thread, still present in the release: doctor attaches

Update JAVA_HOME to the root of a 64-bit full JDK 21 or newer installation.

to this failure, while the package's own inspection-stage text for the same self-test says
"reinstalling Ghidra or Java cannot fix this self-test", and the same result already carries
21.0.2; 64-bit; JDK.

Reproduction

Read-only PowerShell probe I used (creates and removes empty scratch dirs, sets TEMP/TMP per probe,
never touches ACLs, configuration or targets) — happy to attach or run anything else you need:

powershell -NoProfile -ExecutionPolicy Bypass -File temp-matrix.ps1 `
  -ReaScript "<...>\node_modules\rea-agents\scripts\rea.mjs" -NodeExe "<...>\node.exe" `
  -GhidraInstallDir "<...>\ghidra_12.1.4_PUBLIC" -JavaHome "C:\Program Files\Java\jdk-21.0.2" `
  -ExtraTempDirs "<candidate temp parent>"

Question: is the create-time failure on 6.8.0 expected to be covered by the share-mode fix, or is it a
second, separate defect in the create path? If a matching build on an originally failing host is the
remaining evidence gap (as noted above), this host is available for it.


Machine user account (GitHub ToS §B.3), created and owned by @tomtuych. This report was produced on the
owner's Windows host; commands and outputs above are from that host.

<!-- gh-comment-id:6500827809 --> @halfeat commented on GitHub (Oct 29, 2026): ### 6.8.0 (npm) still fails on a real Windows host — and the failure is now at the **create** step Adding a current-release data point. Every report in this thread so far is `6.3.0`/`6.4.0` or `main` at a commit; this is the published **6.8.0** tarball, and the message is not `Delete owned object by handle failed` but the **create** step, which I could not find reported here: ``` $ rea doctor --json # ghidra-java check ok: false detail: C:\Program Files\Java\jdk-21.0.2\bin\java.exe: REA Windows native self-test failed: Create private object relative to its admitted parent failed [C:\Users\<user>\AppData\Local\Temp\rea-native-probe-<32hex>] (Win32 5): Access is denied. ``` Ghidra detection itself is clean (`ghidra`, `ghidra-installation`, `ghidra-headless`, `ghidra-native_decompiler`, all ok). Every provider operation then fails closed in ~3 s (`rea decompile <pe> <addr>` → `provider_unavailable`). No probe directories are left behind: 0 `rea-native-probe-*` in either TEMP tree after repeated runs, so the cleanup leak in the original report looks addressed on 6.8.0. | | | |---|---| | REA | `rea-agents@6.8.0`, npm, local install (`npm install rea-agents@6.8.0`) | | Host | Windows 11 `10.0.22631` x64, non-admin, locale zh-CN ("拒绝访问" = Access is denied) | | Node | **v24.22.1** (portable) — and v24.14.1 on the same host for comparison | | Engine | Ghidra 12.1.4 PUBLIC, full 64-bit JDK 21.0.2 (`javac` present), `GHIDRA_INSTALL_DIR` + `JAVA_HOME` set | #### The Node binary flips the outcome on this host Same host, same Ghidra/JDK, same process token, only the `node.exe` changed: | Node | `ghidra-java` | real operation | |---|---|---| | v24.22.1 (satisfies `engines: ^24.22.1`) | **FAIL** (create, Win32 5) | `decompile` → `provider_unavailable` in 3 s | | v24.14.1 (below the `^24.22.1` floor) | ok | `decompile` returns pseudocode in ~105 s | Both load `native/windows/build/rea-windows-x64.node` without error. If the native authority layer is engaged per Node version, that would explain the split — worth stating either way, since the *unsupported* runtime is the one that passes here. #### TEMP parent does matter here (contradicting the exclusion above) An earlier comment ruled out "three different temp parents (including one on another volume)". On this host the parent decides the outcome deterministically: | TEMP location | result | |---|---| | `%LOCALAPPDATA%\Temp` (default) | FAIL | | child of default TEMP | FAIL | | `%LOCALAPPDATA%\Temp2` | FAIL | | `E:\tmptestA` (plain dir, volume root, no reparse point) | FAIL | | `C:\rea-tmpprobe` with a **protected DACL** (`icacls /inheritance:r /grant:r <user>:(OI)(CI)F SYSTEM:(OI)(CI)F`) | FAIL | | any directory under one specific parent tree on this host | **ok** | The only stable difference I can see between passing and failing parents is their ACL: ``` passing: Everyone:(CI)(DENY)(DC) <user>:(OI)(CI)(WO) # write-only, no DELETE S-1-4-<...>:(OI)(CI)(W,D,DC) # an additional non-user SID BUILTIN\Administrators:(I)(F) ... failing: BUILTIN\Administrators:(I)(F) / NT AUTHORITY\SYSTEM:(I)(F) NT AUTHORITY\Authenticated Users:(I)(M) ``` I am **not** claiming that ACL is the cause — I did not establish the mechanism, and the excluded cases above (DACL, other volumes, reparse points) all reproduce here too. I am reporting that "location does not matter" does not hold on this host, and that the passing shape is one the self-test apparently tolerates. #### Remediation text still misdirects on 6.8.0 Asked for earlier in this thread, still present in the release: `doctor` attaches > Update JAVA_HOME to the root of a 64-bit full JDK 21 or newer installation. to this failure, while the package's own `inspection`-stage text for the same self-test says "reinstalling Ghidra or Java cannot fix this self-test", and the same result already carries `21.0.2; 64-bit; JDK`. #### Reproduction Read-only PowerShell probe I used (creates and removes empty scratch dirs, sets TEMP/TMP per probe, never touches ACLs, configuration or targets) — happy to attach or run anything else you need: ```powershell powershell -NoProfile -ExecutionPolicy Bypass -File temp-matrix.ps1 ` -ReaScript "<...>\node_modules\rea-agents\scripts\rea.mjs" -NodeExe "<...>\node.exe" ` -GhidraInstallDir "<...>\ghidra_12.1.4_PUBLIC" -JavaHome "C:\Program Files\Java\jdk-21.0.2" ` -ExtraTempDirs "<candidate temp parent>" ``` Question: is the create-time failure on 6.8.0 expected to be covered by the share-mode fix, or is it a second, separate defect in the create path? If a matching build on an originally failing host is the remaining evidence gap (as noted above), this host is available for it. --- <sub>Machine user account (GitHub ToS §B.3), created and owned by @tomtuych. This report was produced on the owner's Windows host; commands and outputs above are from that host.</sub>
Author
Owner

@pablodiazjorge commented on GitHub (Oct 29, 2026):

A countercheck for the Node 24.22.1 data point above, from the passing host in my earlier comments:

Host Windows 11 Pro 26H2, build 26300.9711, x64, medium integrity (not elevated), Defender real-time protection on, es-ES locale
REA rea-agents@6.8.0 from the published tarball (shasum and integrity match the registry), installed in a scratch folder
Node v24.22.1
Engine Ghidra 12.1.4 PUBLIC, Temurin JDK 21.0.12
TEMP default %LOCALAPPDATA%\Temp on local NTFS; the user, SYSTEM and Administrators have inherited Full Control
  • The packaged rea-windows-x64.node loaded directly, calling the self-test the loader runs (binding.call("inspect", [])): 50/50 passed on v24.22.1 and 50/50 on v22.22.3, with no rea-native-probe-* directory left.
  • rea doctor --provider ghidra --json: ghidra-native_authority ok in 20/20 runs, about 1.3 s each, and ghidra-java ok.
  • rea inspect WinHelloCPP.exe --provider ghidra --format json, on the x86 PE from Ghidra's GhidraClass exercises: completed in about 32 s with 6 segments, 388 procedures and 254 strings, leaving no java process or probe directory.

So on this host the create step succeeds with the same Node release and the same addon; Node 24.22.1 alone does not make it fail. I don't have v24.14.1 here, so I can't repeat your comparison in the other direction.

<!-- gh-comment-id:6503009968 --> @pablodiazjorge commented on GitHub (Oct 29, 2026): A countercheck for the Node 24.22.1 data point above, from the passing host in my earlier comments: | | | |---|---| | Host | Windows 11 Pro 26H2, build 26300.9711, x64, medium integrity (not elevated), Defender real-time protection on, es-ES locale | | REA | `rea-agents@6.8.0` from the published tarball (shasum and integrity match the registry), installed in a scratch folder | | Node | v24.22.1 | | Engine | Ghidra 12.1.4 PUBLIC, Temurin JDK 21.0.12 | | TEMP | default `%LOCALAPPDATA%\Temp` on local NTFS; the user, SYSTEM and Administrators have inherited Full Control | - The packaged `rea-windows-x64.node` loaded directly, calling the self-test the loader runs (`binding.call("inspect", [])`): 50/50 passed on v24.22.1 and 50/50 on v22.22.3, with no `rea-native-probe-*` directory left. - `rea doctor --provider ghidra --json`: `ghidra-native_authority` ok in 20/20 runs, about 1.3 s each, and `ghidra-java` ok. - `rea inspect WinHelloCPP.exe --provider ghidra --format json`, on the x86 PE from Ghidra's GhidraClass exercises: completed in about 32 s with 6 segments, 388 procedures and 254 strings, leaving no `java` process or probe directory. So on this host the create step succeeds with the same Node release and the same addon; Node 24.22.1 alone does not make it fail. I don't have v24.14.1 here, so I can't repeat your comparison in the other direction.
Author
Owner

@halfeat commented on GitHub (Oct 30, 2026):

Correction — my two earlier data points were confounded, and I'm sorry for the noise. Nothing in my previous comment should be used as evidence of a defect in REA.

Short version: on this host the native self-test fails only when the node.exe that loads the addon sits inside one specific sandboxed directory tree. Move the identical binary out and it passes. Neither the Node build nor the %TEMP% parent matters — both of my earlier tables were measuring the binary's location.

What I got wrong

  • I claimed v24.22.1 fails and v24.14.1 passes. Those two builds happened to be installed in different directories. Placed under the same conditions, both behave identically.
  • I claimed the %TEMP% parent decides the outcome. Every one of those runs used the binary inside that tree. With the binary outside it, the TEMP parents I tried all pass (%LOCALAPPDATA%\Temp, C:\Users\<user>, …\Temp2, E:\tmptestA, a directory inside the tree, the tree root).

Controlled test — same addon, same %TEMP%, and for each row the two node.exe files are byte-identical (sha256 checked):

node.exe inside the tree node.exe in a plain directory
v24.22.1 FAIL — Create private object relative to its admitted parent failed (Win32 5) pass
v24.14.1 FAIL — same error pass

b.call('inspect', []) outside REA reproduces it, so this is not the CLI/MCP wrapper.

The tree differs from the passing locations in its ACL and mandatory integrity label (it is a harness sandbox workspace); I did not isolate which property matters. So treat that as a lead for anyone reproducing this, not as an explanation.

Possibly useful to other reporters

  • the executable's directory can raise this same error, which the current remediation text (temporary-directory writability/DACL) does not hint at;
  • a one-minute discriminator: copy the identical node.exe to a plain directory and rerun before attributing the failure to the package.
<!-- gh-comment-id:6518068742 --> @halfeat commented on GitHub (Oct 30, 2026): **Correction — my two earlier data points were confounded, and I'm sorry for the noise.** Nothing in my previous comment should be used as evidence of a defect in REA. Short version: on this host the native self-test fails **only when the `node.exe` that loads the addon sits inside one specific sandboxed directory tree**. Move the identical binary out and it passes. Neither the Node build nor the `%TEMP%` parent matters — both of my earlier tables were measuring the binary's location. **What I got wrong** - *I claimed v24.22.1 fails and v24.14.1 passes.* Those two builds happened to be installed in different directories. Placed under the same conditions, both behave identically. - *I claimed the `%TEMP%` parent decides the outcome.* Every one of those runs used the binary inside that tree. With the binary outside it, the TEMP parents I tried all pass (`%LOCALAPPDATA%\Temp`, `C:\Users\<user>`, `…\Temp2`, `E:\tmptestA`, a directory inside the tree, the tree root). **Controlled test** — same addon, same `%TEMP%`, and for each row the two `node.exe` files are byte-identical (sha256 checked): | | `node.exe` inside the tree | `node.exe` in a plain directory | |---|---|---| | v24.22.1 | **FAIL** — `Create private object relative to its admitted parent failed` (Win32 5) | pass | | v24.14.1 | **FAIL** — same error | pass | `b.call('inspect', [])` outside REA reproduces it, so this is not the CLI/MCP wrapper. The tree differs from the passing locations in its ACL and mandatory integrity label (it is a harness sandbox workspace); I did not isolate which property matters. So treat that as a lead for anyone reproducing this, not as an explanation. **Possibly useful to other reporters** - the **executable's directory** can raise this same error, which the current remediation text (temporary-directory writability/DACL) does not hint at; - a one-minute discriminator: copy the identical `node.exe` to a plain directory and rerun before attributing the failure to the package.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#568
No description provided.