Buffer overrun on unhandled exception in nativeaot

[OwnageIsMagic]

Description

Reproduction Steps

dotnet new console --aot
echo 'throw new Exception();' > Program.cs
dotnet publish -o out
out/*.exe

Expected behavior

Regular crash dialog.

Actual behavior

The system detected an overrun of a stack-based buffer in this application. This overrun could potentially....

Regression?

yes

Known Workarounds

No response

Configuration

.NET SDK:
 Version:           9.0.100-preview.5.24307.3
 Commit:            35b2c21ea6
 Workload version:  9.0.100-manifests.6407b7e4
 MSBuild version:   17.11.0-preview-24279-02+b963c24ef

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64

Other information

No response

[dotnet-policy-service]

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

[jkotas]

The error message is bogus. There is no actual buffer overflow. The bogus error is unfortunate side-effect of integrating native AOT with WER.

cc @leculver

[OwnageIsMagic]

on net8 it was saying

---------------------------
qq.exe - System Information
---------------------------
Unknown Hard Error
---------------------------
OK   
---------------------------

---

Does it means that I can now collect dumps via HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps ?

[jkotas]

Does it means that I can now collect dumps via HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps ?

That was always possible.

FWIW, this behavior was introduced by https://github.com/dotnet/runtime/pull/88273/files#diff-74f27b3e1e48d38ee293254564011283909305d863d1f1d3b9375900f92e7b0eR31

I am not sure why you see different behavior between .NET 8 and .NET 9. Are you running the final .NET 8 bits (no preview)?

[OwnageIsMagic]

https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps

Applications that do their own custom crash reporting, including .NET applications, are not supported by this feature.

I actually never tried and always resorted to some others ad hoc methods. In retro thinking since .net app crashes were logged to event log, probably it works like this for ages. May be this remark left from pre net4 era.

Uff, it's net 8 preview 5.

Anyway message like this is not expected and I was thinking some time to report it via MSRC.

[jkotas]

May be this remark left from pre net4 era.

Looks like it: MicrosoftDocs/win32#1868

[jkotas]

Anyway message like this is not expected and I was thinking some time to report it via MSRC.

Yes, I agree that this error code and message is super confusing. I am thinking we may want to introduce a build switch to disable the enhanced minidump generation so that apps have a way to avoid the confusing error messages.

[steveberdy]

+1 on this. I've been compiling a ton of AOT apps since .NET 7 and I'm surprised that I just got this issue my first time. I tested in .NET 8, .NET 9, and the latest dogfooded version of the .NET 10 sdk, all with the same results.
Are there any changes I can make besides removing uncaught exceptions?

[steveberdy]

Update: found a workaround that requires minimal changes. Just register a delegate with the System.AppDomain.CurrentDomain.UnhandledException event to log the error and exit the application.