CommunityToolkit / Microsoft.Toolkit.Win32

ARCHIVE - This repository contained XAML Islands wrapper controls and tooling for XAML Islands with WinUI 2, see readme for more info about XAML Islands with WinUI 3 and the WindowsAppSDK.
https://aka.ms/windowsappsdk
Other
383 stars 89 forks source link

Catastrophic failure (0x8000FFFF (E_UNEXPECTED)) #210

Closed michael-hawker closed 4 years ago

michael-hawker commented 4 years ago

Originally posted by @jtbrower in https://github.com/windows-toolkit/Microsoft.Toolkit.Win32/issues/197#issuecomment-557963089

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))

at Windows.UI.Xaml.Application.get_Current() at Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplicationExtensions.GetCurrentProvider()

and then that results in 11 occurrences of the following Debug Output print

Exception thrown: 'System.BadImageFormatException' in System.Private.CoreLib.dll

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.

Faulting application name: WpfApp1.exe, version: 1.0.0.0, time stamp: 0x5dbebebd Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.449, time stamp: 0xb90db728 Exception code: 0xc0000005 Fault offset: 0x0000000000a5398d Faulting process id: 0x86dc Faulting application start time: 0x01d5a33105c0345f Faulting application path: D:\examplesNotInGit\WpfApp1\WpfApp1\bin\x64\Release\netcoreapp3.1\WpfApp1.exe Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll Report Id: 04d367c0-803d-4a5c-a9b9-7eaf1a608de1 Faulting package full name: Faulting package-relative application ID:

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 image

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. image

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.

michael-hawker commented 4 years ago

Copied as a new issue from post @jtbrower made. Not sure if related to #197 or not. @marb2000 @ocalvo can we get these issues looked at?

jtbrower commented 4 years ago

WpfApp1.zip

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!

marb2000 commented 4 years ago

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.

ghost commented 4 years ago

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.

ghost commented 4 years ago

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.

ghost commented 4 years ago

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.

ghost commented 4 years ago

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.

ghost commented 4 years ago

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.

ghost commented 4 years ago

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.

marb2000 commented 4 years ago

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>