ILSpy

9645 Commits

54 Branches

94 Tags

91 MiB

Branch: fix/lambda-parameter-syntax

Commit Graph

Author	SHA1	Message	Date
Christoph Wille	ff46536269	Await the trace drain when a module rundown fails A collection that fails once the session has been granted - most plausibly the target exiting before the stop command reaches it - left the task copying the trace connection behind. That connection is torn down on the way out, the copy faults, nobody awaits it, and the finalizer hands it to TaskScheduler.UnobservedTaskException, which this app reports as a crash: a second report of a failure the dialog's error bar had already explained correctly, minutes later and detached from the gesture that caused it. The CollectTracing2 fallback walks the same path, so one dying target produced two of them. The teardown order is the substance of the fix. The session connection has to go first, because after the failure nothing else will ever end the read the copy is parked on; the drain second, so that its own failure is observed rather than abandoned; and the half-copied trace last, so nothing is still writing into it when it is dropped. The regression test pins the invariant rather than the symptom, because the symptom is transport-specific: a Windows named pipe reports an aborted overlapped read as cancellation, and a cancelled task is never unobserved, so only the unix transport can produce the crash at all. What holds everywhere is that no drain may still be running once the failure path is done with it. Assisted-by: Claude:claude-opus-5:Claude Code	2 months ago
Christoph Wille	d6bf916398	Fix unreachable-process and selection defects in the process dialog A refused unix socket raises SocketException, which derives from Win32Exception rather than IOException, so it escaped the filter meant to skip one unreachable process and failed the whole concurrent enumeration instead: a machine where any .NET process exits between the port scan and the connect showed an empty list. The classification is now a named predicate covering both transports. Two dialog defects shared a shape - state left behind by a query nobody is waiting for any more. Rebuilding the bound collection on every filter keystroke made the grid drop its selection and write that null back, discarding the assemblies of a process the new filter still matched; and the branch taken when nothing is selected cleared no loading flag, while the query it superseded was no longer allowed to, so the progress bar animated over an empty pane. Relatedly, the two-second command budget expired into a process listed with null metadata, which made a slow machine look like a runtime that answered with nothing; it is longer now, and expiry names the process it gave up on, since the only thing that ever reaches the far end of that budget is a runtime which will never answer. The test gaps are closed the same way: a real dynamic assembly pins the in-memory classification, the managed-only assertion is stated as the property instead of a list of native names to exclude, and the .NET Framework path gets live tests. Those showed that a desktop CLR process mostly reports NGen native images rather than the IL assemblies behind them, which is now recorded as the fidelity gap it is. Assisted-by: Claude:claude-opus-5:Claude Code	2 months ago
Christoph Wille	719e863679	Add "Open from running process" dialog With a modern .NET app the executable in the process list is a native apphost that carries no IL, so the path a user can see is precisely the one a decompiler cannot open - ILSpy itself is an example. Ask the runtime instead: since .NET Core 3.0 every CoreCLR process serves a diagnostics endpoint that names its managed entry assembly and, via an EventPipe rundown, every assembly it has loaded, including ones behind a single-file bundle or with no file at all. The endpoint answers the same way on Windows, Linux and macOS and needs no privileges beyond same-user, which also makes it the only workable route on macOS, where native process introspection is gated by SIP. The protocol and the nettrace container it returns are implemented here rather than taken from Microsoft.Diagnostics.NETCore.Client, so the feature costs no new package reference; the reader is scoped to loader rundown events and steps over everything else by size. The rundown asks for the loader keyword alone: the runtime's default set also collects the JIT and IL-to-native-map rundown, which in a long-running process buries the module list and overruns the session buffer, costing the very events the dialog needs. Windows additionally lists .NET Framework processes, which predate the endpoint and are read from their OS module list instead. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago

Author

SHA1

Message

Date

Christoph Wille

ff46536269

Await the trace drain when a module rundown fails

A collection that fails once the session has been granted - most plausibly
the target exiting before the stop command reaches it - left the task copying
the trace connection behind. That connection is torn down on the way out, the
copy faults, nobody awaits it, and the finalizer hands it to
TaskScheduler.UnobservedTaskException, which this app reports as a crash: a
second report of a failure the dialog's error bar had already explained
correctly, minutes later and detached from the gesture that caused it. The
CollectTracing2 fallback walks the same path, so one dying target produced two
of them.

The teardown order is the substance of the fix. The session connection has to
go first, because after the failure nothing else will ever end the read the
copy is parked on; the drain second, so that its own failure is observed
rather than abandoned; and the half-copied trace last, so nothing is still
writing into it when it is dropped.

The regression test pins the invariant rather than the symptom, because the
symptom is transport-specific: a Windows named pipe reports an aborted
overlapped read as cancellation, and a cancelled task is never unobserved, so
only the unix transport can produce the crash at all. What holds everywhere is
that no drain may still be running once the failure path is done with it.

Assisted-by: Claude:claude-opus-5:Claude Code

2 months ago

Christoph Wille

d6bf916398

Fix unreachable-process and selection defects in the process dialog

A refused unix socket raises SocketException, which derives from
Win32Exception rather than IOException, so it escaped the filter meant to
skip one unreachable process and failed the whole concurrent enumeration
instead: a machine where any .NET process exits between the port scan and
the connect showed an empty list. The classification is now a named
predicate covering both transports.

Two dialog defects shared a shape - state left behind by a query nobody is
waiting for any more. Rebuilding the bound collection on every filter
keystroke made the grid drop its selection and write that null back,
discarding the assemblies of a process the new filter still matched; and the
branch taken when nothing is selected cleared no loading flag, while the
query it superseded was no longer allowed to, so the progress bar animated
over an empty pane. Relatedly, the two-second command budget expired into a
process listed with null metadata, which made a slow machine look like a
runtime that answered with nothing; it is longer now, and expiry names the
process it gave up on, since the only thing that ever reaches the far end of
that budget is a runtime which will never answer.

The test gaps are closed the same way: a real dynamic assembly pins the
in-memory classification, the managed-only assertion is stated as the
property instead of a list of native names to exclude, and the .NET
Framework path gets live tests. Those showed that a desktop CLR process
mostly reports NGen native images rather than the IL assemblies behind them,
which is now recorded as the fidelity gap it is.

Assisted-by: Claude:claude-opus-5:Claude Code

2 months ago

Christoph Wille

719e863679

Add "Open from running process" dialog

With a modern .NET app the executable in the process list is a native
apphost that carries no IL, so the path a user can see is precisely the
one a decompiler cannot open - ILSpy itself is an example. Ask the
runtime instead: since .NET Core 3.0 every CoreCLR process serves a
diagnostics endpoint that names its managed entry assembly and, via an
EventPipe rundown, every assembly it has loaded, including ones behind a
single-file bundle or with no file at all. The endpoint answers the same
way on Windows, Linux and macOS and needs no privileges beyond same-user,
which also makes it the only workable route on macOS, where native
process introspection is gated by SIP.

The protocol and the nettrace container it returns are implemented here
rather than taken from Microsoft.Diagnostics.NETCore.Client, so the
feature costs no new package reference; the reader is scoped to loader
rundown events and steps over everything else by size. The rundown asks
for the loader keyword alone: the runtime's default set also collects the
JIT and IL-to-native-map rundown, which in a long-running process buries
the module list and overruns the session buffer, costing the very events
the dialog needs.

Windows additionally lists .NET Framework processes, which predate the
endpoint and are read from their OS module list instead.

Assisted-by: Claude:claude-fable-5:Claude Code

2 months ago

3 Commits (fix/lambda-parameter-syntax)