Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Environment variable DOTNET_DbgEnableMiniDump=1 doens't work when unhandled exception occurs in worker thread #103000

Closed
KurokiYukari opened this issue Jun 3, 2024 · 8 comments
Assignees
Milestone

Comments

@KurokiYukari
Copy link

Description

I run a .NET application with environment variable DOTNET_DbgEnableMiniDump=1. If an unhandled exception
occurs in main thread, the dump file is generated correctly. But if an unhandled exception occurs in worker thread, no dump file is generated.

Reproduction Steps

using powershell on windows:

  1. dotnet new console
  2. Change Program.cs to
var thread = new Thread(() =>
{
    throw new Exception();
});
thread.Start();
thread.Join();
  1. run $env:DOTNET_DbgEnableMiniDump=1
  2. run dotnet run

Expected behavior

Dump is generated and placed in %LocalAppData%/Temp dir.

Actual behavior

No dump is generated.
Console output:

Unhandled exception. System.Exception: Exception of type 'System.Exception' was thrown.
   at Program.<>c.<<Main>$>b__0_0() in C:\dumptest\Program.cs:line 3

Regression?

No response

Known Workarounds

No response

Configuration

  1. Which version of .NET is the code running on? - 8.0.300
  2. What OS and version, and what distro if applicable? - windows11 23H2
  3. What is the architecture (x64, x86, ARM, ARM64)? - x64
  4. Do you know whether it is specific to that configuration? -no. I have tried .NET 6, but also no dump file is generated.

Other information

No response

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Jun 3, 2024
Copy link
Contributor

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

@hoyosjs hoyosjs self-assigned this Jun 3, 2024
@hoyosjs hoyosjs added this to the 9.0.0 milestone Jun 3, 2024
@tommcdon tommcdon removed the untriaged New issue has not been triaged by the area owner label Jun 3, 2024
@tommcdon tommcdon assigned mikem8361 and unassigned hoyosjs Jun 18, 2024
@hoyosjs
Copy link
Member

hoyosjs commented Jun 20, 2024

threadpool threads don't exhibit this behavior. this works:

await Task.Run(async () =>
{
    await Task.Yield();
    throw new Exception();
});

@KurokiYukari
Copy link
Author

@hoyosjs I tried threadpool. it also doesn't work:

ThreadPool.QueueUserWorkItem(state =>
{
    throw new Exception();
});

Task works because unhandled exceptions that are thrown by user code that is running inside a task are propagated back to the calling thread(main thread)

@mikem8361
Copy link
Member

It works in .NET 9. I did get it to repro on .NET 8. I'm not sure what change went into 9.0 that fixes this yet.

Hello, World!

Unhandled exception. System.Exception: Exception of type 'System.Exception' was thrown.
   at Program.<>c.<<Main>$>b__0_0() in C:\sd\builds\background\Program.cs:line 7
[createdump] Writing minidump with heap for process 14676 to file c:\sd\builds\background\createdump.9.0.0.dmp
[createdump] Dump successfully written in 922ms

@mikem8361
Copy link
Member

It looks like this was fixed as part of the new exception handling support. Not sure what part or where, but on .NET 9 if I disable the new exception handling with set DOTNET_LegacyExceptionHandling=1 dumps are not generated anymore.

@janvorli any thoughts?

@janvorli
Copy link
Member

janvorli commented Jul 27, 2024

I think that we need to call CreateCrashDumpIfEnabled by the end of the following function if we want to make it work with legacy EH:

DefaultCatchHandler(PEXCEPTION_POINTERS pExceptionPointers,

I've tried it and it worked.

@mikem8361
Copy link
Member

Thanks Jan. We need to decide if this fix should go into .NET 9 for the legacy EH and if it should go into .NET 8 servicing?

@tommcdon?

@tommcdon
Copy link
Member

For correctness I think we should try to fix the legacy exception scenario for .NET 9, and consider this
for .NET 8 servicing if we have a customer request.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants