Stowed 8007007E (0xc000027b) on some systems upon instantiating Microsoft.UI.Xaml.Window

[KimihikoAkayasaki]

Describe the bug

I'm writing a Windows Desktop app using Windows App SDK with WinUI
(For additional context: you can see the repo here, project website here)
and some users reported some weird crashing issues, where the app would
just crash upon startup, not leaving any notice or additional crash logs.

This happens only on some machines (sadly, I cannot reproduce it myself)
but generally everything seems to be working fine, except for these few cases.
Tried to reproduce on a clean machine running Windows 19041, 19044 (Hyper-V)
but really couldn't get it to crash, neither did it send any debug break signals.

So, into the issue troubleshooting, running with WinDbg Preview attached,
all cases seem to be sharing the same crash point, 8007007E stowed under 0xc000027b
(Used both builtin features and PDE from the XAML crash debugging tutorial)

The WinDbg log from the first session (they agreed to share it for debugging purposes)
ends with the 0xc000027b exception code, and after clicking Go, c0000602 and the end.

Log lines right before the exception (running on Windows NT 10.0.22621.0)

``` D:\a\_work\1\s\dev\UndockedRegFreeWinRT\catalog.cpp(337)\Microsoft.WindowsAppRuntime.dll!00007FFCEF17B610: (caller: 00007FFCEF17E110) ReturnHr(1) tid(15734) 80004002 No such interface supported D:\a\_work\1\s\dev\UndockedRegFreeWinRT\urfw.cpp(244)\Microsoft.WindowsAppRuntime.dll!00007FFCEF17E0F4: (caller: 00007FFCDA0339DC) ReturnHr(2) tid(15734) 80004002 No such interface supported (1570c.14cd8): C++ EH exception - code e06d7363 (first chance) (1570c.14cd8): C++ EH exception - code e06d7363 (first chance) (1570c.14cd8): C++ EH exception - code e06d7363 (first chance) (1570c.14cd8): C++ EH exception - code e06d7363 (first chance) (1570c.14cd8): C++ EH exception - code e06d7363 (first chance) (1570c.14cd8): CLR exception - code e0434352 (first chance) (1570c.14cd8): C++ EH exception - code e06d7363 (first chance) (1570c.14cd8): CLR exception - code e0434352 (first chance) ModLoad: 00007ffd`c1520000 00007ffd`c1634000 C:\WINDOWS\System32\MSCTF.dll (1570c.15030): C++ EH exception - code e06d7363 (first chance) (1570c.15030): C++ EH exception - code e06d7363 (first chance) (1570c.15030): C++ EH exception - code e06d7363 (first chance) (1570c.15030): C++ EH exception - code e06d7363 (first chance) (1570c.15030): C++ EH exception - code e06d7363 (first chance) (1570c.15030): CLR exception - code e0434352 (first chance) (1570c.15030): C++ EH exception - code e06d7363 (first chance) (1570c.15030): CLR exception - code e0434352 (first chance) ModLoad: 00007ffd`72c50000 00007ffd`72c59000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.5\System.Diagnostics.FileVersionInfo.dll (1570c.15734): CLR exception - code e0434352 (first chance) ModLoad: 00007ffc`df950000 00007ffc`df9ff000 C:\Users\[User]\Downloads\Amethyst-04292023\Amethyst-04292023\System.ComponentModel.Composition.dll ModLoad: 00007ffc`e1ad0000 00007ffc`e1aec000 C:\Users\[User]\Downloads\Amethyst-04292023\Amethyst-04292023\Microsoft.Windows.AppNotifications.Projection.dll Microsoft.ui.xaml.dll!00007FFCD9FFE4A9: 8007007E - The specified module could not be found. (1570c.15734): Unknown exception - code c000027b (!!! second chance !!!) KERNELBASE!RaiseFailFastException+0x152: 00007ffd`bfa37cd2 0f1f440000 nop dword ptr [rax+rax] 0:000> g WARNING: Continuing a non-continuable exception (1570c.15734): Unknown exception - code c0000602 (!!! second chance !!!) KERNELBASE!RaiseFailFastException+0x152: 00007ffd`bfa37cd2 0f1f440000 nop dword ptr [rax+rax] ```

The WinDbg log from the second session (they agreed to share it for debugging purposes)
is from a different machine, but also ends in these two exception codes, however,
this time clicking Go allowed further execution

Log lines right before the exception (running on Windows NT 10.0.19045.0)

``` D:\a\_work\1\s\dev\UndockedRegFreeWinRT\catalog.cpp(337)\Microsoft.WindowsAppRuntime.dll!00007FFAF8D90ABE: (caller: 00007FFAF8D9356A) ReturnHr(1) tid(8fe4) 80004002 No such interface supported D:\a\_work\1\s\dev\UndockedRegFreeWinRT\urfw.cpp(244)\Microsoft.WindowsAppRuntime.dll!00007FFAF8D93551: (caller: 00007FFA82831460) ReturnHr(2) tid(8fe4) 80004002 No such interface supported ModLoad: 00000170`c87f0000 00000170`c8836000 D:\Programs\Amethyst\System.ComponentModel.Composition.dll ModLoad: 00000170`c8840000 00000170`c8852000 D:\Programs\Amethyst\Microsoft.Windows.AppNotifications.Projection.dll ModLoad: 00007ffb`1d3c0000 00007ffb`1d3ca000 D:\Programs\Amethyst\System.IO.Compression.ZipFile.dll ModLoad: 00000170`c8860000 00000170`c8868000 D:\Programs\Amethyst\System.Runtime.Loader.dll ModLoad: 00007ffb`64690000 00007ffb`646bd000 C:\WINDOWS\SYSTEM32\iphlpapi.dll ModLoad: 00007ffb`67110000 00007ffb`67119000 C:\WINDOWS\System32\NSI.dll ModLoad: 00007ffb`5eaa0000 00007ffb`5eab9000 C:\WINDOWS\SYSTEM32\dhcpcsvc6.DLL ModLoad: 00007ffb`5ea40000 00007ffb`5ea5f000 C:\WINDOWS\SYSTEM32\dhcpcsvc.DLL ModLoad: 00007ffb`646c0000 00007ffb`647b3000 C:\WINDOWS\SYSTEM32\DNSAPI.dll ModLoad: 00007ffb`62f20000 00007ffb`62f2d000 C:\WINDOWS\SYSTEM32\WINNSI.DLL (7634.8fe4): Unknown exception - code c000027b (!!! second chance !!!) KERNELBASE!RaiseFailFastException+0x152: 00007ffb`65fa57f2 0f1f440000 nop dword ptr [rax+rax] 0:000> g WARNING: Continuing a non-continuable exception (7634.8fe4): Unknown exception - code c0000602 (!!! second chance !!!) KERNELBASE!RaiseFailFastException+0x152: 00007ffb`65fa57f2 0f1f440000 nop dword ptr [rax+rax] 0:000> g WARNING: Continuing a non-continuable exception ```

I'm attaching a memory dump for this crash collected using these guidelines,
also shared in terms of the agreement regarding debugging the issue.

The crash happens while trying to instantiate a new Microsoft.UI.Xaml.Window's base,
where the constructor of the derived MainWindow class isn't even being called yet.
This is really weird, so if there's any more info needed, I'll be happy to try to provide it.

The application is unpackaged, self-contained, sets WindowsAppSDKSelfContained, and isn't being trimmed.
Additionally, the same issue seems to be happening for most Windows App SDK versions tested, currently.

Steps to reproduce the bug

As described before, I can't really reproduce this on my own machine.
I've attached WinDbg logs and a memory dump, if that even helps in this case.

