-
Notifications
You must be signed in to change notification settings - Fork 677
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
App.UnhandledException doesn't catch exceptions from other threads. #5221
Comments
@chrisglein I think the addition context implies that this is a winui3 regression. I'm a bit surprised that Application.UnhandledException could catch off thread exceptions though, I thought this was designed for UI thread exceptions (although the name certainly implies all exceptions) |
Is |
In UWP this was often used to handle (read: log) fatal crashes. |
Still repros on WinAppSDK 8.2. |
Windows.ApplicationModel.Core.CoreApplication.UnhandledErrorDetected and Application.UnhandledException works for me on a WinUI 1.0 .Net 6 application, but only on synchronous operations, they fail to catch even the same kind of exceptions thrown in async methods. |
You might be interested in |
I tried that, but in only triggers when you dont await Tasks, this isn't what I want |
Really need a neat way to be able to catch unhandled exceptions, for a few reasons:
Nothing is more jarring than just having an app disappear. |
Maybe there is a way to do this by replacing the synchronization context? @StephenCleary maybe? |
Seems like they already have a |
This bug has been reported nearly a year ago. |
It really feels like WinUI is enormously underresourced. There are trivial bugs, and real show stopping bugs that have been kicking around for a loooong time. I'm hopeful this is going to change in the near future because I love the platform. |
@StephenCleary how do I catch the exception at the top level in the synchronization context? Wouldn’t I have to re-write and install the synchronization context to do that? |
Even when the exception is caught, it is loosing all important detail such as message and stack trace. See #7160 |
Please can anyone work on this issue? |
Closing this issue, having captured remaining issues |
@gabbybilka Can we see to it that the workarounds noted above are relnoted for the 1.2 release? |
Reopening this issue to cover app event/callback handlers, which are better addressed in WinUI3 code. The only change necessary to C#/WinRT is caching the UnhandledExceptionEventArgs.Exception object. |
Issue has been fixed internally and will be included in v1.3 |
🎉 Handy links: |
Hello @Scottj1s , I can still reproduce it in this scenario: This code requires elevation to open that exe, so if elevation is not configured, process.Start(); will throw an error that will not be handled.
|
I am still experiencing a crash in my Windows MAUI app, that I for the life of me can't get any exception details of.
The app initializes fine, but under certain circumstances, the app crashes when I navigate to a specific page. Either way, each of the above event handlers will write the exception to a txt file. But none of them fire. I am using .NET 8 MAUI, which depend on Microsoft.WindowsAppSDK v1.3.230724000 |
After all this debugging, I have try/catch everywhere related to the crash. Nothing is caught, it still crashes.
Sorry it's in danish, but it's an end-user PC as I am not able to replicate the crash on any of my PCs. |
Thanks, I'll keep that in mind. I finally found a fix. A horizontal CollectionView seems to have been the culprit. What boggles my mind is why it only crashed on some PC's. And why a TeamViewer connection to the PC almost always prevented the crash. And sometimes maximizing the window prevented the crash. Anyhoo, after a few days of trying different things, it finally seems crash-free now. Our next app def. won't be in MAUI. |
In the WinUI Community Call yesterday, Scott illustrated how in 1.5 it's possible to debug the underlying WinUI code and see where the exception is being thrown. He showed an example where the UnhandledException event was not being fired if the exception was related to a 'NaN', whereas an error due to an unexpected negative value did raise that event. It seems that there are still a few places like this in the WinUI code which have yet to be cleaned up. So this kind of silent crash will be possible in any WinUI app, and it's not necessarily MAUI's fault. A desktop app or an Uno app would be equally susceptible ? |
I'm aware it's a WinUI issue. But MAUI hasn't been great all around. So for our next app, we'll probably look at choices outside the .NET ecosystem |
Describe the bug
Unable to catch UnhandledException (at app level) when the exception originates from async Task.
Steps to reproduce the bug
Expected behavior
Would expect the App_UnhandledException to 'handle' this exception.
Screenshots
Version Info
WinUI 0.8.0-preview
Windows 10
NuGet package version:
Microsoft.ProjectReunion (0.8.0-preview)
Microsoft.ProjectReunion.Foundation (0.8.0-preview)
Microsoft.ProjectReunion.WinUI (0.8.0-preview)
Windows app type:
Additional context
GitHub example with 2 'identical' projects, one UWP (WinUI2) and one WinUI3, to show the difference in behavior between the two.
https://github.com/artkat/CrashingApp
The text was updated successfully, but these errors were encountered: