Faulting Module : Microsoft.UI.Xaml.DLL - Win32 WinUI 3 App not loading

[OceanCyanTech]

Describe the bug

When I'm trying to run my WinUI 3 app, I get this error in Event Viewer:

Log Name: Application
Source: Application Error
Date: 29-05-2022 17:30:40
Event ID: 1000
Task Category: Application Crashing Events
Level: Error
Keywords:
User:
Computer:
Description:
Faulting application name: CompInfo.exe, version: 1.0.0.0, time stamp: 0x62571150
Faulting module name: Microsoft.ui.xaml.dll, version: 3.0.0.2204, time stamp: 0xe15d9c14
Exception code: 0xc000027b
Fault offset: 0x0023bac9
Faulting process id: 0x0x59D8
Faulting application start time: 0x0x1D87353B61B4DB3
Faulting application path: C:\Program Files (x86)\CompInfo\CompInfo.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1-preview3_1000.485.2229.0_x86_8wekyb3d8bbwe\Microsoft.ui.xaml.dll
Report Id: 0f4e4cd6-ed23-4b81-bf6d-7aaade61fcda
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
](http://schemas.microsoft.com/win/2004/08/events/event);


1000
0
2
100
0
0x8000000000000000

6885


Application
Lenovo_laptop



CompInfo.exe
1.0.0.0
62571150
Microsoft.ui.xaml.dll
3.0.0.2204
e15d9c14
c000027b
0023bac9
0x59d8
0x1d87353b61b4db3
C:\Program Files (x86)\CompInfo\CompInfo.exe
C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1-preview3_1000.485.2229.0_x86_8wekyb3d8bbwe\Microsoft.ui.xaml.dll
0f4e4cd6-ed23-4b81-bf6d-7aaade61fcda

Steps to reproduce the bug

1. Create a WinUI 3 app with Windows App SDK Runtime 1.0.3
2. Build it as Non-Packaged
3. Use Inno Setup to create a setup.exe
4. Run it on a computer which has Windows App SDK Runtime 1.0.3 installed
5. App doesn't open
6. Open Event Viewer and find issue under Windows Logs> Application

Expected behavior

App runs smoothly

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.0.3

Windows app type

• UWP
• Win32

Device form factor

Desktop

Windows version

Windows Insider Build (xxxxx)

Additional context

No response

[marb2000]

Did you install the Windows App SDK runtime on your machine? When your app is unpackaged you need it:

https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/deploy-unpackaged-apps#deploy-windows-app-sdk-runtime

[lukedukeus]

Im experiencing this too, @OceanCyanTech did you ever get it working?

Faulting module name: Microsoft.ui.xaml.dll, version: 3.0.0.2206, time stamp: 0xfec042e2
Exception code: 0xc000027b
Fault offset: 0x000000000033f2d8

[dannyr-git]

I am having this same problem. My unpackaged app only runs on my machine. I've tested it with friends' Windows 10 machines and my wife's Windows 11 machine. All errors look like this :

Faulting application name: wingman.exe, version: 1.0.0.0, time stamp: 0x63c9df9f
Faulting module name: Microsoft.ui.xaml.dll, version: 3.0.0.2302, time stamp: 0x93c3ada5
Exception code: 0xc000027b
Fault offset: 0x00000000007cd8bc
Faulting process id: 0x0x38C
Faulting application start time: 0x0x1D955C8A6F93000
Faulting application path: d:\Store\net7.0-windows10.0.19041.0\wingman.exe
Faulting module path: d:\Store\net7.0-windows10.0.19041.0\Microsoft.ui.xaml.dll
Report Id: a9acd5cd-c47b-4fbc-a63c-5b51f02d421e
Faulting package full name: 
Faulting package-relative application ID: 

I am compiling with this :

    <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
    <WindowsPackageType>None</WindowsPackageType>

I've personally overseen that every machine installs :

.Net7 (obviously)
VCRedist
and 
https://aka.ms/windowsappsdk/1.2/1.2.230217.4/windowsappruntimeinstall-x64.exe
https://aka.ms/windowsappsdk/1.2/1.2.230217.4/windowsappruntimeinstall-x86.exe

I have no idea how to triage what is going on here. I did notice when you install the WindowsAppRuntime, you get a Microsoft.UI.Xaml.DLL that shows :
v2.8.2207.29001 , that is 6MB

But when I compile with true, the same dll in the folder is
v3.0.0.2302 (3.0.0-zmain.2302) and is 14.1MB

The full source of the app is here for reference :

https://github.com/dannyr-git/wingman

[bogdan-patraucean]

This issue is happening for a packaged app installed from the Store as well. With all runtimes installed.

Might be related to this #8577, #8446 and #5746

It's caused by this error, as I got to find using windbg

0x80040154 (FACILITY_ITF - COM/OLE Interface Management): Class not registered

	Stack	 : 0x2342e4e6ee0
		7ff93d21fa0a Microsoft_ui_xaml!DirectUI::FrameworkApplication::StartDesktop+0x1c3886
		7ff93d07abde Microsoft_ui_xaml!DirectUI::FrameworkApplicationFactory::Start+0x6e
		7ff6e3566fad

Also, Microsoft states this as a know issue:

Potential run-time error in an app with Single-project MSIX that consumes types defined in a referenced Windows Runtime Component:
To resolve, manually add activatable class entries to the appxmanifest.xml.
The expected error in C# applications is “COMException: Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)).
The expected error in C++/WinRT applications is “winrt::hresult_class_not_registered”.

@marb2000 , any updates on this? it's been 2 years since this framework launched and this issue is affecting a lot of users that try to use apps developed with WinUI 3.

[e0ff]

I have a user who has experienced this error multiple times. Our app is packaged.

[CodeFontana]

I'm new to WinUI3, just trying to get off the ground. I have prior WPF experience, so it's not like I'm totally lost.

I'm attempting to build a traditional desktop application, having nothing to do with the Windows Store. I've eliminated the launch profile for the 'packaged' version of the app, along with the 'Assets' folder, and the Package.appxmanifest, which appeared related only to the Packaged/Store version.

Additionally, I've added these three setting to my .csproj file:

<EnableMsixTooling>false</EnableMsixTooling>
<WindowsPackageType>None</WindowsPackageType>
<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>

Running in Visual Studio 2022 works without an issue.
Publishing to a folder has landed me on this thread with a crash:

Faulting application name: WinUIDesktop.exe, version: 1.0.0.0, time stamp: 0x65ab0000
Faulting module name: Microsoft.ui.xaml.dll, version: 3.1.4.0, time stamp: 0x343afd70
Exception code: 0xc000027b
Fault offset: 0x00000000003b9584
Faulting process id: 0x0x2514

Seems if I switch EnableMsixTooling back to 'true', everything works.

I didn't want to look into MAUI, as I don't need cross-platform.
Was looking into WinUI 3 due to the component gallery, would save me a lot of time vs plain old WPF.

With leaving EnableMsixTooling set to true, I'm continuing, but this already feels 'fragile' out of the box. I would highly recommend a project template for starting an 'Unpackaged' application, in addition to it not crashing with the published version. You might also consider rebranding 'unpackaged' as 'Traditional Desktop' and maybe 'Packaged' as 'Windows Store', if that's appropriate.

[CodeFontana]

Coincidentally, 20 mins later, while browsing the WinUI 3 Gallery app, it also crashed on the same Microsoft.ui.xaml.dll:

Faulting application name: WinUIGallery.exe, version: 2.2.0.0, time stamp: 0x655e0000
Faulting module name: Microsoft.ui.xaml.dll, version: 3.1.4.0, time stamp: 0xd8e270fd
Exception code: 0xc000027b
Fault offset: 0x00000000003ba2f4

I was searching icons at the time.

[karmeye]

Seems if I switch EnableMsixTooling back to 'true', everything works.

Thanks @CodeFontana! I also got this in the event log after publishing the non package project generated by the "Blank App, Packaged with Windows Application Packaging Project" template.

This is supposed to work without that right?

[CodeFontana]

Seems if I switch EnableMsixTooling back to 'true', everything works.

Thanks @CodeFontana! I also got this in the event log after publishing the non package project generated by the "Blank App, Packaged with Windows Application Packaging Project" template.

This is supposed to work without that right?

I'm in the same boat-- I would believe you should be able to create a WinUI 3 app independently from MSIX and the Windows Store, but I can't say this for sure, as I'm new to this project type myself.

Seems WinUI project templates and settings need an overhaul. Disappointing it's so confusing/buggy out of the box!

[sigmarsson]

Installed :

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net8.0-windows10.0.22621.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.22621.0</TargetPlatformMinVersion>
    <RootNamespace>Weather.History</RootNamespace>
    <Platforms>x86;x64;</Platforms>
    <RuntimeIdentifiers>win-x86;win-x64;</RuntimeIdentifiers>
    <DefaultLanguage>en</DefaultLanguage>
    <UseWinUI>true</UseWinUI>
    <EnableMsixTooling>true</EnableMsixTooling>
    <WindowsPackageType>MSIX</WindowsPackageType>
    <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
  </PropertyGroup>

Deploy successfull and program icon appears in Windows start menu.

what is missing if self-contained is being demanded ? I wonder if WinUI will represent a workload in Visual Studio installer like MAUI does.

[ENGiDEERS]

I have the same problem. I tried the same thing and couldn't find a solution. I hope this will be solved soon.

[sigmarsson]

@ENGiDEERS https://stackoverflow.com/questions/78180962/faulting-module-name-microsoft-ui-xaml-dll

[book1625]

Any update ??

[arthur28197]

Hi,
I have build a packaged self-contain WinUI3 with the following setting added into the csproj file following instruction from https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/self-contained-deploy/deploy-self-contained-apps and https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-packaging-dot-net.

 <UseWinUI>true</UseWinUI>
    <EnableMsixTooling>true</EnableMsixTooling>
    <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
    <SelfContained>true</SelfContained>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    ...
 <Target Name="_RemoveFrameworkReferences" BeforeTargets="_ConvertItems;_CalculateInputsForGenerateCurrentProjectAppxManifest">
<ItemGroup>
<FrameworkSdkReference Remove="@(FrameworkSdkReference)" Condition="$([System.String]::Copy('%(FrameworkSdkReference.SDKName)').StartsWith('Microsoft.WindowsAppRuntime.'))" />
</ItemGroup>
</Target>

The application can run in VS with no problems. However, the published MSIX package application can not run and throw the following error in event reviewer. Thanks.

[RobertK66]

Pls. all be careful to state 'I have the same problem here' with this "c000027b" Exception!

FYI: https://learn.microsoft.com/en-us/shows/inside/c000027b

IMHO this error is happening deep in the guts of Win UI XAML code. Unfortunately it is not much of a help when it happens:

... If the exception is not handled by the caller, the stowed exception is thrown fatally. Because the throwing is deferred, the current context of the associated dump has little value. ...

My own instance of this problem was simply caused by my 'stupidly misusing' of a Component in my XAML while I did not fully understand this component at that time. My symptoms where as described here

the application can run in VS with no problems. However, the published MSIX package application can not run and throw the following error in event reviewer ....

see here for details Providing a corrected version of my own XAML solved it.

That said, I am hoping that future versions of WinUI3 do improve the developer experience in this area.

[Strypper]

ere as describe

Unfortunately I stepped into these 2 error

1. Windows 10 : Faulting application name: mauisland.exe, version: 1.0.0.0, time stamp: 0x65a80000
   Faulting module name: KERNELBASE.dll, version: 10.0.19041.4355, time stamp: 0xd7762934
2. Windows 11 :Faulting application name: mauisland.exe, version: 2.0.0.0, time stamp: 0x661f0000
   Faulting module name: Microsoft.ui.xaml.dll, version: 3.1.5.0, time stamp: 0x7fd76c03

My problem is the project launch in release mode just fine both Debug and Release run the like charm, but when deployed to MSIX it crash on start which make me really frustrated to located where the issue really is

[malciin]

I have the same issue with the same exception code.

It's easily reproducible on my machine when I build the MSIX package with both /p:PublishSelfContained=true /p:WindowsAppSDKSelfContained=true. Our crucial requirement is for the app to run self-contained on an offline machine - only setting /p:PublishSelfContained=true wont allow us to install & run app on offline machine because of:

[naoki-yamamoto-ymh]

I have the same problem. Unfortunately, this problem only occurs in some environments. Is this issue still active?

[SanskaarPatni]

I am facing the same issue. I created a blank app, packaged (winui 3 in Desktop)

The "Debug" configuration deploys fine, and app does not crash on launching.

Whereas the "Release" configuration deploys and the app crashes when launched from Start menu.

Is there any issue with the template?

[jansapp]

same here

[pratikone]

Thank you all for sharing your experiences with these failures. Your input is incredibly valuable in identifying and resolving these issues. After investigating multiple issues discussed in this thread, I’ve compiled a list of potential causes and solutions for the mux.dll crash failures. It addresses some of concerns. We need more data for better root cause analysis of crashes.

Investigation Results

1. Publishing Self-Contained Unpackaged App to a Folder Results in a Crash
   Issue: The “Trim unused code” option is enabled by default in publish settings, leading to certain WinRT parts being incorrectly trimmed out. This causes a crash when running the build.
   Solution: A fix is underway. More details can be found here. In the meantime, you can disable the “Trim unused code” option to prevent the crash.

2. EnableMSIXTooling=false Results in a Crash in Self-Contained Unpackaged App’s Launch
   Issue: The EnableMsixTooling property must be set to true even for self-contained unpackaged apps, as it includes essential resource loading logic.
   Solution: We are working on improving the default settings and providing clearer indications of required build properties.

3. Publishing Packaged App to a Folder Results and launching the published binary results in a Crash
   Issue: Publishing a packaged app to a folder is not a valid configuration. This option is only applicable to unpackaged apps and can cause crashes.
   Solution: Use Project -> Publish -> Create App Packages to create an MSIX package for packaged apps. We are working on disabling the folder publish option for packaged apps.

4. Published Self-Contained MSIX Installs Correctly but Crashes on Launch on Different Machines
   Issue: This issue is challenging to reproduce. The crash stack is not helpful without symbols, and the likely cause is missing runtimes on the target machines.
   Solution: Ensure all necessary dependencies (e.g., Universal CRT, .NET runtime) are installed.

Debugging Crashes

With WinUI 3 being source available and symbols available, you can get meaningful stack traces from crashes.
First ensure you have the right setup for debugging.

WinDBG: Add the Microsoft symbol server to the default symbol path. Launch the app and let it crash to fetch symbols and display a meaningful stack trace.
Symbol Path Setup
Visual Studio: Add the Microsoft symbol server in Options -> Debugging -> Symbols. Launch the app from Visual Studio, ensuring the debugging mode is set to Native, Mixed, or Auto.
Mixed Mode Debugging
Once you have a detailed stack trace, please create a new issue in the microsoft-ui-xaml repo and share your configuration and stack trace. This will help us address these problems more efficiently.

Few debugging techniques :

1. Investigating contents of stowed exception. This resource can be useful. https://learn.microsoft.com/en-us/shows/inside/c000027b.Windbg provides a useful !pde.dse command.

2. Set breakpoint on Microsoft.UI.Xaml!OnFailureEncountered.

3. Subscribing to Application.UnhandledException Event https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.application.unhandledexception?view=windows-app-sdk-1.6

4. See crash debugging hands-on by @Scottj1s here : https://www.youtube.com/watch?v=uFgGhNGlPm4&t=1015s

If you encounter a new failure, please create a new thread instead of adding to this one. This will help us track and communicate more effectively. I will be closing this issue now.

Thank you for your cooperation and understanding!

@michael-hawker for reference.

[CodeFontana]

By closing this issue, I'm assuming you're saying WinUI is not a viable project type for traditional desktop needs. To be honest, my team abandoned the idea of using WinUI3 for our needs, based on the idea it was broken out of the box. This is feedback you need to hear when arbitrarily closing an issue based on a summary, and no concrete solutions. I'd rather you retire the technology than lie to us.

[freemstr]

I can repro this issue in .NET 8 MAUI project as well with publish trimmed turned off, just FYI

[Scottj1s]

@CodeFontana our intent is not to ignore anyone, but to actively manage our backlog. This issue dates back a couple years to Windows App SDK 1.0.3, and many variations of crashes in Microsoft.UI.Xaml.DLL have been added to it. We've resolved a few of these, and are tracking others separately. We welcome new issues opened against the latest version of Windows App SDK, with clear repro steps.

[Scottj1s]

@freemstr please enter a new issue for your MAUI-related crash.

[CodeFontana]

@CodeFontana our intent is not to ignore anyone, but to actively manage our backlog. This issue dates back a couple years to Windows App SDK 1.0.3, and many variations of crashes in Microsoft.UI.Xaml.DLL have been added to it. We've resolved a few of these, and are tracking others separately. We welcome new issues opened against the latest version of Windows App SDK, with clear repro steps.

Yeah, you're right. It's just frustrating because it takes so long to address what I would call "getting started" issues. Unfortunately, my team is not using this technology, and now it would be an uphill battle to try and suggest again. There's a basic expectation this stuff should work gracefully out of the box-- I mean we really didn't have to go far to immediately bump into problems. And I still feel there should be more obvious templating for "Traditional Desktop" vs "Windows Store" applications. Sorry if my feedback was bit rough, might just be passion and disappointment. We want you guys to hit every mark, so us folks in the trenches can confidently and consistently recommend cohesive Microsoft tech stacks.

[mirec75]

The problem with Microsoft.UI.Xaml.dll is not limited just to developing a new app.
See my problem after I updated my Win11 office notebook to 24H2 with an always crashing file explorer.
and see the solution here:
https://answers.microsoft.com/en-us/windows/forum/windows_11-wintop_update/cannot-open-explorer-after-update-to-24h2-crashes/e149b7b0-2d67-445c-807b-e25d6b87d656

With "office notebook" I mean, I'm not developing anything on the notebook, just use it with MS Office, for office like stuff
and the file explorer was simply crashing each time when I wanted to open it.