.NET 6 and WINUI3 fails to start Unable to load DLL 'Microsoft.ui.xaml.dll'

[devlead]

Describe the bug

When running WINUI3 on Windows 10 ( 21H1 19043.1083 ) looks like the application never launches, but is application crashes with the below error in the event log

CoreCLR Version: 6.0.21.52210
.NET Version: 6.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException: Unable to load DLL 'Microsoft.ui.xaml.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)

Steps to reproduce the bug

Packaged

1. Install Windows 10 21H1 19043.1083
2. Install the latest Microsoft.WindowsAppRuntime.Redist.1.0.0
3. Install MSIX dependencies
4. Install application MSIX
5. Launch the application
6. Application never launches (well crashes)

Unpackaged,

1. Install Windows 10 21H1 19043.1083
2. Install the latest Microsoft.WindowsAppRuntime.Redist.1.0.0
3. Copy compiled output
4. Launch the application
5. Application never launches (well crashes)

Packaged

1. Install Windows 10 21H2 2200.194
2. Install the latest Microsoft.WindowsAppRuntime.Redist.1.0.0
3. Install MSIX dependencies
4. Install application MSIX
5. Launch the application
6. Application never launches (well crashes)

Unpackaged,

1. Install Windows 10 21H2 2200.194
2. Install the latest Microsoft.WindowsAppRuntime.Redist.1.0.0
3. Copy compiled output
4. Launch the application
5. Application never launches (well crashes)

Expected behavior

For the application to launch.

Screenshots

No response

IDE

Visual Studio 2022

NuGet package version

Microsoft.WindowsAppSDK 1.0.0-preview3

Project type

• Packaged
• Unpackaged

Windows version

Windows 11 (22000), May 2021 Update (19043)

Additional context

No response

[kmgallahan]

CommunityToolkit/WindowsCommunityToolkit#3998 (comment)

microsoft/microsoft-ui-xaml#4591

[devlead]

Currently, get same issue with .NET 5 too though

CoreCLR Version: 5.0.1221.52207
.NET Version: 5.0.12
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException: Unable to load DLL 'Microsoft.ui.xaml.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
   at .Program.XamlCheckProcessRequirements()

Works on a Machine with Visual Studio and Visual Studio Extension installed.

[devlead]

Seems like others are having similar issues #974

[MikeHillberg]

I've seen that when the VCRedist wasn't installed on the target machine, which would explain why you don't see it on a machine with VS installed. Xaml.dll is generally the first runtime DLL to get loaded (trying to get static APIs from the Application class), so multiple install issues can show up with that message.

[stewienj]

@MikeHillberg Thanks, that was the solution to this problem.

[devlead]

@MikeHillberg this indeed sorted the issue 👍

[stewienj]

I think the problem here is the assumption that you can just xcopy your build output to another PC and run it when you put this in your project file:

<!-- This bundles the .NET Core libraries -->
<SelfContained>true</SelfContained>
<!-- This bundles the WinUI3 components -->
<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>

I see a few potential fixes for people running into this problem:

• The app should detect the missing C++ runtime DLLs and throw up a message, or log a message stating the C++ runtime needs to be installed.
• There should be a nuget package available from Microsoft that allows you to bundle the C++ runtime DLLs with your app.
• There could be a project file flag that copies the required DLLs to the build directory

[MikeHillberg]

Yes, is WRT the .NET runtime, not the WindowsAppSDK runtime.

[bryaan]

I'm having this issue as well and don't know what the solution is. I already have the Redistributable.

[yshteinm]

When I run Packaged app on my machine it works. When I run Unpackaged app it doesn't. When I run exe from console it doesn't work. When I deploy an app to another machine it doesn't work. When I say it doesn't work it means I am getting an error either in Event Viewer or dialog box "Unable to load DLL 'Microsoft.ui.xaml.dll' or one of its dependencies"
I am running Released version 1.0.0

[candritzky]

I'm still having the same problem, also after reinstalling VCredist 14.30.30704.

[stewienj]

@candritzky I had the same issues on Windows 10 version 1909 and installing the VC++ runtime didn't fix it. I copied the following DLLs from my dev PC to my apps directory on the target PC and it worked. They might not all be required though:
concrt140.dll
msvcp140.dll
msvcp140_1.dll
msvcp140_2.dll
msvcp140_atomic_wait.dll
msvcp140_codecvt_ids.dll
vcruntime140.dll
vcruntime140_1.dll

[pjc2007]

I just installed VS 2022, and the WindowsAppSDK.Cs.Extension.Dev17.Standalone.vsix

I started a new WinUI3 project form the templates. F5 debug running packaged is ok, but I get this error when I select WinUIDeploy (Unpackaged) . This is trying to start within VS.

