morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #5146] [Bug] inspect-managed-members returns unavailable on a 2042-type .NET app and offers no way to list its types #3164

New issue

Closed

opened 2026-10-31 00:37:23 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:37:23 +00:00

Owner

Originally created by @elricfd on GitHub (Oct 19, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5146

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

rea inspect-managed-members on a large .NET Framework app (Mixed In Key 11, MixedInKey.exe, 16.8 MB, 2042 TypeDefs, 14783 MethodDefs) exits 0 after about 1.4 s with an Evidence envelope where types, fields, methods and member_refs are all empty and:

"coverage": {"state":"unavailable","issues":[{"code":"resource-limit","scope":"metadata.representation","offset":null,"detail":"Managed metadata exceeds the 67108864 byte representation budget"}]},
"limitations": ["The CLI metadata could not be admitted; managed member inspection is unavailable."]

inspect-managed-artifact succeeds on the same file but returns only table row counts, not type names. The MCP tool inspect_managed_members with detail:"summary" and no type_names returns the same unavailable result. So REA offers no way to learn which --type / type_names values exist. I obtained the names with an external metadata parser; four --type batches (359 to 593 names each) then all returned coverage.state: complete, at 13 to 19 MB of JSON per batch.

Reproduction

rea inspect-managed-members "<MIK dir>\MixedInKey.exe" --json -> unavailable as above (ran; reproduced on the second run).
rea inspect-managed-artifact "<MIK dir>\MixedInKey.exe" --json -> complete; table_row_counts only.
MCP inspect_managed_members {"path": "...", "detail": "summary"} -> same resource-limit (coverage.examined: 0).
rea inspect-managed-members ... --type <name> per batch -> complete.

Vendor binary not attached (commercial software). SHA-256 b014a00e6f6b80ed9313f68ad3da8f42c2de38f9111582e62145cec63c7da843.

Expected behavior

When whole-assembly inspection exceeds the budget, the caller can still enumerate the assembly's TypeDefs (full name, token, member counts) without decoding bodies, for example from inspect-managed-artifact or from a degraded inspect-managed-members that keeps types and marks the other collections unknown. Documentation (docs/managed-code-analysis.md, "Member summary and retained member rows") points to type_names plus summary/paging, which presupposes the caller already knows the names.

Impact and scope

Observed: whole-assembly member analysis of this app is impossible through REA alone, and the workaround needs an external parser. Other assemblies were not tested. The CLI also exits 0 for coverage.state: unavailable; I did not check whether that is intended.

REA version

6.7.0 (source commit 22ddd82014)

Runtime and platform

Node v24.15.0 (repo .nvmrc pins 24.18.0); Windows 11 Pro 10.0.26300 x64; managed static provider only

Target and artifact context

PE32+ x86_64, .NET Framework 4.x, IL-only, 16,816,128 bytes. Row counts: TypeDef 2042, MethodDef 14783, Field 7016, MemberRef 6829, CustomAttribute 6055.

Interface

CLI

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Commands and result as in "Observed behavior" and "Reproduction", all run locally. Not established: whether this assembly legitimately exceeds 64 MiB or whether the charging still over-counts. The four batch outputs total about 70 MB of JSON with the assembly-wide member_refs (about 4 MB) repeated in each, so exceeding the limit is plausible but unproven.

Analysis or suspected cause

Source-derived: the limit is MAX_METADATA_REPRESENTATION_BYTES = 64 * 1024 * 1024 in src/dotnet/ManagedDecodeBudget.ts:7. Earlier false positives with the same message were fixed in #1801 (fixed by #1768) and #3449 (#3487, #3491), so a residual over-count is worth ruling out. Hypothesis (untested): charge and return types first so a budget failure in later collections still leaves the type list.

Originally created by @elricfd on GitHub (Oct 19, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5146 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior `rea inspect-managed-members` on a large .NET Framework app (Mixed In Key 11, `MixedInKey.exe`, 16.8 MB, 2042 TypeDefs, 14783 MethodDefs) exits 0 after about 1.4 s with an Evidence envelope where `types`, `fields`, `methods` and `member_refs` are all empty and: ```json "coverage": {"state":"unavailable","issues":[{"code":"resource-limit","scope":"metadata.representation","offset":null,"detail":"Managed metadata exceeds the 67108864 byte representation budget"}]}, "limitations": ["The CLI metadata could not be admitted; managed member inspection is unavailable."] ``` `inspect-managed-artifact` succeeds on the same file but returns only table row counts, not type names. The MCP tool `inspect_managed_members` with `detail:"summary"` and no `type_names` returns the same unavailable result. So REA offers no way to learn which `--type` / `type_names` values exist. I obtained the names with an external metadata parser; four `--type` batches (359 to 593 names each) then all returned `coverage.state: complete`, at 13 to 19 MB of JSON per batch. ### Reproduction 1. `rea inspect-managed-members "<MIK dir>\MixedInKey.exe" --json` -> unavailable as above (ran; reproduced on the second run). 2. `rea inspect-managed-artifact "<MIK dir>\MixedInKey.exe" --json` -> complete; `table_row_counts` only. 3. MCP `inspect_managed_members {"path": "...", "detail": "summary"}` -> same `resource-limit` (`coverage.examined: 0`). 4. `rea inspect-managed-members ... --type <name>` per batch -> complete. Vendor binary not attached (commercial software). SHA-256 `b014a00e6f6b80ed9313f68ad3da8f42c2de38f9111582e62145cec63c7da843`. ### Expected behavior When whole-assembly inspection exceeds the budget, the caller can still enumerate the assembly's TypeDefs (full name, token, member counts) without decoding bodies, for example from `inspect-managed-artifact` or from a degraded `inspect-managed-members` that keeps `types` and marks the other collections unknown. Documentation (docs/managed-code-analysis.md, "Member summary and retained member rows") points to `type_names` plus summary/paging, which presupposes the caller already knows the names. ### Impact and scope Observed: whole-assembly member analysis of this app is impossible through REA alone, and the workaround needs an external parser. Other assemblies were not tested. The CLI also exits 0 for `coverage.state: unavailable`; I did not check whether that is intended. ### REA version 6.7.0 (source commit 22ddd820143b0ce455756b24acf60ed251286622) ### Runtime and platform Node v24.15.0 (repo .nvmrc pins 24.18.0); Windows 11 Pro 10.0.26300 x64; managed static provider only ### Target and artifact context PE32+ x86_64, .NET Framework 4.x, IL-only, 16,816,128 bytes. Row counts: TypeDef 2042, MethodDef 14783, Field 7016, MemberRef 6829, CustomAttribute 6055. ### Interface CLI ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence Commands and result as in "Observed behavior" and "Reproduction", all run locally. Not established: whether this assembly legitimately exceeds 64 MiB or whether the charging still over-counts. The four batch outputs total about 70 MB of JSON with the assembly-wide `member_refs` (about 4 MB) repeated in each, so exceeding the limit is plausible but unproven. ### Analysis or suspected cause Source-derived: the limit is `MAX_METADATA_REPRESENTATION_BYTES = 64 * 1024 * 1024` in `src/dotnet/ManagedDecodeBudget.ts:7`. Earlier false positives with the same message were fixed in #1801 (fixed by #1768) and #3449 (#3487, #3491), so a residual over-count is worth ruling out. Hypothesis (untested): charge and return `types` first so a budget failure in later collections still leaves the type list.

bsakaguchi closed this issue

2026-10-31 00:37:23 +00:00

bsakaguchi commented

2026-10-31 00:37:24 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 19, 2026):

This is a genuine dead-end: docs point to type_names + summary, but the default path exceeds the budget before telling you which type_names exist — the caller can only guess. Charging and returning types first is a sensible minimal fix, and it fits the existing degraded-coverage model: keep types populated, mark methods/fields/member_refs as unknown, and surface the resource-limit issue alongside.

Two smaller notes: (1) worth confirming whether the 64MiB charge still over-counts on this assembly — the earlier false positives fixed in #1768/#3487 suggest the accounting has drifted before, and a quick per-table charge audit might reveal a cheaper fix than reordering; (2) the CLI exiting 0 on coverage.state:unavailable is worth documenting as intended or flipping to a non-zero code, since scripts that check exit codes would otherwise silently treat 'could not analyze' as success.

@XinwangTao commented on GitHub (Oct 19, 2026): This is a genuine dead-end: docs point to type_names + summary, but the default path exceeds the budget before telling you which type_names exist — the caller can only guess. Charging and returning types first is a sensible minimal fix, and it fits the existing degraded-coverage model: keep types populated, mark methods/fields/member_refs as unknown, and surface the resource-limit issue alongside. Two smaller notes: (1) worth confirming whether the 64MiB charge still over-counts on this assembly — the earlier false positives fixed in #1768/#3487 suggest the accounting has drifted before, and a quick per-table charge audit might reveal a cheaper fix than reordering; (2) the CLI exiting 0 on coverage.state:unavailable is worth documenting as intended or flipping to a non-zero code, since scripts that check exit codes would otherwise silently treat 'could not analyze' as success.

bsakaguchi commented

2026-10-31 00:37:24 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 23, 2026):

Thanks for landing #5312 — retaining type discovery after the member-limit budget hit is exactly the degraded-coverage behavior this report asked for. Keeping the type list available while methods/fields/member_refs are marked unknown turns this from a dead end into a usable path. I'll re-run against the MixedInKey sample when I get a chance to confirm the degraded output.

@XinwangTao commented on GitHub (Oct 23, 2026): Thanks for landing #5312 — retaining type discovery after the member-limit budget hit is exactly the degraded-coverage behavior this report asked for. Keeping the type list available while methods/fields/member_refs are marked unknown turns this from a dead end into a usable path. I'll re-run against the MixedInKey sample when I get a chance to confirm the degraded output.

bsakaguchi referenced this issue

2026-10-31 01:08:20 +00:00

[PR #3227] [CLOSED] fix(ci): track compiler inputs and module scopes #5657

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#3164

No description provided.

Rows
Columns