UWP app throws unhandled exception when installed from .msix package

Hi @WoodManEXP

Thanks for testing both of those and reporting back.

OK so since PublishTrimmed didn't reproduce it locally and TrimmerRootAssembly didn't fix the .msix crash, I think we can rule out trimming. My earlier suggestion was off the mark on this one - let's take a different approach.

The main thing we're missing right now is the actual exception details. Could you try this on the Windows 11 machine where the crash happens?

Go to Debug → Other Debug Targets → Debug Installed App Package, pick your app and check "Do not launch, but debug my code when it starts". Then in Debug → Windows → Exception Settings, check the top-level Common Language Runtime Exceptions box so it breaks on everything. Launch the app, and when it breaks, I'd need the exception type, the message, and the full call stack (right-click Call Stack → Select All → copy).

Make sure the solution open in VS is the same build that produced the .msix so the PDBs match and you get line numbers.

Two more things that would help: check Event Viewer after the crash (under Applications and Services Logs → Microsoft → Windows → AppXDeployment-Server / Operational), and try publishing a Debug config .msix to see if that also crashes - that'll tell us if Release optimizations are involved.

Once we have the stack trace we'll know exactly what's going on. The System.Text.Json migration is still a good idea either way, but let's nail down the actual cause first.

Let me know what you find.

Hi Jay,

-         Both Release and Debug .msix’s were built and deployed to the Windows 10 machine. Both crashed in the same way.

-         Event Viewer after the crash (under Applications and Services Logs → Microsoft → Windows → AppXDeployment-Server / Operational) looks unremarkable. Only entries after the crash are informational about the successful app installation from the .msix.

-         In Debug → Windows → Exception Settings, the top-level Common Language Runtime Exceptions box is checked, so it breaks on everything. In Debug → Other Debug Targets → Debug Installed App Package, code when it starts" is checked.

o   Started the app on the Windows 10 machine and sent it to the crash point. It crashes but remote debugger does not catch the crash (the remote debugging is connected).

o   The remote app seems to be otherwise debug-able in that breakpoints can be set and reached in the remote app (between the two machines).