[KerryRJ]

I had to change this in the .wapproj, from

<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.0.0" />

to

<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.0.0">
  <IncludeAssets>build</IncludeAssets>
</PackageReference>

and finally got the packaged app to install and run on my dev pc (outside of VS2022) and on two non-dev pcs.

I didn't need to install the VC redistributables.

[turkerdev]

If you are trying to run unpackaged version, do not forget to add this code to "csproj" file.

<WindowsPackageType>None</WindowsPackageType>

Microsoft reference

[bryaan]

I had to change this in the .wapproj,

<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.0.0">
  <IncludeAssets>build</IncludeAssets>
</PackageReference>

When I try this the code doesn't compile because it is now missing all xaml references. For example, Application and Window are no longer found.

[wstaelens]

has this been resolved? same issue.

[niels9001]

@MikeHillberg Ping on this - I'm getting the same issue with 1.0.1.

[CleanCodeDeveloper]

I have this issue as well using 1.0.1

@niels9001: Funny to see you here too.

[markolbert]

I'm getting the same problem on 1.0.1 as well. Any timeline on when it'll be resolved/fixed?

[FrogsLegs]

I'm getting the same problem on 1.0.2 also today. Is there any known workarounds until this is resolved?

[mikebattista]

What do you mean by packed and unpacked? With MSIX (packaged) and without MSIX (unpackaged)?

[gmgallo]

Yes MSIX packed.
Right now I gave up trying to fix the crippled project. Started a new TS with two blank pages and made sure that MSIX packed and unpacked runs fine local and remote. So far so good, they do. Do you want a copy of the bad project to have a look?

[mikebattista]

What did you change between the known good version and the crippled version?

[gmgallo]

As commented earlier, the problem started when I setup for remote debug over the local network. I had to try and error a couple of times until I got the settings right to work with MSIX packed to remote debug on the target, but at that point I lost the capacity to run the app unpacked anyware.
Before that, last week I created a couple of Publish profiles: release x86 and release x64, and ran them. At that time I was not doing remote debug. Maybe that threw a wrench in the settings somewhere?
Both project files had differences but after making the bad one identical to the good one made no difference.
Very frustrating, I wasted countless hours faighting the tool instead of doing my work.

[gmgallo]

