UWP app throws unhandled exception when installed from .msix package

Question

This is a UWP app with Visual Studio Insiders [11709.129]. When deployed from Visual Studio, started with or without debugging to a Windows 10, an Xbox, or a Windows 11, it runs fine and is passing the tests.

However, when the project is published to an App Package then the generated .msix file is taken to a Windows 11 machine and installed, the app fails. It shows, by attaching remote debugger to the installed App Package, that an unhandled exception (Windows.UI.Xaml.dll) is being thrown.

The app does quite a bit of work before the exception is thrown. It seems like the exception may be related to JSON serialization taking place that then writes a file to Windows.Storage.ApplicationData.Current.LocalFolder. But cannot determine that for sure.

The stack trace from the exception is not so helpful. Any thoughts about how to debug this? Can this exception be caught to try to get an idea of the cause?

As follow on let me ask about remote debugging from an .msix install. The remote debugger can attach to the Installed App Package, but there are no debug symbols over there for setting breakpoints and such. It might be easier to debug this if there were a way to create the debug info for the Installed App Package were available to the debugger. Is such a thing possible?

 TY!

Answer 1

Hi @WoodManEXP ,

I understand how frustrating this issue is. Since the app works in F5 debugging but crashes after MSIX installation, the most likely causes are:

• .NET Native compilation stripping reflection metadata (common with JSON serialization in Release builds)
• Synchronous file I/O (.Result / .Wait()) causing crashes inside the AppContainer sandbox

You can verify this by:

• Switch to Release mode
• Enable .NET Native toolchain
• Run the app locally with F5

If it crashes, it is likely a reflection metadata issue.

For Newtonsoft.Json, add metadata preservation in Default.rd.xml. Also ensure all file operations use async/await only.

To capture the exact exception:

• Enable CLR Exceptions in Exception Settings
• Use Debug Installed App Package in Visual Studio

Please try the Release + .NET Native test and share any exception details if available. Hope this helps! If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.Hi @WoodManEXP ,

I understand how frustrating this issue is. Since the app works in F5 debugging but crashes after MSIX installation, the most likely causes are:

• .NET Native compilation stripping reflection metadata (common with JSON serialization in Release builds)
• Synchronous file I/O (.Result / .Wait()) causing crashes inside the AppContainer sandbox

You can verify this by:

• Switch to Release mode
• Enable .NET Native toolchain
• Run the app locally with F5

If it crashes, it is likely a reflection metadata issue.

For Newtonsoft.Json, add metadata preservation in Default.rd.xml. Also ensure all file operations use async/await only.

To capture the exact exception:

• Enable CLR Exceptions in Exception Settings
• Use Debug Installed App Package in Visual Studio

Please try the Release + .NET Native test and share any exception details if available.

Hope this helps! If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

Answer 2

Use the installed package and remote debugging to narrow this down, then collect deployment/runtime diagnostics from the MSIX side.

1. Debug the installed app package

• On the target Windows 11 machine, install the .msix.
• In Visual Studio, use Debug → Other → Debug Installed App Packages.
• Select the app, then either:
  • Start it directly from this dialog, or
  • Select Do not launch, but debug my code when it starts, then launch the app normally so the debugger attaches as soon as it starts.
• This lets breakpoints and exception settings work against the installed package, not just the F5-deployed build.

If the app is on another device (Xbox, another PC, etc.), use the same Debug Installed App Packages flow with remote debugging. Visual Studio will install the correct remote debugger on the target device and attach to the installed package.

2. Attach to the process if needed

• Alternatively, use Debug → Attach to Process to attach to the running UWP process.
• For full debugging features (breakpoints, correct call stacks), ensure the installed binaries and PDBs match the build open in Visual Studio. The compiled app on the target must come from the same build as the local one.

3. Capture deployment/runtime diagnostics for the MSIX Because the failure only occurs when installed from the .msix, also check packaging/deployment logs:

• Open Event Viewer → Applications and Services Logs → Microsoft → Windows.
• Inspect:
  • AppXDeployment-Server → Microsoft-Windows-AppXDeploymentServer/Operational
  • AppxPackagingOM → Microsoft-Windows-AppxPackaging/Operational
• These logs can reveal issues related to package integrity, file system virtualization, or container behavior that differ between F5 deployment and installed MSIX.
• Optionally run Get-AppxLog in PowerShell to see the most recent deployment operation and correlate with the failing run.

4. Compare builds and symbols

• Ensure the package being installed is a debug (or at least symbolized) build so that Visual Studio can load matching PDBs.
• Open the same solution/build in Visual Studio that produced the .msix, then attach via Debug Installed App Packages. This improves the usefulness of the stack trace and allows stepping into code around JSON deserialization and file I/O.

5. Consider MSIX/OS differences

• MSIX behavior can differ by Windows version. If targeting Windows 10 and running on Windows 11, confirm that no Windows 11–only manifest extensions or MSIX features are being used incorrectly.
• If using newer MSIX features, verify that the target OS version supports them as described in MSIX feature/limitations documentation.

By combining Debug Installed App Packages (or Attach to Process with matching symbols) and the MSIX deployment logs, it is possible to catch the exception in managed code, inspect the JSON/file I/O logic, and see whether containerized storage or packaging differences on Windows 11 are causing the unhandled exception.

---

References:

• Deploying and debugging UWP apps
• Debug an installed UWP app package in Visual Studio
• Attach to running processes with the Visual Studio debugger (programming-language-all)
• Attach to running processes with the Visual Studio debugger (programming-language-dotnet)
• Attach to running processes with the Visual Studio debugger (programming-language-dotnetf)
• Attach to running processes with the Visual Studio debugger (programming-language-cpp)
• Troubleshooting packaging, deployment, and query of Windows apps
• MSIX troubleshooting guide

AI-generated content may be incorrect. Read our transparency notes for more information.