WinRT originate error - 0x80040111 : 'Windows.ApplicationModel.LimitedAccessFeatures'.

Question

WinRT originate error - 0x80040111 : 'Windows.ApplicationModel.LimitedAccessFeatures'.

Hong 1,661

If I start a WinUI app in the debug mode (i.e., F5 in VS 2026), it always throws the following exception at the start:

Exception thrown at 0x00007FF9F86E41CA (KernelBase.dll) in MyAppr.exe: WinRT originate error - 0x80040111 : 'Windows.ApplicationModel.LimitedAccessFeatures'.

However, I can continue to run the app. I have not noticed any problems with the app.

I did a global search for "LimitedAccessFeatures", but could not find any.

I have the following in the app:

using Windows.ApplicationModel;
using Windows.ApplicationModel.Activation;
using Windows.ApplicationModel.DataTransfer;

They are for the share UI (DataTransferManagerInterop) and app activation by a file (IFileActivatedEventArgs). Both functions work properly without any issues.

Could anyone shed some light on the 0x80040111 error?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @Hong ,

0x80040111 is CLASS_E_CLASSNOTAVAILABLE, meaning "ClassFactory cannot supply requested class" (Microsoft's error-code reference). WinRT can report an error to the debugger through a structured exception, as described in RoOriginateError. So this notification alone does not mean the application has an unhandled exception or that the overall operation failed.

If sharing and file activation succeed, the app continues normally, and no exception propagates into your application code, you can treat this as a nonfatal debugger diagnostic for now. No application code change is needed solely to remove this message.

If you prefer to hide it after confirming that behavior, select Debug in the Output window's Show output from list, right-click inside the pane, and clear Exception Messages (the same setting is under Tools > Options > Debugging > Output Window), as described in The Output window while debugging with Visual Studio. This filters exception messages generally; it does not change application behavior or the debugger's break settings.

I reproduced the notification with a C# factory lookup on Windows 11 build 26200.9457, x64, using the .NET 10.0.12 runtime (SDK 10.0.401). With a native debugger attached, requesting the factory for Windows.ApplicationModel.LimitedAccessFeatures produced 0x80040111, but the call returned 0x00000000 (S_OK) and the process exited with code 0. Microsoft documents S_OK as a successful RoGetActivationFactory call.

A blank WinUI app using Windows App SDK 1.7.250909003 and the .NET 8.0.31 runtime, unpackaged, also ran successfully with and without a native debugger. Its debugger run did not produce the LAF notification. The factory test reproduces the message, but it does not identify the startup caller in your app.

This screenshot combines the recorded results, a code excerpt, and the relevant Microsoft documentation; it is a local test report, not Visual Studio output.

Factory lookup results, four comparisons, C# code, and Microsoft documentation

The console output was:

Factory result: 0x00000000
Execution continued after the lookup.

LimitedAccessFeatures manages access to features requiring Microsoft-issued IDs and tokens. The notification does not establish that your app needs a token. A dependency or Windows component could be calling it internally, but a call stack is needed to identify which one.

If you would like to trace the startup caller, you can capture a native call stack:

Stop debugging, open the project's Debug properties, and select Open debug launch profiles UI. Under Enable native code debugging, enable debugging for managed and native code together (Microsoft's mixed-mode debugging instructions).
In Tools > Options, open the Symbols settings and enable Microsoft Symbol Servers in the symbol search locations (Microsoft's symbol settings instructions).
Start debugging again. When the notification pauses execution, open Debug > Windows > Call Stack, select Show External Code, and copy the stack before continuing. If symbols are missing, use Load Symbols for the affected frames (Microsoft's Call Stack instructions).

If the notification only appears in Output without pausing, complete steps 1 and 2, then open Debug > Windows > Exception Settings. Under Win32 Exceptions, select 0x40080201 (WinRT originate error) to break when thrown; add it with that code and description if it is not listed (Microsoft's exception settings instructions). Restart debugging and follow step 3 when the message names Windows.ApplicationModel.LimitedAccessFeatures. Here, 0x40080201 is the native notification code observed in the test, while 0x80040111 is the HRESULT carried by it.

If you have a chance, feel free to share that stack, your Windows build, and the Microsoft.WindowsAppSDK package version. These details will help identify the caller before deciding whether any application change is needed.

Gatlin Le (WICLOUD CORPORATION) 805 Reputation points Microsoft External Staff Moderator

2026-10-05T02:10:56.58+00:00

Hi @Hong ,

Thank you for sharing the stack trace. I understand your concern about whether this message could point to an underlying problem even though your applications run normally.

A "WinRT originate error" message does not, by itself, mean that the application has an unhandled exception. Microsoft's RoOriginateError documentation explains that WinRT reports an error code r by raising a structured exception. The debugger can display this notification, or pause on it, even when the calling code handles the condition afterward.

In your stack, the call path runs through WinUI/XAML (Microsoft.UI.Xaml.dll), Windows composition (dcomp.dll / dcompi.dll), and COM (combase.dll) before reaching Windows.ApplicationModel.dll, where 0x80040111 (CLASS_E_CLASSNOTAVAILABLE) frames come from your application code. This also explains why the same message appears in all of your WinUI applications, since they share the same framework and platform code.

Given that your applications behave normally, this message reflects an error reported to the debugger during framework startup. Based on the stack and the behavior you described, it does not indicate a failure in your application code. If you ever notice a functional problem that occurs together with this message, that would be worth looking into separately.
Hong 1,661 Reputation points

2026-10-05T02:47:58.41+00:00

Thank you for all the tips.