runtime: GUI host fails to give unhandled exception message box
Steps to reproduce
- clone https://github.com/rogersachan/NetRadio
- pull the
dotnetcore3
branch - cd into
NetRadio
dotnet restore
dotnet build
- click resulting executable or run it from command line
Expected behavior
it should be showing an unhandled exception messagebox from the GUI host with the following:
Unhandled Exception: System.InvalidCastException: Unable to cast object of type 'System.String' to type 'System.Drawing.Bitmap'.
at NetRadio.Properties.Resources.get_edit() in ...\NetRadio\NetRadio\Properties\Resources.Designer.cs:line 109
at NetRadio.frmMain.InitializeComponent() in ...\NetRadio\NetRadio\frmMain.Designer.cs:line 241
at NetRadio.frmMain..ctor() in ...\NetRadio\NetRadio\frmMain.cs:line 43
at NetRadio.Program.Main() in ...\NetRadio\NetRadio\Program.cs:line 25
thanks to @peterhuene
Actual behavior
Nothing happens
Environment data
C:\Users\sacha>dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 3.0.100-preview5-011568
Commit: b487ff10aa
Runtime Environment:
OS Name: Windows
OS Version: 10.0.18362
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.0.100-preview5-011568\
Host (useful for support):
Version: 3.0.0-preview5-27626-15
Commit: 61f30f5a23
.NET Core SDKs installed:
3.0.100-preview5-011568 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.0-preview5-19227-01 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.0.0-preview5-27626-15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0-preview5-27626-15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 29 (24 by maintainers)
stderr
https://github.com/dotnet/coreclr/issues/15466 has some more discussion on this. We follow the common practices. Other runtimes do not seem to log crashes into system log on Linux either.
I think the reason Steve brought up TraceLogging is that the docs say that the API which CoreCLR uses is “old” and new code should use TraceLogging - see: https://docs.microsoft.com/en-us/windows/desktop/EventLog/about-event-logging (the first Note on the page). But if CoreCLR uses the old APIs I see no reason why the host should do anything different.
EventLog is two orders of magnitudes simpler than either of these. It is like 10 lines of code to write a message into event log. This is what it looks like in CoreCLR: https://github.com/dotnet/coreclr/blob/030a3ea9b8dbeae89c90d34441d4d9a1cf4a7de6/src/utilcode/safewrap.cpp#L251
It would be nice to be consistent and have the same plan for all errors. We started displaying dialog boxes for host errors: https://github.com/dotnet/core-setup/pull/6325/files#diff-d879441c77c53723780bea5613c6056dL319 . If we go with the Windows Event Viewer + stderr redirect plan for the unhandled exceptions, should we switch the host to the same plan?
The Windows GUI apps are always launched in the background when you run them from command prompt. You have to go out of your way to wait for them to finish.
I tried running the repro in this issue and eventvwr shows the error from .NET Runtime:
Changed this to 3.0 because it negatively impacts developer experience
I see, we looked over it in triage and didn’t spot the Core-Setup work. Reopening.