Catching the exception remains elusive :-(

Might there be a way to code a try/catch somewhere to capture that unhandled exception in the code (in order to break there via debugger)?

TY !!

WoodManEXP (Robert)

HI Jay, It has been possible to get the debugger to break on the unhandled exception via the remote debugger on the .msix install using the UnhandledException call-back in the App class. Let me dig into that a it more and let you know what has been learned.

TY!!

Hi @WoodManEXP

That is a very clever workaround! Utilizing the UnhandledException event handler in App.xaml.cs is an excellent way to capture those startup crashes that might otherwise bypass the standard debugger attachment.

Once the breakpoint is triggered, gathering the following details could help me narrow down the potential factors behind this behavior:

• The Exception Object (e.Exception):

_ The Exception Type (such as UnauthorizedAccessException, NullReferenceException, etc.) which might give me a clue about the subsystem involved.

_The Full Stack Trace (e.Exception.StackTrace) and the Message (e.Exception.Message).

• Inner Exceptions:

_ If it happens to be an AggregateException or has an InnerException, these nested details often hold the actual context of the failure.

• The HRESULT:

_ If it is a COMException, the HRESULT hex code (like 0x80004005) could point me toward a specific platform or permission boundary restriction.

Please take your time looking into this. Once you have a chance to collect these details, feel free to share them here, and I can help you explore the potential causes.

Hi Jay,

Once the Unhandled exception was caught it was possible to decode through the, rather cryptic and limited, stack-trace, to get closer to where the exception originated. It originates from an InvalidCastException from a statement (in a lambda expression)

 /* this statement */var thisDoubleAnimation = (DoubleAnimation)thisStoryboard.Children[0];
 thisDoubleAnimation.Duration = new Duration(TimeSpan.FromSeconds(1));
 thisDoubleAnimation.From = 0D;
 thisDoubleAnimation.To = 1D;

That C# code is referencing this XAML

 <Storyboard x:Name="Image0FadeInStoryboard">
 <DoubleAnimation Storyboard.TargetName="Image0"
 Storyboard.TargetProperty="Opacity" 
 From="0.0" To="1.0" Duration="0:0:1"/> <!-- Set in code-behind -->
 </Storyboard>

That code segment was subsequently surrounded with try/catch which brought to light the cast exception.

Running the app from F5 does not cause the cast exception but running from .msix install does. And, in spite of my best efforts to get the .pdb symbol file associated with the .msix app, the remote debugging is showing line numbers but is really limited in terms of stepping through code and examining variable values. But it was possible to hit a break point inside the catch to see the cast exception.

What would cause this exception from .msix version of the app?

TY!

Hi Jay,

The original issue may be now solved.

By switching the syntax from

/* this statement */var thisDoubleAnimation = (DoubleAnimation)thisStoryboard.Children[0];
 thisDoubleAnimation.Duration = new Duration(TimeSpan.FromSeconds(1));
 thisDoubleAnimation.From = 0D;
 thisDoubleAnimation.To = 1D;

to

 var thisDoubleAnimation = thisStoryboard.Children[0] as DoubleAnimation;
 thisDoubleAnimation?.Duration = new Duration(TimeSpan.FromSeconds(1));
 thisDoubleAnimation?.From = 0D;
 thisDoubleAnimation?.To = 1D;

The cast exception is no longer raised. Why? Unknown.

TY for helping work this!

And, in spite of my best efforts and documentation reading to get the .pdb symbol file associated with the .msix app, the remote debugging is showing line numbers but is really limited in terms of stepping through code and examining variable values. Can share knowledge about more complete remote debuggig for the .msix install?

TY!!

Hi @WoodManEXP ,

Thanks for reaching out.

Really glad you were able to track down the actual exception. Nice work using the UnhandledException callback to catch it.

So the reason (DoubleAnimation)thisStoryboard.Children[0] throws an InvalidCastException in the .msix package but not during F5 debugging comes down to how the XAML runtime processes the visual tree differently between the two deployment modes. When deployed as an installed package, the XAML compiler and runtime may reorder or inject internal Timeline objects into the Storyboard.Children collection (for optimization or platform bookkeeping). This means the element sitting at index [0] isn't necessarily your DoubleAnimation anymore. It could be some internal framework object that can't be cast.

Your as pattern works as a workaround, but here's a more reliable approach. Rather than relying on index-based access at all, you can use OfType<>() to find the correct child by type:

var thisDoubleAnimation = thisStoryboard.Children.OfType<DoubleAnimation>().FirstOrDefault();

if (thisDoubleAnimation != null)

{

 thisDoubleAnimation.Duration = new Duration(TimeSpan.FromSeconds(1));

 thisDoubleAnimation.From = 0D;

 thisDoubleAnimation.To = 1D;

}

Or even better, give the DoubleAnimation its own x:Name in XAML and reference it directly, no cast needed:

<Storyboard x:Name="Image0FadeInStoryboard">

 <DoubleAnimation x:Name="Image0FadeInAnimation"

 Storyboard.TargetName="Image0"

 Storyboard.TargetProperty="Opacity" />

</Storyboard>

Image0FadeInAnimation.Duration = new Duration(TimeSpan.FromSeconds(1));

Image0FadeInAnimation.From = 0D;

Image0FadeInAnimation.To = 1D;

This approach is deployment-mode agnostic and eliminates any ambiguity.

Regarding your question about improving remote debugging for the .msix install, the limited stepping/variable inspection you're seeing is almost certainly a PDB mismatch issue. Here's how to get full debugging:

1. Include PDB files in your package output. Make sure your .csproj generates full symbols:

   
    <PropertyGroup>
   
    <DebugType>full</DebugType>
   
    <DebugSymbols>true</DebugSymbols>
   
    </PropertyGroup>
   
   

2. Point VS to matching symbols. In Visual Studio on the dev machine, go to Debug → Options → Symbols and add the folder path where your PDBs are located (the same build output directory that produced the .msix). The PDB GUIDs must match the deployed binaries exactly.
3. Disable "Just My Code". Go to Tools → Options → Debugging → General → uncheck Enable Just My Code. This allows full frame inspection.
4. Use the same solution/config. Open the exact same solution and build configuration (Debug/x64, etc.) that generated the .msix before attaching via Debug → Other Debug Targets → Debug Installed App Package.

For more details, see:

• Debug an installed UWP app package in Visual Studio
• Deploying and debugging UWP apps - Symbols section
• Specify symbol (.pdb) and source files in the debugger

Hope this helps.

Hello @WoodManEXP ,

Could you please let me know if my explanation was helpful? If you need any further assistance, feel free to let me know.

Hi Jay,

Your responses have been most helpful, especially in realizing some of the things that change between F5 and .msix versions (I did not know these things...).

The app has been altered to use the x:Name values to reach the XAML defined DoubleAnimation object. It should have been doing that all along!

Preparing now to move to the newer form of JSON serialization.

My attempts to get the remote debugging to have the symbols, like F5 local debugging does, are still unsuccessful. Believe each of your suggestions have been followed. Debug → Options → Symbols has been set to the folder under ..\bin\x64\Debug\net10.0,,,\win-64 where the .pdb for Debug lives. It still sees line numbers and some local variables. But nothing as extensive as F5 debugging.

TY!!

Hi @WoodManEXP

Glad the x:Name fix worked out.

On the remote debugging symbols - I want to be upfront with you here. What you're seeing is actually normal, and I don't want you burning more time thinking something is misconfigured on your end.

The difference is pretty simple: when you F5, Visual Studio launches the app in a special debug-friendly mode where the runtime keeps everything unoptimized. All locals are preserved, stepping works perfectly, etc. But when you install the .msix by hand and attach later, the app already started normally - the runtime already optimized the code before your debugger showed up. The PDB still maps line numbers fine, but the optimizer threw away a bunch of the local variable info. That's just how it works.

So you haven't done anything wrong. The symbol path is correct (that's why you get line numbers). The gap you're feeling is the optimization, not a missing setting.

One thing worth trying if you haven't already: Tools > Options > Debugging > General > check "Suppress JIT optimization on module load (Managed only)". This tells the runtime to re-compile modules without optimization when the debugger loads them. It helps, but honestly it still won't be identical to F5.

If you ever really need that full F5 experience on the remote machine, the cleanest way is to set the remote machine as your deploy target in VS (Debug target dropdown > Remote Machine) and let VS push and launch the build itself. Downside is it runs in debug mode, so if you're specifically trying to catch something that only happens in the "real" installed package, you're back to the attach workflow with its limitations.

Reference if you want to dig deeper: Debug optimized code

Hope this helps.

Good to know about the remote debugger and TY!

In other news, the project has been refitted for System.Text.Json in an attempt to come in-line with newer JSON (De)Serialization methods, nonreflective. Let me close out this thread and send a new message your way for a bit of clarification on behavior of System.Text.Json. TY!

Pls see this question: https://learn.microsoft.com/en-us/answers/questions/5911779/question-about-json-(de)serialization-using-system

TY!!