Add on-demand in-proc crash report generation.

[lateralusX]

Summary

Adds an on-demand entry point to the in-proc crash reporter so a report can be generated programmatically while the runtime is still running, independent of the fatal-signal path. This is the reporting mechanism that a user-registered native
fatal-error handler (proposed in #129543) can call to produce a crash report.

Motivation

The in-proc crash reporter can currently only run from the PAL fatal-signal dispatcher. The fatal-error-handler proposal (#129543) needs a way to invoke just the reporting mechanism on demand, formatting the report to a caller-supplied sink,
without the watchdog/lifecycle/file-management that the signal path performs.

What's in this PR

• On-demand report API — InProcCrashReportCreateReport(outputFormat, signal, context, outputCallback, callbackContext). Emits the same report as the signal path but streams the selected format (Json or Log) to a caller-supplied callback, with no watchdog or file output. Re-runnable; yields to any report already in flight.
• Shared in-flight guard — the signal-path and on-demand CreateReport paths are made mutually exclusive over the shared signal-safe writers, module table, and process-global thread-suspension machinery via a single m_reportInFlight guard. The on-demand path releases the guard on completion; the signal path never does (the process is terminating).
• Init / services split — reporter bring-up is split into CrashReportInitialize (VM callbacks only, so on-demand reports are possible) and InProcCrashReportInitializeServices (env-gated watchdog + lifecycle + PAL dispatcher registration). This lets the reporter be initialized from either the runtime startup path or a future fatal-error-handler setup path, without arming the signal-path crash-dump behavior.
• Output sink refactor — SignalSafeConsoleWriter and SignalSafeJsonWriter gain a small copyable sink abstraction so a single caller-supplied callback shape can drive either writer (platform console / drop-all / caller callback).
• Stack-overflow classification fix — the in-proc SO stack trace is now captured only on the real stack-overflow path. Previously a FailFast (which funnels through the same fatal-error callstack logger) populated the SO-trace latch, causing an on-demand report to misclassify a FailFast as a StackOverflow. Gating capture to the real-SO path makes the latch authoritative for classification.

Behavior notes

• No behavior changes when crash reporting is disabled: startup allocates nothing.
• No behavior changes when crash reporting is enabled: allocates and configure signal-based in-proc crash reporter.

Testing

• In-proc crash reporter lacks automatic tests, on-demand can be tested through Implement ExceptionHandling.SetFatalErrorHandler #129543 tests when integrated.
• Manually ran FailFast and StackOverflow paths on Android arm64 emulator.
• All tests in https://github.com/mdh1418/runtime/blob/inproc_crashreport_tests/src/tests/FunctionalTests/Android/Device_Emulator/InProcCrashReport/OVERVIEW.md pass on Android arm64 emulator.

Follow-ups

• Wiring the on-demand entry point into the fatal-error handler once Implement ExceptionHandling.SetFatalErrorHandler #129543 lands.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends CoreCLR’s in-proc crash reporter to support on-demand report generation (JSON or compact log) via a caller-supplied callback, and refactors initialization so the reporter can be brought up without arming the fatal-signal crash-dump services.

Changes:

• Adds an on-demand reporting entry point (InProcCrashReportCreateReport) and splits reporter init into “VM callbacks” vs “services + PAL registration”.
• Refactors the signal-safe JSON/console writers to use small copyable “output sink” abstractions (platform sink / drop-all / caller callback).
• Fixes stack-overflow classification by only capturing the “SO trace latch” on the real SO path (not on other fatal paths like FailFast).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/vm/eepolicy.cpp	Gates stack-overflow trace capture behind an explicit “capture SO trace” flag to avoid misclassification.
src/coreclr/vm/crashreportstackwalker.h	Adds CrashReportInitialize() declaration to support init without services.
src/coreclr/vm/crashreportstackwalker.cpp	Implements CrashReportInitialize() and updates CrashReportConfigure() to start services separately.
src/coreclr/debug/crashreport/signalsafejsonwriter.h	Introduces SignalSafeJsonOutputSink and replaces Init with SetOutputSink.
src/coreclr/debug/crashreport/signalsafejsonwriter.cpp	Implements sink plumbing + drop-all sink for JSON writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.h	Introduces SignalSafeConsoleOutputSink and sink selection APIs for console writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.cpp	Implements platform/drop-all sinks and sink-driven newline/flush behavior.
src/coreclr/debug/crashreport/inproccrashreporter.h	Adds on-demand API, output callback type/format enum, and splits settings into VM vs services.
src/coreclr/debug/crashreport/inproccrashreporter.cpp	Implements on-demand report generation and shared in-flight guard, plus services init split.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[mdh1418]

Overall looks good to me, just one concern.

[lateralusX]

Summary

Adds an on-demand entry point to the in-proc crash reporter so a report can be generated programmatically while the runtime is still running, independent of the fatal-signal path. This is the reporting mechanism that a user-registered native
fatal-error handler (proposed in #129543) can call to produce a crash report.

Motivation

The in-proc crash reporter can currently only run from the PAL fatal-signal dispatcher. The fatal-error-handler proposal (#129543) needs a way to invoke just the reporting mechanism on demand, formatting the report to a caller-supplied sink,
without the watchdog/lifecycle/file-management that the signal path performs.

What's in this PR

• On-demand report API — InProcCrashReportCreateReport(outputFormat, signal, context, outputCallback, callbackContext). Emits the same report as the signal path but streams the selected format (Json or Log) to a caller-supplied callback, with no watchdog or file output. Re-runnable; yields to any report already in flight.
• Shared in-flight guard — the signal-path and on-demand CreateReport paths are made mutually exclusive over the shared signal-safe writers, module table, and process-global thread-suspension machinery via a single m_reportInFlight guard. The on-demand path releases the guard on completion; the signal path never does (the process is terminating).
• Init / services split — reporter bring-up is split into CrashReportInitialize (VM callbacks only, so on-demand reports are possible) and InProcCrashReportInitializeServices (env-gated watchdog + lifecycle + PAL dispatcher registration). This lets the reporter be initialized from either the runtime startup path or a future fatal-error-handler setup path, without arming the signal-path crash-dump behavior.
• Output sink refactor — SignalSafeConsoleWriter and SignalSafeJsonWriter gain a small copyable sink abstraction so a single caller-supplied callback shape can drive either writer (platform console / drop-all / caller callback).
• Stack-overflow classification fix — the in-proc SO stack trace is now captured only on the real stack-overflow path. Previously a FailFast (which funnels through the same fatal-error callstack logger) populated the SO-trace latch, causing an on-demand report to misclassify a FailFast as a StackOverflow. Gating capture to the real-SO path makes the latch authoritative for classification.

Behavior notes

• No behavior changes when crash reporting is disabled: startup allocates nothing.
• No behavior changes when crash reporting is enabled: allocates and configure signal-based in-proc crash reporter.

Testing

• In-proc crash reporter lacks automatic tests, on-demand can be tested through Implement ExceptionHandling.SetFatalErrorHandler #129543 tests when integrated.
• Manually ran FailFast and StackOverflow paths on Android arm64 emulator.
• All tests in https://github.com/mdh1418/runtime/blob/inproc_crashreport_tests/src/tests/FunctionalTests/Android/Device_Emulator/InProcCrashReport/OVERVIEW.md pass on Android arm64 emulator.

Follow-ups

• Wiring the on-demand entry point into the fatal-error handler once Implement ExceptionHandling.SetFatalErrorHandler #129543 lands.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends CoreCLR’s in-proc crash reporter to support on-demand report generation (JSON or compact log) via a caller-supplied callback, and refactors initialization so the reporter can be brought up without arming the fatal-signal crash-dump services.

Changes:

• Adds an on-demand reporting entry point (InProcCrashReportCreateReport) and splits reporter init into “VM callbacks” vs “services + PAL registration”.
• Refactors the signal-safe JSON/console writers to use small copyable “output sink” abstractions (platform sink / drop-all / caller callback).
• Fixes stack-overflow classification by only capturing the “SO trace latch” on the real SO path (not on other fatal paths like FailFast).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/vm/eepolicy.cpp	Gates stack-overflow trace capture behind an explicit “capture SO trace” flag to avoid misclassification.
src/coreclr/vm/crashreportstackwalker.h	Adds CrashReportInitialize() declaration to support init without services.
src/coreclr/vm/crashreportstackwalker.cpp	Implements CrashReportInitialize() and updates CrashReportConfigure() to start services separately.
src/coreclr/debug/crashreport/signalsafejsonwriter.h	Introduces SignalSafeJsonOutputSink and replaces Init with SetOutputSink.
src/coreclr/debug/crashreport/signalsafejsonwriter.cpp	Implements sink plumbing + drop-all sink for JSON writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.h	Introduces SignalSafeConsoleOutputSink and sink selection APIs for console writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.cpp	Implements platform/drop-all sinks and sink-driven newline/flush behavior.
src/coreclr/debug/crashreport/inproccrashreporter.h	Adds on-demand API, output callback type/format enum, and splits settings into VM vs services.
src/coreclr/debug/crashreport/inproccrashreporter.cpp	Implements on-demand report generation and shared in-flight guard, plus services init split.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[mdh1418]

Overall looks good to me, just one concern.

[lateralusX]

Summary

Adds an on-demand entry point to the in-proc crash reporter so a report can be generated programmatically while the runtime is still running, independent of the fatal-signal path. This is the reporting mechanism that a user-registered native
fatal-error handler (proposed in #129543) can call to produce a crash report.

Motivation

The in-proc crash reporter can currently only run from the PAL fatal-signal dispatcher. The fatal-error-handler proposal (#129543) needs a way to invoke just the reporting mechanism on demand, formatting the report to a caller-supplied sink,
without the watchdog/lifecycle/file-management that the signal path performs.

What's in this PR

• On-demand report API — InProcCrashReportCreateReport(outputFormat, signal, context, outputCallback, callbackContext). Emits the same report as the signal path but streams the selected format (Json or Log) to a caller-supplied callback, with no watchdog or file output. Re-runnable; yields to any report already in flight.
• Shared in-flight guard — the signal-path and on-demand CreateReport paths are made mutually exclusive over the shared signal-safe writers, module table, and process-global thread-suspension machinery via a single m_reportInFlight guard. The on-demand path releases the guard on completion; the signal path never does (the process is terminating).
• Init / services split — reporter bring-up is split into CrashReportInitialize (VM callbacks only, so on-demand reports are possible) and InProcCrashReportInitializeServices (env-gated watchdog + lifecycle + PAL dispatcher registration). This lets the reporter be initialized from either the runtime startup path or a future fatal-error-handler setup path, without arming the signal-path crash-dump behavior.
• Output sink refactor — SignalSafeConsoleWriter and SignalSafeJsonWriter gain a small copyable sink abstraction so a single caller-supplied callback shape can drive either writer (platform console / drop-all / caller callback).
• Stack-overflow classification fix — the in-proc SO stack trace is now captured only on the real stack-overflow path. Previously a FailFast (which funnels through the same fatal-error callstack logger) populated the SO-trace latch, causing an on-demand report to misclassify a FailFast as a StackOverflow. Gating capture to the real-SO path makes the latch authoritative for classification.

Behavior notes

• No behavior changes when crash reporting is disabled: startup allocates nothing.
• No behavior changes when crash reporting is enabled: allocates and configure signal-based in-proc crash reporter.

Testing

• In-proc crash reporter lacks automatic tests, on-demand can be tested through Implement ExceptionHandling.SetFatalErrorHandler #129543 tests when integrated.
• Manually ran FailFast and StackOverflow paths on Android arm64 emulator.
• All tests in https://github.com/mdh1418/runtime/blob/inproc_crashreport_tests/src/tests/FunctionalTests/Android/Device_Emulator/InProcCrashReport/OVERVIEW.md pass on Android arm64 emulator.

Follow-ups

• Wiring the on-demand entry point into the fatal-error handler once Implement ExceptionHandling.SetFatalErrorHandler #129543 lands.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends CoreCLR’s in-proc crash reporter to support on-demand report generation (JSON or compact log) via a caller-supplied callback, and refactors initialization so the reporter can be brought up without arming the fatal-signal crash-dump services.

Changes:

• Adds an on-demand reporting entry point (InProcCrashReportCreateReport) and splits reporter init into “VM callbacks” vs “services + PAL registration”.
• Refactors the signal-safe JSON/console writers to use small copyable “output sink” abstractions (platform sink / drop-all / caller callback).
• Fixes stack-overflow classification by only capturing the “SO trace latch” on the real SO path (not on other fatal paths like FailFast).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/vm/eepolicy.cpp	Gates stack-overflow trace capture behind an explicit “capture SO trace” flag to avoid misclassification.
src/coreclr/vm/crashreportstackwalker.h	Adds CrashReportInitialize() declaration to support init without services.
src/coreclr/vm/crashreportstackwalker.cpp	Implements CrashReportInitialize() and updates CrashReportConfigure() to start services separately.
src/coreclr/debug/crashreport/signalsafejsonwriter.h	Introduces SignalSafeJsonOutputSink and replaces Init with SetOutputSink.
src/coreclr/debug/crashreport/signalsafejsonwriter.cpp	Implements sink plumbing + drop-all sink for JSON writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.h	Introduces SignalSafeConsoleOutputSink and sink selection APIs for console writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.cpp	Implements platform/drop-all sinks and sink-driven newline/flush behavior.
src/coreclr/debug/crashreport/inproccrashreporter.h	Adds on-demand API, output callback type/format enum, and splits settings into VM vs services.
src/coreclr/debug/crashreport/inproccrashreporter.cpp	Implements on-demand report generation and shared in-flight guard, plus services init split.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[mdh1418]

Overall looks good to me, just one concern.

[lateralusX]

Summary

Adds an on-demand entry point to the in-proc crash reporter so a report can be generated programmatically while the runtime is still running, independent of the fatal-signal path. This is the reporting mechanism that a user-registered native
fatal-error handler (proposed in #129543) can call to produce a crash report.

Motivation

The in-proc crash reporter can currently only run from the PAL fatal-signal dispatcher. The fatal-error-handler proposal (#129543) needs a way to invoke just the reporting mechanism on demand, formatting the report to a caller-supplied sink,
without the watchdog/lifecycle/file-management that the signal path performs.

What's in this PR

• On-demand report API — InProcCrashReportCreateReport(outputFormat, signal, context, outputCallback, callbackContext). Emits the same report as the signal path but streams the selected format (Json or Log) to a caller-supplied callback, with no watchdog or file output. Re-runnable; yields to any report already in flight.
• Shared in-flight guard — the signal-path and on-demand CreateReport paths are made mutually exclusive over the shared signal-safe writers, module table, and process-global thread-suspension machinery via a single m_reportInFlight guard. The on-demand path releases the guard on completion; the signal path never does (the process is terminating).
• Init / services split — reporter bring-up is split into CrashReportInitialize (VM callbacks only, so on-demand reports are possible) and InProcCrashReportInitializeServices (env-gated watchdog + lifecycle + PAL dispatcher registration). This lets the reporter be initialized from either the runtime startup path or a future fatal-error-handler setup path, without arming the signal-path crash-dump behavior.
• Output sink refactor — SignalSafeConsoleWriter and SignalSafeJsonWriter gain a small copyable sink abstraction so a single caller-supplied callback shape can drive either writer (platform console / drop-all / caller callback).
• Stack-overflow classification fix — the in-proc SO stack trace is now captured only on the real stack-overflow path. Previously a FailFast (which funnels through the same fatal-error callstack logger) populated the SO-trace latch, causing an on-demand report to misclassify a FailFast as a StackOverflow. Gating capture to the real-SO path makes the latch authoritative for classification.

Behavior notes

• No behavior changes when crash reporting is disabled: startup allocates nothing.
• No behavior changes when crash reporting is enabled: allocates and configure signal-based in-proc crash reporter.

Testing

• In-proc crash reporter lacks automatic tests, on-demand can be tested through Implement ExceptionHandling.SetFatalErrorHandler #129543 tests when integrated.
• Manually ran FailFast and StackOverflow paths on Android arm64 emulator.
• All tests in https://github.com/mdh1418/runtime/blob/inproc_crashreport_tests/src/tests/FunctionalTests/Android/Device_Emulator/InProcCrashReport/OVERVIEW.md pass on Android arm64 emulator.

Follow-ups

• Wiring the on-demand entry point into the fatal-error handler once Implement ExceptionHandling.SetFatalErrorHandler #129543 lands.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends CoreCLR’s in-proc crash reporter to support on-demand report generation (JSON or compact log) via a caller-supplied callback, and refactors initialization so the reporter can be brought up without arming the fatal-signal crash-dump services.

Changes:

• Adds an on-demand reporting entry point (InProcCrashReportCreateReport) and splits reporter init into “VM callbacks” vs “services + PAL registration”.
• Refactors the signal-safe JSON/console writers to use small copyable “output sink” abstractions (platform sink / drop-all / caller callback).
• Fixes stack-overflow classification by only capturing the “SO trace latch” on the real SO path (not on other fatal paths like FailFast).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/vm/eepolicy.cpp	Gates stack-overflow trace capture behind an explicit “capture SO trace” flag to avoid misclassification.
src/coreclr/vm/crashreportstackwalker.h	Adds CrashReportInitialize() declaration to support init without services.
src/coreclr/vm/crashreportstackwalker.cpp	Implements CrashReportInitialize() and updates CrashReportConfigure() to start services separately.
src/coreclr/debug/crashreport/signalsafejsonwriter.h	Introduces SignalSafeJsonOutputSink and replaces Init with SetOutputSink.
src/coreclr/debug/crashreport/signalsafejsonwriter.cpp	Implements sink plumbing + drop-all sink for JSON writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.h	Introduces SignalSafeConsoleOutputSink and sink selection APIs for console writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.cpp	Implements platform/drop-all sinks and sink-driven newline/flush behavior.
src/coreclr/debug/crashreport/inproccrashreporter.h	Adds on-demand API, output callback type/format enum, and splits settings into VM vs services.
src/coreclr/debug/crashreport/inproccrashreporter.cpp	Implements on-demand report generation and shared in-flight guard, plus services init split.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[mdh1418]

Overall looks good to me, just one concern.

[lateralusX]

Summary

Adds an on-demand entry point to the in-proc crash reporter so a report can be generated programmatically while the runtime is still running, independent of the fatal-signal path. This is the reporting mechanism that a user-registered native
fatal-error handler (proposed in #129543) can call to produce a crash report.

Motivation

The in-proc crash reporter can currently only run from the PAL fatal-signal dispatcher. The fatal-error-handler proposal (#129543) needs a way to invoke just the reporting mechanism on demand, formatting the report to a caller-supplied sink,
without the watchdog/lifecycle/file-management that the signal path performs.

What's in this PR

• On-demand report API — InProcCrashReportCreateReport(outputFormat, signal, context, outputCallback, callbackContext). Emits the same report as the signal path but streams the selected format (Json or Log) to a caller-supplied callback, with no watchdog or file output. Re-runnable; yields to any report already in flight.
• Shared in-flight guard — the signal-path and on-demand CreateReport paths are made mutually exclusive over the shared signal-safe writers, module table, and process-global thread-suspension machinery via a single m_reportInFlight guard. The on-demand path releases the guard on completion; the signal path never does (the process is terminating).
• Init / services split — reporter bring-up is split into CrashReportInitialize (VM callbacks only, so on-demand reports are possible) and InProcCrashReportInitializeServices (env-gated watchdog + lifecycle + PAL dispatcher registration). This lets the reporter be initialized from either the runtime startup path or a future fatal-error-handler setup path, without arming the signal-path crash-dump behavior.
• Output sink refactor — SignalSafeConsoleWriter and SignalSafeJsonWriter gain a small copyable sink abstraction so a single caller-supplied callback shape can drive either writer (platform console / drop-all / caller callback).
• Stack-overflow classification fix — the in-proc SO stack trace is now captured only on the real stack-overflow path. Previously a FailFast (which funnels through the same fatal-error callstack logger) populated the SO-trace latch, causing an on-demand report to misclassify a FailFast as a StackOverflow. Gating capture to the real-SO path makes the latch authoritative for classification.

Behavior notes

• No behavior changes when crash reporting is disabled: startup allocates nothing.
• No behavior changes when crash reporting is enabled: allocates and configure signal-based in-proc crash reporter.

Testing

• In-proc crash reporter lacks automatic tests, on-demand can be tested through Implement ExceptionHandling.SetFatalErrorHandler #129543 tests when integrated.
• Manually ran FailFast and StackOverflow paths on Android arm64 emulator.
• All tests in https://github.com/mdh1418/runtime/blob/inproc_crashreport_tests/src/tests/FunctionalTests/Android/Device_Emulator/InProcCrashReport/OVERVIEW.md pass on Android arm64 emulator.

Follow-ups

• Wiring the on-demand entry point into the fatal-error handler once Implement ExceptionHandling.SetFatalErrorHandler #129543 lands.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends CoreCLR’s in-proc crash reporter to support on-demand report generation (JSON or compact log) via a caller-supplied callback, and refactors initialization so the reporter can be brought up without arming the fatal-signal crash-dump services.

Changes:

• Adds an on-demand reporting entry point (InProcCrashReportCreateReport) and splits reporter init into “VM callbacks” vs “services + PAL registration”.
• Refactors the signal-safe JSON/console writers to use small copyable “output sink” abstractions (platform sink / drop-all / caller callback).
• Fixes stack-overflow classification by only capturing the “SO trace latch” on the real SO path (not on other fatal paths like FailFast).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/vm/eepolicy.cpp	Gates stack-overflow trace capture behind an explicit “capture SO trace” flag to avoid misclassification.
src/coreclr/vm/crashreportstackwalker.h	Adds CrashReportInitialize() declaration to support init without services.
src/coreclr/vm/crashreportstackwalker.cpp	Implements CrashReportInitialize() and updates CrashReportConfigure() to start services separately.
src/coreclr/debug/crashreport/signalsafejsonwriter.h	Introduces SignalSafeJsonOutputSink and replaces Init with SetOutputSink.
src/coreclr/debug/crashreport/signalsafejsonwriter.cpp	Implements sink plumbing + drop-all sink for JSON writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.h	Introduces SignalSafeConsoleOutputSink and sink selection APIs for console writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.cpp	Implements platform/drop-all sinks and sink-driven newline/flush behavior.
src/coreclr/debug/crashreport/inproccrashreporter.h	Adds on-demand API, output callback type/format enum, and splits settings into VM vs services.
src/coreclr/debug/crashreport/inproccrashreporter.cpp	Implements on-demand report generation and shared in-flight guard, plus services init split.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[mdh1418]

Overall looks good to me, just one concern.

[lateralusX]

Summary

Adds an on-demand entry point to the in-proc crash reporter so a report can be generated programmatically while the runtime is still running, independent of the fatal-signal path. This is the reporting mechanism that a user-registered native
fatal-error handler (proposed in #129543) can call to produce a crash report.

Motivation

The in-proc crash reporter can currently only run from the PAL fatal-signal dispatcher. The fatal-error-handler proposal (#129543) needs a way to invoke just the reporting mechanism on demand, formatting the report to a caller-supplied sink,
without the watchdog/lifecycle/file-management that the signal path performs.

What's in this PR

• On-demand report API — InProcCrashReportCreateReport(outputFormat, signal, context, outputCallback, callbackContext). Emits the same report as the signal path but streams the selected format (Json or Log) to a caller-supplied callback, with no watchdog or file output. Re-runnable; yields to any report already in flight.
• Shared in-flight guard — the signal-path and on-demand CreateReport paths are made mutually exclusive over the shared signal-safe writers, module table, and process-global thread-suspension machinery via a single m_reportInFlight guard. The on-demand path releases the guard on completion; the signal path never does (the process is terminating).
• Init / services split — reporter bring-up is split into CrashReportInitialize (VM callbacks only, so on-demand reports are possible) and InProcCrashReportInitializeServices (env-gated watchdog + lifecycle + PAL dispatcher registration). This lets the reporter be initialized from either the runtime startup path or a future fatal-error-handler setup path, without arming the signal-path crash-dump behavior.
• Output sink refactor — SignalSafeConsoleWriter and SignalSafeJsonWriter gain a small copyable sink abstraction so a single caller-supplied callback shape can drive either writer (platform console / drop-all / caller callback).
• Stack-overflow classification fix — the in-proc SO stack trace is now captured only on the real stack-overflow path. Previously a FailFast (which funnels through the same fatal-error callstack logger) populated the SO-trace latch, causing an on-demand report to misclassify a FailFast as a StackOverflow. Gating capture to the real-SO path makes the latch authoritative for classification.

Behavior notes

• No behavior changes when crash reporting is disabled: startup allocates nothing.
• No behavior changes when crash reporting is enabled: allocates and configure signal-based in-proc crash reporter.

Testing

• In-proc crash reporter lacks automatic tests, on-demand can be tested through Implement ExceptionHandling.SetFatalErrorHandler #129543 tests when integrated.
• Manually ran FailFast and StackOverflow paths on Android arm64 emulator.
• All tests in https://github.com/mdh1418/runtime/blob/inproc_crashreport_tests/src/tests/FunctionalTests/Android/Device_Emulator/InProcCrashReport/OVERVIEW.md pass on Android arm64 emulator.

Follow-ups

• Wiring the on-demand entry point into the fatal-error handler once Implement ExceptionHandling.SetFatalErrorHandler #129543 lands.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends CoreCLR’s in-proc crash reporter to support on-demand report generation (JSON or compact log) via a caller-supplied callback, and refactors initialization so the reporter can be brought up without arming the fatal-signal crash-dump services.

Changes:

• Adds an on-demand reporting entry point (InProcCrashReportCreateReport) and splits reporter init into “VM callbacks” vs “services + PAL registration”.
• Refactors the signal-safe JSON/console writers to use small copyable “output sink” abstractions (platform sink / drop-all / caller callback).
• Fixes stack-overflow classification by only capturing the “SO trace latch” on the real SO path (not on other fatal paths like FailFast).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/vm/eepolicy.cpp	Gates stack-overflow trace capture behind an explicit “capture SO trace” flag to avoid misclassification.
src/coreclr/vm/crashreportstackwalker.h	Adds CrashReportInitialize() declaration to support init without services.
src/coreclr/vm/crashreportstackwalker.cpp	Implements CrashReportInitialize() and updates CrashReportConfigure() to start services separately.
src/coreclr/debug/crashreport/signalsafejsonwriter.h	Introduces SignalSafeJsonOutputSink and replaces Init with SetOutputSink.
src/coreclr/debug/crashreport/signalsafejsonwriter.cpp	Implements sink plumbing + drop-all sink for JSON writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.h	Introduces SignalSafeConsoleOutputSink and sink selection APIs for console writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.cpp	Implements platform/drop-all sinks and sink-driven newline/flush behavior.
src/coreclr/debug/crashreport/inproccrashreporter.h	Adds on-demand API, output callback type/format enum, and splits settings into VM vs services.
src/coreclr/debug/crashreport/inproccrashreporter.cpp	Implements on-demand report generation and shared in-flight guard, plus services init split.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[mdh1418]

Overall looks good to me, just one concern.

[lateralusX]

Summary

Adds an on-demand entry point to the in-proc crash reporter so a report can be generated programmatically while the runtime is still running, independent of the fatal-signal path. This is the reporting mechanism that a user-registered native
fatal-error handler (proposed in #129543) can call to produce a crash report.

Motivation

The in-proc crash reporter can currently only run from the PAL fatal-signal dispatcher. The fatal-error-handler proposal (#129543) needs a way to invoke just the reporting mechanism on demand, formatting the report to a caller-supplied sink,
without the watchdog/lifecycle/file-management that the signal path performs.

What's in this PR

• On-demand report API — InProcCrashReportCreateReport(outputFormat, signal, context, outputCallback, callbackContext). Emits the same report as the signal path but streams the selected format (Json or Log) to a caller-supplied callback, with no watchdog or file output. Re-runnable; yields to any report already in flight.
• Shared in-flight guard — the signal-path and on-demand CreateReport paths are made mutually exclusive over the shared signal-safe writers, module table, and process-global thread-suspension machinery via a single m_reportInFlight guard. The on-demand path releases the guard on completion; the signal path never does (the process is terminating).
• Init / services split — reporter bring-up is split into CrashReportInitialize (VM callbacks only, so on-demand reports are possible) and InProcCrashReportInitializeServices (env-gated watchdog + lifecycle + PAL dispatcher registration). This lets the reporter be initialized from either the runtime startup path or a future fatal-error-handler setup path, without arming the signal-path crash-dump behavior.
• Output sink refactor — SignalSafeConsoleWriter and SignalSafeJsonWriter gain a small copyable sink abstraction so a single caller-supplied callback shape can drive either writer (platform console / drop-all / caller callback).
• Stack-overflow classification fix — the in-proc SO stack trace is now captured only on the real stack-overflow path. Previously a FailFast (which funnels through the same fatal-error callstack logger) populated the SO-trace latch, causing an on-demand report to misclassify a FailFast as a StackOverflow. Gating capture to the real-SO path makes the latch authoritative for classification.

Behavior notes

• No behavior changes when crash reporting is disabled: startup allocates nothing.
• No behavior changes when crash reporting is enabled: allocates and configure signal-based in-proc crash reporter.

Testing

• In-proc crash reporter lacks automatic tests, on-demand can be tested through Implement ExceptionHandling.SetFatalErrorHandler #129543 tests when integrated.
• Manually ran FailFast and StackOverflow paths on Android arm64 emulator.
• All tests in https://github.com/mdh1418/runtime/blob/inproc_crashreport_tests/src/tests/FunctionalTests/Android/Device_Emulator/InProcCrashReport/OVERVIEW.md pass on Android arm64 emulator.

Follow-ups

• Wiring the on-demand entry point into the fatal-error handler once Implement ExceptionHandling.SetFatalErrorHandler #129543 lands.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends CoreCLR’s in-proc crash reporter to support on-demand report generation (JSON or compact log) via a caller-supplied callback, and refactors initialization so the reporter can be brought up without arming the fatal-signal crash-dump services.

Changes:

• Adds an on-demand reporting entry point (InProcCrashReportCreateReport) and splits reporter init into “VM callbacks” vs “services + PAL registration”.
• Refactors the signal-safe JSON/console writers to use small copyable “output sink” abstractions (platform sink / drop-all / caller callback).
• Fixes stack-overflow classification by only capturing the “SO trace latch” on the real SO path (not on other fatal paths like FailFast).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/vm/eepolicy.cpp	Gates stack-overflow trace capture behind an explicit “capture SO trace” flag to avoid misclassification.
src/coreclr/vm/crashreportstackwalker.h	Adds CrashReportInitialize() declaration to support init without services.
src/coreclr/vm/crashreportstackwalker.cpp	Implements CrashReportInitialize() and updates CrashReportConfigure() to start services separately.
src/coreclr/debug/crashreport/signalsafejsonwriter.h	Introduces SignalSafeJsonOutputSink and replaces Init with SetOutputSink.
src/coreclr/debug/crashreport/signalsafejsonwriter.cpp	Implements sink plumbing + drop-all sink for JSON writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.h	Introduces SignalSafeConsoleOutputSink and sink selection APIs for console writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.cpp	Implements platform/drop-all sinks and sink-driven newline/flush behavior.
src/coreclr/debug/crashreport/inproccrashreporter.h	Adds on-demand API, output callback type/format enum, and splits settings into VM vs services.
src/coreclr/debug/crashreport/inproccrashreporter.cpp	Implements on-demand report generation and shared in-flight guard, plus services init split.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[mdh1418]

Overall looks good to me, just one concern.

[lateralusX]

Summary

Adds an on-demand entry point to the in-proc crash reporter so a report can be generated programmatically while the runtime is still running, independent of the fatal-signal path. This is the reporting mechanism that a user-registered native
fatal-error handler (proposed in #129543) can call to produce a crash report.

Motivation

The in-proc crash reporter can currently only run from the PAL fatal-signal dispatcher. The fatal-error-handler proposal (#129543) needs a way to invoke just the reporting mechanism on demand, formatting the report to a caller-supplied sink,
without the watchdog/lifecycle/file-management that the signal path performs.

What's in this PR

• On-demand report API — InProcCrashReportCreateReport(outputFormat, signal, context, outputCallback, callbackContext). Emits the same report as the signal path but streams the selected format (Json or Log) to a caller-supplied callback, with no watchdog or file output. Re-runnable; yields to any report already in flight.
• Shared in-flight guard — the signal-path and on-demand CreateReport paths are made mutually exclusive over the shared signal-safe writers, module table, and process-global thread-suspension machinery via a single m_reportInFlight guard. The on-demand path releases the guard on completion; the signal path never does (the process is terminating).
• Init / services split — reporter bring-up is split into CrashReportInitialize (VM callbacks only, so on-demand reports are possible) and InProcCrashReportInitializeServices (env-gated watchdog + lifecycle + PAL dispatcher registration). This lets the reporter be initialized from either the runtime startup path or a future fatal-error-handler setup path, without arming the signal-path crash-dump behavior.
• Output sink refactor — SignalSafeConsoleWriter and SignalSafeJsonWriter gain a small copyable sink abstraction so a single caller-supplied callback shape can drive either writer (platform console / drop-all / caller callback).
• Stack-overflow classification fix — the in-proc SO stack trace is now captured only on the real stack-overflow path. Previously a FailFast (which funnels through the same fatal-error callstack logger) populated the SO-trace latch, causing an on-demand report to misclassify a FailFast as a StackOverflow. Gating capture to the real-SO path makes the latch authoritative for classification.

Behavior notes

• No behavior changes when crash reporting is disabled: startup allocates nothing.
• No behavior changes when crash reporting is enabled: allocates and configure signal-based in-proc crash reporter.

Testing

• In-proc crash reporter lacks automatic tests, on-demand can be tested through Implement ExceptionHandling.SetFatalErrorHandler #129543 tests when integrated.
• Manually ran FailFast and StackOverflow paths on Android arm64 emulator.
• All tests in https://github.com/mdh1418/runtime/blob/inproc_crashreport_tests/src/tests/FunctionalTests/Android/Device_Emulator/InProcCrashReport/OVERVIEW.md pass on Android arm64 emulator.

Follow-ups

• Wiring the on-demand entry point into the fatal-error handler once Implement ExceptionHandling.SetFatalErrorHandler #129543 lands.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends CoreCLR’s in-proc crash reporter to support on-demand report generation (JSON or compact log) via a caller-supplied callback, and refactors initialization so the reporter can be brought up without arming the fatal-signal crash-dump services.

Changes:

• Adds an on-demand reporting entry point (InProcCrashReportCreateReport) and splits reporter init into “VM callbacks” vs “services + PAL registration”.
• Refactors the signal-safe JSON/console writers to use small copyable “output sink” abstractions (platform sink / drop-all / caller callback).
• Fixes stack-overflow classification by only capturing the “SO trace latch” on the real SO path (not on other fatal paths like FailFast).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/vm/eepolicy.cpp	Gates stack-overflow trace capture behind an explicit “capture SO trace” flag to avoid misclassification.
src/coreclr/vm/crashreportstackwalker.h	Adds CrashReportInitialize() declaration to support init without services.
src/coreclr/vm/crashreportstackwalker.cpp	Implements CrashReportInitialize() and updates CrashReportConfigure() to start services separately.
src/coreclr/debug/crashreport/signalsafejsonwriter.h	Introduces SignalSafeJsonOutputSink and replaces Init with SetOutputSink.
src/coreclr/debug/crashreport/signalsafejsonwriter.cpp	Implements sink plumbing + drop-all sink for JSON writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.h	Introduces SignalSafeConsoleOutputSink and sink selection APIs for console writer.
src/coreclr/debug/crashreport/signalsafeconsolewriter.cpp	Implements platform/drop-all sinks and sink-driven newline/flush behavior.
src/coreclr/debug/crashreport/inproccrashreporter.h	Adds on-demand API, output callback type/format enum, and splits settings into VM vs services.
src/coreclr/debug/crashreport/inproccrashreporter.cpp	Implements on-demand report generation and shared in-flight guard, plus services init split.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[mdh1418]

Overall looks good to me, just one concern.