The described crash happens when the application is trying to instantiate Microsoft.UI.Xaml.Window
(as I said, the constructor of the derived MainWindow class isn't even being called at that point)

The detailed crash stack pointed at DragBarWindow, but I guess it's just the base,
and anyway, the memory dump attached upper should show the same stack trace too.

Expected behavior

XAML shouldn't crash the app, and this exception cannot be caught using
in-app crash handlers because it invokes FailFast that surpasses them.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.3.0: 1.3.230331000

Windows version

Windows 11 (22H2): Build 22621, Windows 10 (21H2): Build 19044

Additional context

I've probably forgotten about some basic things to this report anyway,
please say if there's anything more I could try doing to troubleshooting this.

[bogdan-patraucean]

I'm having the same issue with my app. Same 1.3 version.

[DFFspace]

Having similar issues with my projects but for some reason the crash only appears when the soloution config is set to debug. When I switch to release the application does launch normally. Reverting back to 1.2.5 will give the same issues.

[KimihikoAkayasaki]

Note, in my case the CI is always publishing the app using the following profile:

     <Configuration>Release</Configuration> 
     <Platform>x64</Platform> 
     <PublishDir>bin\Release\net7.0\win10-x64\publish\</PublishDir> 
     <PublishProtocol>FileSystem</PublishProtocol> 
     <_TargetId>Folder</_TargetId> 
     <TargetFramework>net7.0</TargetFramework> 
     <RuntimeIdentifier>win10-x64</RuntimeIdentifier> 
     <SelfContained>true</SelfContained> 
     <PublishSingleFile>false</PublishSingleFile> 
     <PublishReadyToRun>true</PublishReadyToRun> 
     <PublishTrimmed>false</PublishTrimmed>

So ofc it's set to release, I wouldn't expect debug builds to run correctly on non-dev machines...
As mentioned, the crash persists no matter if the app is published as self-contained or not.

[DFFspace]

I think mine is a bit different. When I Build my app and publish it as release I have no issues. The issue for me has to do when running the application inside Visual Studio when set to debug. It will build and tries to launch the app. I see the diagnostic page popup where resources are being used but the program doesn't popup. sometimes It will instand close or takes 30 secs before it closes. I have attached a video to showcase it.

Recording.2023-05-09.122818.mp4

[bogdan-patraucean]

My issue is also happening live in production.

[KimihikoAkayasaki]

I've managed to get it working again by switching to packaged deployment model.
It probably won't be a suitable solution for everyone, though...

Some things worth noting, which helped along the way:

• desktop8's UserMutablePackageDirectories is super-helpful for mods and runtime localization (we're using json and auto refresh on changes), note that the desktop6 version doesn't allow for these
• if you need to give other apps a way to load stuff from your app (e.g. load/write/execute a dll), it's a good idea to put it in packaged AppData (ApplicationData.Current)
• this was very very helpful for enabling auto updates and self-restart, as we're currently using AppCenter distribute for preview builds (note: won't work for apps defining multiple "shortcuts" / appx manifest Applications)

And hope this can be fixed soon enough

[beeradmoore]

I think I just had this issue reported here for my DLSS Swapper app. I've had minimal time to look into he crash dump but what I have seen so far looks to be the same as reported above.

Application (DLSS Swapper) is an unpackaged app, self contained + WindowsAppSDKSelfContained as above. The main change I did between 1.0 and 1.0.2 is I bumped SDK, so I guess I'll be putting that back. I don't know to what version as I am unable to replicate it on any of my own machines.

As @KimihikoAkayasaki hinted at, packaged isn't suitable for many people. Having to jump through hoops to get users to install and trust certificates is a pain, we were published to the Microsoft Store but were later told we can't publish an update as an application that downloads executables (dlss dll files used to place in games) is against store policy. It was after that I removed those and went only the unpackaged route.

[beeradmoore]

I've now had multiple users reporting the issue. The common thread with all of them is that they are using RivaTuner Statistics Server (RTSS). Setting RTSS application detection level to none (either globally or specifically for my application) then allows my app to start. I've tested RTSS on 3 PC's and am unable to replicate with the build they are having the issue in (DLSS Swapper portable v1.0.2)

@KimihikoAkayasaki (or anyone else above) I don't suppose you have installed RTSS (often comes with MSI Afterburner)?

[KimihikoAkayasaki]

No, I don't really use such stuff. However, as reported by some users, supposedly all non-native OC, "boosting", and "optimization" software is going to cause weird and unpredictable errors.

[pratikone]

Thanks for providing detailed logs. Unfortunately, not having a stable repro makes it hard to debug. The logs are also not very useful because it is such a early level failure. The window object itself is not able to create. I wonder if something is blocking it. The reference to 3P software like Riva Turner also complicates.
I wouldn't be able to help much here apart from verifying regular stuff like ensuring app.manifest of project has this

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- The ID below informs the system that this application is compatible with OS features first introduced in Windows 10. 
      It is necessary to support features in unpackaged applications, for example the custom titlebar implementation.
      For more info see https://docs.microsoft.com/windows/apps/windows-app-sdk/use-windows-app-sdk-run-time#declare-os-compatibility-in-your-application-manifest -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
    </application>
  </compatibility>

Apart from that, i would close this issue as there isn't any lead to go on.