-
Notifications
You must be signed in to change notification settings - Fork 89
Catastrophic failure (0x8000FFFF (E_UNEXPECTED)) #210
Comments
I just realized that I forgot to attach the solution that I was using, please find it here. I was experimenting with quite a few work-around attempts so don't assume that the current state of the solution mimics all attempts that I tried. Thanks! |
It's known issue, that it's on the backlog. I will assigned to me, although I won't be the one who fix it. |
This issue has been marked as "needs attention 👋" due to no activity for 7 days. Please triage the issue so the fix can be established. |
2 similar comments
This issue has been marked as "needs attention 👋" due to no activity for 7 days. Please triage the issue so the fix can be established. |
This issue has been marked as "needs attention 👋" due to no activity for 7 days. Please triage the issue so the fix can be established. |
This issue has been marked as "needs attention 👋" due to no activity for 7 days. Please triage the issue so the fix can be established. |
1 similar comment
This issue has been marked as "needs attention 👋" due to no activity for 7 days. Please triage the issue so the fix can be established. |
This issue has been marked as "needs attention 👋" due to no activity for 15 days. Please triage the issue so the fix can be established. |
Per my investigations, this is caused because the XAML Application object is instantiated after trying to load son Xaml content. To fix that create your own Main for the WPF app and instantiate the XamlApplication object first public static class Program
{
[STAThread]
public static void Main()
{
using (new UwpApp1.App())
{
var app = new WpfApp1.App();
app.InitializeComponent();
app.Run();
}
}
Remember to set the StartupObject in the WPF csproj file to specify your own Main class: <PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<UseWPF>true</UseWPF>
<Platform>x64</Platform>
<PlatformTarget>x64</PlatformTarget>
<Platforms>AnyCPU;x64</Platforms>
<StartupObject>WpfApp1.Program</StartupObject>
</PropertyGroup> |
Originally posted by @jtbrower in #197 (comment)
I was moments away from posting this bug report over on the WinUI teams github page, but after a bit more research it appears it belongs over here. Is there a work-around for this? Out of curiosity what is the cause?
Describe the bug
Following the example at Host UWP in WPF APP I ran the application and although I was able to write on the Ink Canvas and the Calendar Control worked sometimes I am seeing an initial catastrophic failure with the following stack trace
Catastrophic failure (0x8000FFFF (E_UNEXPECTED))
and then that results in 11 occurrences of the following Debug Output print
Surprisingly to me, none of those exceptions cause the app to crash. However I can easily force the crash by trying to scroll the calendar through the months using the mouse scroll. About 50% of the time the calendar stops rendering the UI and then crashes so quickly that I cannot catch the exception with Domain, Dispatcher or TaskScheduler exception handlers. Not being able to catch the crash really makes me feel uneasy. The Windows Event Log contains the following.
Steps to reproduce the bug
Following either the tutorial located at Host UWP in WPF APP or running the attached project you will see the exceptions print on the console. You can also place a breakpoint in the first chance exception handler I installed to break on the initial Catastrophic Failure.
Although I assume that these initial errors are the ultimate cause of the crash, you can cause the crash by trying to scroll quickly through the calendar. It seems to be a timing related issue. About 50% of the time the calendar will not render months beyond the current month displayed. That's when you can crash the app with ease.
Expected behavior
Other than hoping the application doesn't crash, it would be nice if the crash was tossed up the stack so that I know about it before the application goes down without any sign or error.
Screenshots
Errors on Console
Calendar View Just before Crash
In this screenshot you can see how the calendar is having trouble rendering. When this happens if you attempt to scroll further into the future (I have been using my mouse scroll) then the application will go down without any popup or chance to log the exception.
Version Info
My app is a direct consumer of the Microsoft.Toolkit.Wpf.UI.Controls 6.0.0 package, however it is an indirect consumer of Windows.UI.Xaml.dll, version: 10.0.18362.449 that appears to cause the crash. (Hopefully you are the proper team to report this to, I apologize if you are not).
NuGet package version:
I was using Microsoft.Toolkit.Wpf.UI.Controls 6.0.0, but noticed the tutorial was speaking of pre-release versions so I tried pre-7.1 and that also caused the issue. I tried running as both a 32bit and 64bit app for both assemblies involved in the solution.
Windows 10 version 18362
Device form factor Desktop (I did not test others)
Additional context
I am running this application on a laptop through Visual Studio Pro 2019 Preview 16.4.0 Preview 6.0 (which also crashes frequently). The laptop has an NVidia RTX5000, Xeon E-2286M with 128GB ECC. I spent a good 4 hours trying to figure out if I personally did something wrong, but I don't think I overlooked anything. The bad image format gives me the feeling that the wrong assemblies are being loaded.
The text was updated successfully, but these errors were encountered: