You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When test runs with --blame-crash, on .NET we set environment variables that use internal functionality of .NET to collect a crash dump. When a child process is started these environment variables are inherited and a child process can crash dump itself. This gives us a view of the state that the child process was in, but does not give us any idea about what state the testhost process was in (what test was running).
Maybe we could check on process exit if the process exited with 0 (or maybe there is a specific exit code for process crashed), and initiate a "hang" dump of the testhost process.
Steps to reproduce
Expected behavior
When child process of a test crashes I want to capture the state in testhost.
Actual behavior
I get child-process dump but not testhost dump.
Diagnostic logs
Environment
The text was updated successfully, but these errors were encountered:
Description
When test runs with --blame-crash, on .NET we set environment variables that use internal functionality of .NET to collect a crash dump. When a child process is started these environment variables are inherited and a child process can crash dump itself. This gives us a view of the state that the child process was in, but does not give us any idea about what state the testhost process was in (what test was running).
Maybe we could check on process exit if the process exited with 0 (or maybe there is a specific exit code for process crashed), and initiate a "hang" dump of the testhost process.
Steps to reproduce
Expected behavior
When child process of a test crashes I want to capture the state in testhost.
Actual behavior
I get child-process dump but not testhost dump.
Diagnostic logs
Environment
The text was updated successfully, but these errors were encountered: