search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.66k stars 4.57k forks source link

Buffer overrun on unhandled exception in nativeaot #103718

Open OwnageIsMagic opened 1 month ago

OwnageIsMagic commented 1 month ago

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[bot] commented 1 month ago

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

jkotas commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

May be this remark left from pre net4 era.

Looks like it: https://github.com/MicrosoftDocs/win32/pull/1868

jkotas commented 1 month ago

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.