UWP app System.IO.FileLoadException: 'Could not find or load a specific file. (Exception from HRESULT: 0x80131621)'

Question

UWP app System.IO.FileLoadException: 'Could not find or load a specific file. (Exception from HRESULT: 0x80131621)'

Hong 1,526

When I run a UWP app in debugging mode, it always throws this exception at the start:

System.IO.FileLoadException
  HResult=0x80131621
  Message=Could not find or load a specific file. (Exception from HRESULT: 0x80131621)
  Source=System.Private.CoreLib
  StackTrace:
   at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type, ObjectHandleOnStack keepalive)
   at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName)

It does not seem to affect the app, so it is just a minor nuisance that I would like to get rid of.

It is thrown at the following method in XamlTypeInfo.g.cs:

        public global::Windows.UI.Xaml.Markup.IXamlType GetXamlTypeByName(string typeName)
        {
            return Provider.GetXamlType(typeName);
        }

Is there a way to get rid of it?

Hong 1,526 Reputation points

2026-05-07T12:44:15.32+00:00

Thank you for lending a hand.

I found out that the app, which is more than 10 years old, was somehow using

xmlns:winui="using:Microsoft.UI.Xaml.Controls"

The typeName that triggered the exception was Microsoft.UI.Xaml.Controls.StylesVersion.

Once I removed xmlns:winui="using:Microsoft.UI.Xaml.Controls" from App.xaml, the exception is gone.
Jay Pham (WICLOUD CORPORATION) 3,690 Reputation points Microsoft External Staff Moderator

2026-05-08T03:53:07.71+00:00

Hello @Hong,

I am glad the issue is resolved.

The exception was caused by an unnecessary WinUI namespace reference in App.xaml: xmlns:winui="using:Microsoft.UI.Xaml.Controls

That reference triggered type resolution for Microsoft.UI.Xaml.Controls.StylesVersion in a UWP app context. After removing that xmlns entry, the startup FileLoadException no longer occurs.

Answer accepted by question author

Jay Pham (WICLOUD CORPORATION) 3,690 Microsoft External Staff Moderator

Hello @Hong ,

I see this is most likely a first-chance exception that the debugger catches the runtime handles it internally, which is why the app continues to work fine.

To stop it from breaking into the debugger:

Press Ctrl+Alt+E to open Exception Settings.
Find System.IO.FileLoadException under Common Language Runtime Exceptions.
Uncheck it.

Could you also confirm whether the exception appears only in Debug, or also in a Release build with .NET Native enabled? If it shows up in Release, the fix is different it would involve adding a runtime directive to .rd.xml, and I can help with that.

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

0 comments

1 additional answer

Your answer

Hong 1,526 Reputation points

2026-05-07T12:44:15.32+00:00

Thank you for lending a hand.

I found out that the app, which is more than 10 years old, was somehow using

xmlns:winui="using:Microsoft.UI.Xaml.Controls"

The typeName that triggered the exception was Microsoft.UI.Xaml.Controls.StylesVersion.

Once I removed xmlns:winui="using:Microsoft.UI.Xaml.Controls" from App.xaml, the exception is gone.
Jay Pham (WICLOUD CORPORATION) 3,690 Reputation points Microsoft External Staff Moderator

2026-05-08T03:53:07.71+00:00

Hello @Hong,

I am glad the issue is resolved.

The exception was caused by an unnecessary WinUI namespace reference in App.xaml: xmlns:winui="using:Microsoft.UI.Xaml.Controls

That reference triggered type resolution for Microsoft.UI.Xaml.Controls.StylesVersion in a UWP app context. After removing that xmlns entry, the startup FileLoadException no longer occurs.

Answer 1

The exception is raised because the UWP XAML infrastructure is trying to resolve a type name at runtime (via reflection) and fails to load the corresponding implementation, even though the app continues to run. This is a tooling/runtime artifact and should not be handled with a try/catch in app code.

For .NET Native–compiled UWP apps, such issues are typically caused by missing runtime artifacts or metadata that the reflection-based XAML infrastructure expects to find. These are controlled by the .rd.xml runtime directives file. When a type or member is referenced only dynamically (for example, by name), the .NET Native toolchain may remove its implementation unless explicitly preserved.

To eliminate the exception instead of ignoring it:

Identify which type name is being resolved when the exception occurs (from the debugger or call stack around GetXamlTypeByName).
Add an appropriate runtime directive in the app’s .rd.xml file to preserve that type (or its containing namespace) with Activate or Dynamic policy so that both metadata and implementation are kept at runtime.
Rebuild and redeploy the app, then repeat until no further missing-runtime-artifact or metadata-related exceptions appear.

When adding directives, prefer specifying them at the namespace or type level (instead of individual members) to keep the app resilient to future code changes, at the cost of slightly larger binaries and longer compile times.

Do not try to “handle away” this exception in code; it indicates that the runtime has removed implementation code that XAML/reflection expects. The correct fix is to adjust the .rd.xml configuration so the required implementation is preserved.

References:

Share via

UWP app System.IO.FileLoadException: 'Could not find or load a specific file. (Exception from HRESULT: 0x80131621)'

1 additional answer

Your answer