New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GUI host fails to give unhandled exception message box #3594
Comments
Note that the unhandled exception is currently expected because MSBuild for Core doesn't support non-string resources such as bitmaps yet (support is being worked on for a future 3.0 preview). |
@dagood this is not a duplicate of the MSBuild issue, rather that issue caused this issue (no error reported on unhandled exception) in the host. Please reopen. |
I see, we looked over it in triage and didn't spot the Core-Setup work. Reopening. |
Changed this to 3.0 because it negatively impacts developer experience |
I am thinking a way to solve this could be to create an anonymous pipe and connect it stderr. Then add a thread to read from the pipe and write to Vitek's message buffer. ASP.NET IIS is using an approach like this. See aspnet/IISIntegration#549 The anonymous pipe has the disadvantage of requiring an additional thread which I am not too excited about. Seems heavy weight for what seems like a development scenario. Maybe only enable it in debug builds? |
As @vitek-karas mentioned in #25279, the stderr can be captured by running with a stderr redirect.
Is documenting this sufficient? This is certainly the simplest and most robust solution. |
The third option is to attempt to catch the unhandled exception and log it when using a WInExe. |
I think the winexe host should be consistent with the .NET Framework UX of logging the unhandled exception with the Windows Event Log, since users will probably check there first to see why the application didn't "activate". |
I tried running the repro in this issue and eventvwr shows the error from .NET Runtime:
|
Event log is also working for the dotnet/coreclr#25279 repro |
Catching the unhandled exception would disable the event log, unless we go through extra hurdles. Given this is triggered by an unhandled exception, I do not think the pipe solution would work. Process would likely end with error in the pipe. Error is showing in the Windows Event Viewer. I am beginning to think the best solution is to just document this. |
It also appears that when the GUI bit is set, the resultant app does not set |
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. |
The dialog boxes are only enabled for GUI apphost. I guess it is also worth noting that the dotnet host also reports the error fine on stderr. So even a gui app will report its error on stderr if run with the dotnet host. |
Yes. I meant that either all fatal errors from .NET Core GUI apps should be dialog boxes; or none of them should be dialog boxes. I do not think it makes sense to have the dialog boxes for some, but not others.
We do not recommend to run GUI apps this way. It may not even work in some cases when the GUI parts depend on the manifest in the .exe. |
Looks like the errors reported in hostpolicy are not using ETW, but only the dialog. Seems like ETW is preferred. We may not have time to fix this for preview7. |
ETW is tracing that you need to configure and turn on upfront. It is meant to be used for in-depth diagnostic, by more advanced users like developers. EventLog is "always on" and much simpler. It is meant to be used for basic diagnostic, by less advanced users like sys admins. EventLog is built on top ETW as a dedicated channel. Events written to EventLog are available via ETW as well. EventLog is the appropriate mechanism for fatal errors. .NET Framework logged fatal errors to EventLog. .NET Core 1.0 did not do it, but we have received feedback about it and added it back: https://github.com/dotnet/coreclr/issues/14037, https://github.com/dotnet/coreclr/issues/16735 |
I tend to agree that Event Logs is probably the better solution here. Making the runtime show dialogs is something I would like to avoid adding to the runtime itself. But doing this from the host is pretty tricky (given how runtime handles unhandles exceptions). Also if logging to EventLog matches .NET Framework behavior, that adds additional appeal to it. |
@jkotas From an event provider perspective it is not immediately obvious to me how it is simpler. From reading the docs it seems:
|
Found this quote:
here https://blogs.msdn.microsoft.com/dcook/2015/09/24/tracelogging-background/ |
I completely agree with that when trouble-shooting apps outside VS. However I do not agree with that in an F5-Debugging scenario. In that case I'd expect to be told why my app didn't run. |
Agree. It is the case today for unhandled exceptions. |
@dotMorten The debugger should be notified about unhandled exception and show the appropriate UI for that. |
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 |
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. |
Consensus...
Fixed in dotnet/core-setup#6921 by removing the message box in case of host errors and using Windows Event Log to report errors. |
Using async IO there would be no need for a thread. |
EventLog is windows only. What is the story for Unix? |
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. |
Steps to reproduce
dotnetcore3
branchNetRadio
dotnet restore
dotnet build
Expected behavior
it should be showing an unhandled exception messagebox from the GUI host with the following:
thanks to @peterhuene
Actual behavior
Nothing happens
Environment data
related to dotnet/msbuild#2221
The text was updated successfully, but these errors were encountered: