[GH-ISSUE #1832] [Bug] inspect-managed-members marks generic, array, fnptr, and custom-modifier member signatures unsupported #617

Closed
opened 2026-10-15 18:26:40 +00:00 by bsakaguchi · 0 comments
Owner

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

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

inspect-managed-members (and the MCP inspect_managed_members tool) reports well-formed ECMA-335 member signatures as signature.parse_status: "unsupported" with issue: "unsupported element type 0x15", and likewise for 0x14 (ARRAY), 0x1b (FNPTR), 0x1f/0x20 (CMOD_REQD/CMOD_OPT), and 0x16 (TYPEDBYREF). The member row is still listed with its raw signature, but return_type/parameter_types/field_type stay null and coverage.state drops to partial even though every other row of the artifact decodes.

On the .NET Framework 4 GAC System.Runtime.Caching.dll:

  • methods: 474/493 decoded, 19 unsupported
  • fields: 391/403 decoded, 12 unsupported
  • coverage.state: "partial"
  • method 0x06000001 -> "unsupported element type 0x15" (its 7-byte signature 20 00 15 12 71 01 0e decodes to return_type: "class:113<string>")

The same class of failure appears in any framework assembly that uses generics in members. Across a sweep of 187 assemblies (.NET 7 shared framework 7.0.20 + in-box .NET Framework 4.8 GAC assemblies), 9,472 member signatures are blocked by exactly these element types:

  • methods: 6,383 x 0x15, 36 x 0x1f, 9 x 0x1b, 2 x 0x14, 2 x 0x16
  • fields: 2,755 x 0x15, 243 x 0x1f, 33 x 0x1b, 9 x 0x14

Reproduction

  1. Check out 43dafb5abe (rea-agents 6.4.0) and run npm ci.
  2. Run node scripts/rea.mjs inspect-managed-members "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Runtime.Caching\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.Caching.dll" --format json.
  3. Observe coverage.state: "partial" and the unsupported methods/fields above; 0x06000001.signature.return_type is null with issue: "unsupported element type 0x15".

Any .NET 7 runtime assembly with generic members reproduces the same class (for example System.Collections.Immutable.dll methods 0x06000020, 0x06000140).

Expected behavior

The standard element types should decode into the existing type-string form (GENERICINST -> class:113<string> / valuetype:10<var:0,mvar:1>, ARRAY -> i4[2...5], FNPTR -> fnptr[...](...), CMOD_REQD/CMOD_OPT -> modreq:.../modopt:..., TYPEDBYREF -> typedbyref) while the raw_length/raw_sha256 pairing stays unchanged. Only genuinely malformed blobs (or element types ECMA-335 does not assign in signature blobs) should keep unsupported/malformed. The sample above should report coverage.state: "complete", 493/493 methods, 403/403 fields, and 0x06000001.return_type: "class:113<string>".

Impact and scope

  • Affected: anyone using REA to inspect ordinary .NET / Unity assemblies whose members use generics (Dictionary<K,V>, ImmutableArray<T>, ...) or the other listed element types. The signature is the only place REA discloses a member's decoded type in inspect-managed-members / inspect_managed_members, and the compare workflows lose exact-signature matching for those members.
  • With GENERICINST alone, 6,383 methods and 2,755 fields were blocked across the 187-assembly sweep; the full set of listed element types blocks 9,472 members.
  • coverage.state: "partial" misreports a fully analysable artifact as partially covered.
  • Not affected: metadata row counts, CIL decoding, and raw signature digests. Nothing here executes or loads target code.

REA version

rea-agents 6.4.0 (source revision 43dafb5abe)

Runtime and platform

Node 22.22.2; Windows 11 (win32 x64); no provider involved

Target and artifact context

PE/CLI managed assemblies: .NET Framework 4 GAC (System.Runtime.Caching.dll) and .NET 7 shared-framework assemblies; no native runtime involved.

Interface

CLI

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

$ node scripts/rea.mjs inspect-managed-members "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Runtime.Caching\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.Caching.dll" --format json
methods: 474/493 decoded (19 unsupported)
fields:  391/403 decoded (12 unsupported)
coverage: { "state": "partial", "issues": [] }
method 0x06000001: { "parse_status": "unsupported", "issue": "unsupported element type 0x15" }

Typed outcome or recovery expected

Members with these element types should keep parse_status: "decoded" and disclose their types; unsupported should remain only for element types that the metadata format does not assign in member signatures.

Analysis or suspected cause

Source-derived: readTypeSignature in src/dotnet/ManagedMemberInspectorCore.ts decodes a fixed subset (named primitives, CLASS/VALUETYPE coded tokens, VAR/MVAR, and the SZARRAY/PTR/BYREF suffixes) and raises unsupported-signature for every other element type. An existing unit test recorded ARRAY (0x14) as "valid, but not decoded here", which marks the support gap as a known limitation rather than an intentional rejection.

Additional context

Decoded values for these element types can be cross-checked against Microsoft System.Reflection.Metadata decoding of the same blobs; a regression test using the System.Runtime.Caching method 0x06000001 signature is straightforward.

Originally created by @JasonBuildAI on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1832 ### 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 `inspect-managed-members` (and the MCP `inspect_managed_members` tool) reports well-formed ECMA-335 member signatures as `signature.parse_status: "unsupported"` with `issue: "unsupported element type 0x15"`, and likewise for 0x14 (ARRAY), 0x1b (FNPTR), 0x1f/0x20 (CMOD_REQD/CMOD_OPT), and 0x16 (TYPEDBYREF). The member row is still listed with its raw signature, but `return_type`/`parameter_types`/`field_type` stay null and `coverage.state` drops to `partial` even though every other row of the artifact decodes. On the .NET Framework 4 GAC `System.Runtime.Caching.dll`: - methods: 474/493 decoded, 19 unsupported - fields: 391/403 decoded, 12 unsupported - `coverage.state: "partial"` - method `0x06000001` -> `"unsupported element type 0x15"` (its 7-byte signature `20 00 15 12 71 01 0e` decodes to `return_type: "class:113<string>"`) The same class of failure appears in any framework assembly that uses generics in members. Across a sweep of 187 assemblies (.NET 7 shared framework 7.0.20 + in-box .NET Framework 4.8 GAC assemblies), 9,472 member signatures are blocked by exactly these element types: - methods: 6,383 x 0x15, 36 x 0x1f, 9 x 0x1b, 2 x 0x14, 2 x 0x16 - fields: 2,755 x 0x15, 243 x 0x1f, 33 x 0x1b, 9 x 0x14 ### Reproduction 1. Check out 43dafb5abe60ee21be4f6a6b6de482cd7a5bab0a (rea-agents 6.4.0) and run `npm ci`. 2. Run `node scripts/rea.mjs inspect-managed-members "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Runtime.Caching\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.Caching.dll" --format json`. 3. Observe `coverage.state: "partial"` and the unsupported methods/fields above; `0x06000001.signature.return_type` is null with `issue: "unsupported element type 0x15"`. Any .NET 7 runtime assembly with generic members reproduces the same class (for example `System.Collections.Immutable.dll` methods `0x06000020`, `0x06000140`). ### Expected behavior The standard element types should decode into the existing type-string form (GENERICINST -> `class:113<string>` / `valuetype:10<var:0,mvar:1>`, ARRAY -> `i4[2...5]`, FNPTR -> `fnptr[...](...)`, CMOD_REQD/CMOD_OPT -> `modreq:...`/`modopt:...`, TYPEDBYREF -> `typedbyref`) while the `raw_length`/`raw_sha256` pairing stays unchanged. Only genuinely malformed blobs (or element types ECMA-335 does not assign in signature blobs) should keep `unsupported`/`malformed`. The sample above should report `coverage.state: "complete"`, 493/493 methods, 403/403 fields, and `0x06000001.return_type: "class:113<string>"`. ### Impact and scope - Affected: anyone using REA to inspect ordinary .NET / Unity assemblies whose members use generics (`Dictionary<K,V>`, `ImmutableArray<T>`, ...) or the other listed element types. The signature is the only place REA discloses a member's decoded type in `inspect-managed-members` / `inspect_managed_members`, and the compare workflows lose exact-signature matching for those members. - With GENERICINST alone, 6,383 methods and 2,755 fields were blocked across the 187-assembly sweep; the full set of listed element types blocks 9,472 members. - `coverage.state: "partial"` misreports a fully analysable artifact as partially covered. - Not affected: metadata row counts, CIL decoding, and raw signature digests. Nothing here executes or loads target code. ### REA version rea-agents 6.4.0 (source revision 43dafb5abe60ee21be4f6a6b6de482cd7a5bab0a) ### Runtime and platform Node 22.22.2; Windows 11 (win32 x64); no provider involved ### Target and artifact context PE/CLI managed assemblies: .NET Framework 4 GAC (`System.Runtime.Caching.dll`) and .NET 7 shared-framework assemblies; no native runtime involved. ### Interface CLI ### Earliest failure stage Artifact or evidence registration ### Relevant output or evidence ``` $ node scripts/rea.mjs inspect-managed-members "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Runtime.Caching\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.Caching.dll" --format json methods: 474/493 decoded (19 unsupported) fields: 391/403 decoded (12 unsupported) coverage: { "state": "partial", "issues": [] } method 0x06000001: { "parse_status": "unsupported", "issue": "unsupported element type 0x15" } ``` ### Typed outcome or recovery expected Members with these element types should keep `parse_status: "decoded"` and disclose their types; `unsupported` should remain only for element types that the metadata format does not assign in member signatures. ### Analysis or suspected cause Source-derived: `readTypeSignature` in `src/dotnet/ManagedMemberInspectorCore.ts` decodes a fixed subset (named primitives, CLASS/VALUETYPE coded tokens, VAR/MVAR, and the SZARRAY/PTR/BYREF suffixes) and raises `unsupported-signature` for every other element type. An existing unit test recorded ARRAY (0x14) as "valid, but not decoded here", which marks the support gap as a known limitation rather than an intentional rejection. ### Additional context Decoded values for these element types can be cross-checked against Microsoft `System.Reflection.Metadata` decoding of the same blobs; a regression test using the `System.Runtime.Caching` method 0x06000001 signature is straightforward.
bsakaguchi 2026-10-15 18:26:40 +00:00
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#617
No description provided.