Defer DOTNET_DbgEnableMiniDump error message until dump creation

[Copilot]

Description

The error message "DOTNET_DbgEnableMiniDump is set and the createdump binary does not exist" was being printed during runtime initialization, even when no dump would be created. This prevented setting the environment variable in crossgen scenarios where createdump isn't shipped.

Changes:

• Removed file existence check (stat()) during initialization in PalCreateDumpInitialize() to avoid unnecessary file system operations
• Detect missing createdump binary when execv() returns ENOENT error in CreateCrashDump()
• Print specific error message only when actually attempting to execute the missing binary
• Error now appears only when dump creation is attempted (either via crash or explicit API call), not during initialization

Customer Impact

Customers using crossgen tooling cannot set DOTNET_DbgEnableMiniDump without spurious error messages during builds. This affects debugging workflows in environments where dump generation is conditionally needed.

Regression

No. This is an existing issue with the environment variable handling.

Testing

Built NativeAOT runtime successfully with changes. Verified:

• No initialization errors when createdump missing
• Error message appears when attempting to execute missing createdump binary
• No change in behavior when createdump exists
• No unnecessary file system checks during initialization

Risk

Low. Changes eliminate unnecessary file system checks during initialization and defer error detection to the point where the binary is actually needed (execv call). The actual dump creation logic and all success paths remain unchanged. Error messages now appear only when dumps are actually attempted, preventing spurious warnings during initialization.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Hard to use DOTNET_DbgEnableMiniDump when crossgen is involved somewhere in the build</issue_title>
<issue_description>

runtime/src/coreclr/nativeaot/Runtime/unix/PalCreateDump.cpp

Line 627 in 242f7b2

fprintf(stderr, "DOTNET_DbgEnableMiniDump is set and the createdump binary does not exist: %s\n", program);

This line runs ahead-of-time in the non failure case when setting the DOTNET_DbgEnableMiniDump env var. The Crossgen2 pack currently doesn't ship createdump and therefore this line always raises an error when the env var is set.

This isn't great as it means that you can't set DOTNET_DbgEnableMiniDump if crossgen is involved. I.e. when building the runtime repo.

cc @hoyosjs </issue_description>

<agent_instructions>Instead of having fprintf(stderr, "DOTNET_DbgEnableMiniDump is set and the createdump binary does not exist: %s\n", program); in PalCreateDumpInitialize in PalCreateDump.cpp, we should instead output it in BuildCreateDumpCommandLine inside the if (g_szCreateDumpPath == nullptr || g_ppidarg == nullptr) block</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Hard to use DOTNET_DbgEnableMiniDump when crossgen is involved somewhere in the build #122982

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[steveisok]

@copilot I'd like to keep more in the spirit of the original logic. Rather than store the path regardless if the file exists, bring back the old logic and just move where the error message gets printed.

[Copilot]

@copilot I'd like to keep more in the spirit of the original logic. Rather than store the path regardless if the file exists, bring back the old logic and just move where the error message gets printe...

Updated in 6d701ff. The original logic is now preserved - the path is not stored if the file doesn't exist. The fprintf was simply moved from PalCreateDumpInitialize to BuildCreateDumpCommandLine.

[Copilot]

Pull request overview

This PR defers an error message about a missing createdump binary from runtime initialization to actual dump creation time. This fixes an issue where setting DOTNET_DbgEnableMiniDump in crossgen scenarios would produce spurious error messages even when no dump would be created.

Key Changes:

• Error message moved from PalCreateDumpInitialize() to BuildCreateDumpCommandLine() to only appear when explicitly generating a dump
• Added free(program) to prevent memory leak when createdump binary doesn't exist

[MichalStrehovsky]

An alternative fix could be to update the crossgen2 task (the one that invokes crossgen2) to ignore stderr.

The problem the message is causing is that if MSBuild sees writes to stderr, it will fail the tool invocation task. Otherwise the message is not harmful, it might even be helpful.

[steveisok]

An alternative fix could be to update the crossgen2 task (the one that invokes crossgen2) to ignore stderr.

The problem the message is causing is that if MSBuild sees writes to stderr, it will fail the tool invocation task. Otherwise the message is not harmful, it might even be helpful.

Not a bad suggestion. The value of having a message at startup is that you know you aren't in a good state ahead of time as opposed to realizing it only when the crash occurs.

@hoyosjs - what do you think?

[hoyosjs]

I think such a task invocation can set to ignore stderr - if crossgen never tries to write to err without also returning error that is a good approach for the immediate issue.

As for the createdump issue - I still think the error should only be displayed at the crash point. Startup could've happened long ago and the logs should show this near the crash point. Also, I wonder if it's better to always perform the check at crash time to allow users to drop createdump after deployment as needed.

[dotnet-policy-service]

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

[jkotas]

LGTM!

[steveisok]

@noahfalk @hoyosjs I think we need at least one more approver.

[jkotas]

I think we need at least one more approver.

That's not the blocker. You should see this towards the end of the PR page:

[steveisok]

That's not the blocker. You should see this towards the end of the PR page:

lol thanks. I need to look harder.