Enable minidump creation directly from application

[ThomasMader]

I am referring to https://github.com/dotnet/runtime/blob/v5.0.8/docs/design/coreclr/botr/xplat-minidump-generation.md .

I tried to use the documented environment variables to activate the minidump creation of the CLR from within my application by doing the following right at the start.

Environment.SetEnvironmentVariable("COMPlus_DbgEnableMiniDump", "1");

I expected that this might not work because I figured the CLR needs that information right at the start and the application start is too late for that.
Nevertheless I asked myself if it would not be possible to provide a way to communicate that back to the CLR somehow.

A working solution is clearly to create some kind of wrapper to set first the environment variables and then start the application.
This is just a bit inconvenient and I thought that if talking back to the CLR is not possible another solution might be to provide the environment variables to the build and the build incorporates that information into the startup process of the CLR or maybe even some kind of initialization callback.

I can see that all of that is probably too much for too little gain but maybe there are better solutions to the problem I am currently not seeing.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

I am referring to https://github.com/dotnet/runtime/blob/v5.0.8/docs/design/coreclr/botr/xplat-minidump-generation.md .

I tried to use the documented environment variables to activate the minidump creation of the CLR from within my application by doing the following right at the start.

Environment.SetEnvironmentVariable("COMPlus_DbgEnableMiniDump", "1");

I expected that this might not work because I figured the CLR needs that information right at the start and the application start is too late for that.
Nevertheless I asked myself if it would not be possible to provide a way to communicate that back to the CLR somehow.

A working solution is clearly to create some kind of wrapper to set first the environment variables and then start the application.
This is just a bit inconvenient and I thought that if talking back to the CLR is not possible another solution might be to provide the environment variables to the build and the build incorporates that information into the startup process of the CLR or maybe even some kind of initialization callback.

I can see that all of that is probably too much for too little gain but maybe there are better solutions to the problem I am currently not seeing.

Author:	ThomasMader
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[hoyosjs]

@dotnet/dotnet-diag I think this is worth - I'd considered making this an event-pipe command at some point, but making it in-proc makes sense too for scenarios where vars are hard to set.

[mikem8361]

@kdubau (Kyle White) from the VS4Mac team also asked about allowing something like this.

[noahfalk]

I think the principle that an app developer can enable the setting for their app independent of the particular environment it runs in is perfectly reasonable. The first approach that comes to mind would be making it a configuration setting in runtimeconfig.json, but managed APIs are also an option if there are scenarios where devs need to decide the behavior dynamically at runtime.

[AraHaan]

I would love to actually be able to call the function in the runtime that allows dumping myself too. Currently it requires manual p/invokes to MiniDumpWriteDump and a few other Windows API functions just to get all the things I need in order to properly do everything that is needed. And the code in particular is an .NET Standard 2.0 library where I would like it to work to create dumps on windows, macos, and linux all from the same code and compilation. I could use reflection to probe for it like I do with GetExceptionPointers as .NET Standard lacks that member directly while it might be loaded into say a runtime that contains that function and so it works and runs it (even though that same codebase also uses source generators btw).

[kdubau]

if there are scenarios where devs need to decide the behavior dynamically at runtime.

This is what I was thinking for our (Visual Studio for Mac) scenario. We want to configure the COMPlus_DbgMiniDumpName dynamically at runtime.

[noahfalk]

Odd, I thought I commented earlier but I no longer see it in the history. Apologies if I am repeating myself...

I would love to actually be able to call the function in the runtime that allows dumping myself too

I think you are asking to create dumps on demand whereas the original request is to configure the runtime for capturing crash dumps if they occur in the future. For your use case I think you could use Microsoft.Diagnostics.NetCore.Client NuGet package with the WriteDump API. Older versions of the runtime only supported this on Linux, but in .NET 5 we added Windows dump support and in .NET 6 we have Mac dump support. I haven't personally tried to make an app create a dump of itself but it seems like it should work.

[AraHaan]

I think you are asking to create dumps on demand whereas the original request is to configure the runtime for capturing crash dumps if they occur in the future. For your use case I think you could use Microsoft.Diagnostics.NetCore.Client NuGet package with the WriteDump API. Older versions of the runtime only supported this on Linux, but in .NET 5 we added Windows dump support and in .NET 6 we have Mac dump support. I haven't personally tried to make an app create a dump of itself but it seems like it should work.

So basically that is safe to reference in the library even when it only targets .NET Standard 2.0 and where it most likely will be running on the .NET 5 or 6 runtime (as in when my library gets referenced in a .NET 5 or 6 project)?

[hoyosjs]

The process hosting the library needs to be NS2.0 or a netcoreapp2.1 or later. However, the target process needs to be 3.1 or above (5.0 if you want windows dumps, and 6.0 for machO native dumps as Noah pointed out) to get the dump support.

[AraHaan]

The process hosting the library needs to be NS2.0 or a netcoreapp2.1 or later. However, the target process needs to be 3.1 or above (5.0 if you want windows dumps, and 6.0 for machO native dumps as Noah pointed out) to get the dump support.

I see, well cant the process hosting the library also be the target process then? This is because the processes that consumes my library then technically would be the hosting process while also being the target process 🤔.

I do admit however, it can theoretically remove all P/Invokes that I currently use in my codebase just by using that though and gain xplat dumping capabilies which is then a free enhancement.

[hoyosjs]

I see, well cant the process hosting the library also be the target process then? This is because the processes that consumes my library then technically would be the hosting process while also being the target process 🤔.

Yes, at that point you have to be 3.1+ in Linux, 5.0+ on windows, and 6.0+ on macOS.

[AraHaan]

As for the process id that api takes in, is it the .NET version of process id or the native process id's (those docs do not explicitly specify which ones)?

[noahfalk]

is it the .NET version of process id or the native process id's

There should be no distinction, ie calling win32 GetCurrentProcessId() returns the same number as Process.GetCurrentProcess().Id, which is the same ID as you'd find in task manager.

[AraHaan]

I thought that property had a breaking change in .NET 5 where it would return the managed process ids instead.

[noahfalk]

I thought that property had a breaking change in .NET 5 where it would return the managed process ids instead.

If there was a change I am unaware of it. I did a quick test on .NET 5 Windows with the managed API and it gave the expected ID.

[ThomasMader]

It's a bit off topic but it is related to this so I mention it just briefly.

An option to restart the program (or start any program) in case the CLR crashed would also be convenient. With the enabled dump option the start of the new process should be done after the dump was created to be able to immediately send a crash report for example.
That could be done from the program itself for all exceptions which are catchable but if the VM would offer that I guess it could be made to work for more exception cases and when doing it from the program itself the dump was not yet created.

[AraHaan]

I implemented a better way with my MiniDump library (now it's xplat thanks to some logic that is xplat from a separate package) which is located at https://github.com/Elskom/Sdk.

Note: Updated code is not pushed to nuget.org yet so you would need to manually copy everything from it over if you want to use it for now.

I had to decide whether to basically do the following back then:

• Use CsWin32 to generate Windows only MiniDumps but do nothing on other platforms.
• Use the xplat nuget package that basically tells the .NET runtime itself to generate a core dump on Non-Windows platforms while it generates a proper minidump on Windows platforms without needing any conditional checks (aka IsWindows(), IsLinux(), IsMac(), etc checks).

So then I decided on the latter without the conditional checks per platform for special dumping logic for each one.