The good news on this one is that I did find the source of the problem in the publish profiles. While trying to get the settings right for remote debugging I changed the default target locations in the Publish Profles. Replacing the files in the project->Properties->PublishProfiles with a copy of the untouched ones from the good project fixed the problem. The crippled app now runs normally (I haven't try the remote debug yet).
I can see that there is a copy of the missing Microsoft.ui.xaml.dll in the good app project here:
...\Good App\bin\x86\Debug\net6.0-windows10.0.19041.0\win10-x86\AppX\Microsoft.ui.xaml.dll
But it is missing in:
...\Crippled App\bin\x86\Debug\net6.0-windows10.0.19041.0\win10-x86\AppX
Maybe Windows caches it somewhere?

Lesson learned: Don't mess with the publishing profies!

[dotMorten]

In one case.the launch settings file got hidden from git and didn't get checked in. The launch error is completely unhelpful trying to troubleshoot this

[gmgallo]

Well, it seems that I claimed victory too soon. The crippled app started to fault again in Main() -> XamlCheckProcessRequirements();
Now both projects have the same unmodified files in the PublishProfiles folder.
I don't see any substantial difference in the project files, but genrating Debug x86 in both projects ceates a subtatially different set of output filles with missing files and folders. Notably AppX is not there as well as Microsoft.ui.xaml.dll, and all its cousins. I created dir listings of both projects attached here.
bad_dir.txt
good_dir.txt

[SamusAranX]

I'm getting this exact error message when trying to run the default WinUI 3 project template. How do I fix this?

[gmgallo]

Once the app started to fail, I couldn't find a way to fix it. So, I started the project from scratch a couple of times, and gave up trying to debug it to a remote machine. In my case the release MSIX pack installs fine in the target machine.

[niels9001]

Make sure VS and other required stuff is up to date. Try to delete all WASDK/WinUI cache in the .nuget folder. That did the trick for me the other day.

[ushergm]

In your csproj file, under the <PropertyGroup> tag, try adding: <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>

Windows App SDK deployment guide for self-contained apps

Thanks @dshe , i would never have figured this out.

I'm investigating WinUI 3 for future projects and a POC, after 2 hours wasted on something silly, i am seriously considering ditching it. Appears to need serious time to mature.

[mwkldeveloper]

This issue occurs when starting the packaged project via WinUI App project directly.
--> the packaged project must start /set packaging project as startup
Esri/arcgis-maps-sdk-dotnet-samples#1256 (comment)

Add <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> or <WindowsPackageType>None</WindowsPackageType> to WinUI csproj both can fix the issue.

But this is not intuitive, when you try to change packaged project to non-packaged project/ run WinUI App project directly.

If you create WInUI project only (the template without packaging project), no such issue, and don't need to add
<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> or <WindowsPackageType>None</WindowsPackageType>

This is so confused and inconsistent to handle WinUI App project.
What I think to change packaged project to non-packaged project is just simple delete the packaging project or set startup project to WinUI App project directly, and all should work fine.

[dotMorten]

I’ve tried to make that argument many times. It’s how all the other packaged app projects work. No idea why WinUI needed to be
different but I agree its a serious developer experience flaw that has hurt so many people getting started.

[mwkldeveloper]

This is not WinUI project problem. Yes, it is developer experience flaw.

It is quite stranger for a new dotnet developer:
When create WInUI project only (without packaging project) , it doesn't need <WindowsPackageType>None</WindowsPackageType>,

But when create WInUI project with packaging project, and I try to run it directly I need add <WindowsPackageType>None</WindowsPackageType>'

Event I delete the packaging project, the solution still thinks it refence packaging project.
Maybe something I misunderstand, but that's what I think.

[esmorun]

Having this problem when I try to publish my app as self contained single file. Here are my properties, what am I doing wrong?

<PropertyGroup>
   <OutputType>WinExe</OutputType>
    <TargetPlatformMinVersion>10.0.18362</TargetPlatformMinVersion>
    <RootNamespace>MyWinUIApp</RootNamespace>
    <ApplicationManifest>app.manifest</ApplicationManifest>
    <Platforms>x86;x64;ARM64</Platforms>
    <RuntimeIdentifiers>win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>
    <PublishProfile>win10-$(Platform).pubxml</PublishProfile>
    <UseWinUI>true</UseWinUI>
    <EnableMsixTooling>true</EnableMsixTooling>
    <ApplicationIcon>Assets\icon.ico</ApplicationIcon>
    <TargetFrameworks>net6.0-windows10.0.18362</TargetFrameworks>
    <StartupObject></StartupObject>
    <SelfContained>true</SelfContained>
    <WindowsPackageType>None</WindowsPackageType>
    <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
    <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>
    <Nullable>enable</Nullable>
</PropertyGroup>

[gmgallo]

And here we go again a year later. This nasty problem cripped again in a new app that I was working for months now. Compiled and debug hundred of times without a problem except for the debugger that crassed a couple of time all the way to a blue screen (BugCheck). But the project itself ran just fine until I tried to run a Packed release version without debuger. Then things tarted to go bad. The app didn't start, tried to run Unpacked. Same result. Going back to debug packed, the problem persists, now it doesn't run in any mode. I can't find the way to reverse it back to run debug packed. The non graphical part of the app keeps running in the backgroung and must be killed by the debugger (Ctrl+F5) or by task manager if ran drectly from file Explorer. Both VS and TemplateStudio are up to date. This must be a WinUI problem. I ran the app undr WinDbg Preview and got this out:

odLoad: 00007ffc`ef680000 00007ffc`ef6b0000   C:\WINDOWS\System32\IMM32.DLL
ModLoad: 00007ffc`2e840000 00007ffc`2e8a0000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\hostfxr.dll
ModLoad: 00007ffc`2e7d0000 00007ffc`2e834000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\hostpolicy.dll
ModLoad: 00007ffc`2e2d0000 00007ffc`2e7c8000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\coreclr.dll
ModLoad: 00007ffc`ed750000 00007ffc`ed87b000   C:\WINDOWS\System32\ole32.dll
ModLoad: 00007ffc`ed960000 00007ffc`edcb4000   C:\WINDOWS\System32\combase.dll
ModLoad: 00007ffc`ed890000 00007ffc`ed95d000   C:\WINDOWS\System32\OLEAUT32.dll
ModLoad: 00007ffc`ecf40000 00007ffc`ecfc2000   C:\WINDOWS\System32\bcryptPrimitives.dll
(2e44.2e48): Unknown exception - code 04242420 (first chance)
ModLoad: 00007ffc`2d1b0000 00007ffc`2dccb000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\System.Private.CoreLib.dll
ModLoad: 00007ffc`2d030000 00007ffc`2d1ab000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\clrjit.dll
ModLoad: 00007ffc`eb540000 00007ffc`eb552000   C:\WINDOWS\SYSTEM32\kernel.appcore.dll
ModLoad: 00007ffc`2cf30000 00007ffc`2d025000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\TSDataLoggerApp.dll
ModLoad: 000001ab`59cf0000 000001ab`59cfe000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\System.Runtime.dll
ModLoad: 00007ffc`ea5c0000 00007ffc`ea65e000   C:\WINDOWS\system32\uxtheme.dll
ModLoad: 00007ffc`2c190000 00007ffc`2cf27000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\Microsoft.WinUI.dll
ModLoad: 00007ffc`2c000000 00007ffc`2c185000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\WinRT.Runtime.dll
ModLoad: 00007ffc`2bfc0000 00007ffc`2bffe000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\System.Collections.Concurrent.dll
ModLoad: 00007ffc`2bf80000 00007ffc`2bfbf000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\System.Collections.dll
ModLoad: 00007ffc`4db40000 00007ffc`4db53000   E:\Code\SC200\TSDataLoggerApp\bin\Release\Publish\System.Threading.dll
ModLoad: 00007ffc`ed570000 00007ffc`ed597000   C:\WINDOWS\System32\BCrypt.dll
(2e44.2e48): C++ EH exception - code e06d7363 (first chance)
ModLoad: 00007ffc`cc730000 00007ffc`cc95e000   C:\WINDOWS\SYSTEM32\icu.dll
(2e44.2e48): CLR exception - code e0434352 (first chance)
(2e44.2e48): CLR exception - code e0434352 (!!! second chance !!!)
KERNELBASE!RaiseException+0x69:
00007ffc`ed11cf19 0f1f440000      nop     dword ptr [rax+rax]

as you can see, the real offender icu.dll.
None of the proposed solutions here have worked for me. I must resort to the only method that works: start from scratch a new project and move all my files there, adjust namepsaces, and keep going.

[zipswich]

If you are trying to run unpackaged version, do not forget to add this code to "csproj" file.

<WindowsPackageType>None</WindowsPackageType>

Microsoft reference

Today is December 19, 2023, and I still got the System.DllNotFoundException error after creating a barebone new app with the template:

This solution from Jan 20, 2022 still saved me.

[gmgallo]

Yes, I tried that, several references to it are in this thread, but once the damage is made, that won't fix it.
Also I just discovered a few days ago while trying to narrow into this problem that refactoring the base namespace of a MVVM project also creates the same problem and, sometimes, compiler errors, despite the fact that, as far as I can see, refactoring do a thorough job working all over the source code and XAML files. However, some the compiler generated code, those o.i.cs files, still refer to the old namespace. Reverting the namespace back to its original at the project creation time solves the error. That strongly suggest that this is a disconnected or unresolved namespace that manifests at run time.

And by the way, the same error happens if you try to run a freshly created WinUI3 packed project available in the VS templates. Instead, you should run the pack project created alongside and everything works fine, which I find counter intuitive. See, @mwkldeveloper comment above.

[dantra13]

I'd like to share some of my experiences as I was transitioning from Unpackaged to Packaged and encountered the already discussed issue. The program ran well alongside Visual Studio, but when generating the MSIX and installing it, launching the application was blocked, both on the development machine and on others where I had set up everything needed to run the application. The error in the event log is the same:

Faulting application name: Crono.exe, version: 1.0.0.0, time stamp: 0x656f70bc
Faulting module name: Microsoft.ui.xaml.dll, version: 3.1.4.0, time stamp: 0xd8e270fd
Exception code: 0xc000027b
Fault offset: 0x00000000003ba2f4
Faulting process id: 0x0xDA48
Faulting application start time: 0x0x1DA749FAA3F4B7C
Faulting application path: C:\Users\mella\OneDrive\Escritorio\app\Crono.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.4_4000.1136.2333.0_x64__8wekyb3d8bbwe\Microsoft.ui.xaml.dll
Report Id: ce939508-e0e0-401a-beb1-e2749a330203
Faulting package full name: 
Faulting package-relative application ID: 

Inspired by a blog post from @markolbert, which related similar problems to path handling in their application, led me to investigate the configuration of my project, which uses Sqlite3 with Entity Framework Core, as well as references to assets required by the project. I identified that the problem arose when trying to access the database. To solve it, I made significant changes in the way the database was accessed in the code.

Change made:

Originally, the database configuration was done as follows:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    var path = AppDomain.CurrentDomain.BaseDirectory + @"\settings.db";
    optionsBuilder.UseSqlite($"Data Source={path}");
}

After modifying the configuration:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    string databasePath = Path.Combine(ApplicationData.Current.LocalFolder.Path, "settings.db");
    optionsBuilder.UseSqlite($"Data Source={databasePath}");
}

Although this modification resolves the issue, I don't understand the connection to the problem seen in the event log. I am relatively new to desktop application development, especially with WinUI3. I hope this can also be of use to you, and that you do not disregard the recommendations already mentioned.