ObservableCollection does not work for Microsoft Store version while working for debug version

Question

ObservableCollection does not work for Microsoft Store version while working for debug version

Hong 1,661

The following code is solely for debugging.

Xaml:

        <ListView x:Name="listViewTest"/>

C#:

                var folders = new ObservableCollection<string>
                    {
                        "OBS 1",
                        "OBS 2",
                        "OBS 3"
                    };

                listViewTest.ItemsSource = folders;

This works exactly as expected if the WinUI app is started from VS2026, but the store version built by VS2026 shows nothing.

The following works for both the debug version and the store version:

                var folders = new c<string>
                    {
                        "OBS 1",
                        "OBS 2",
                        "OBS 3"
                    };

                listViewTest.ItemsSource = folders.ToList();

My app has a slightly complex list, and it works flawlessly with the debug version, but not with the store version. It took me many hours to narrow it down to ObservableCollection.

Could anyone shed some light on this?

User's image

0 comments

Answer accepted by question author

Jay Pham (WICLOUD CORPORATION) 4,680 Microsoft External Staff Moderator

Hi @Hong

Thank you for providing the additional information, call stack, and clarification about the use of ToList().

The available evidence does not yet confirm that ObservableCollection itself is the root cause. The exception is a native access violation followed by a fail-fast in Microsoft.UI.Xaml, while the supplied call stack contains only unresolved native addresses.

However, I tested the shared App1 project and found the following workaround while keeping the original ObservableCollection code unchanged.

I added these properties to the project file:


<PropertyGroup>

  <WindowsPackageType>None</WindowsPackageType>

  <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>

  <EnableMsixTooling>true</EnableMsixTooling>

  <PublishTrimmed>false</PublishTrimmed>

</PropertyGroup>

I then deleted the existing bin and obj directories and generated a fresh Release x64 publish. With this configuration, the application remained open and responsive, and the ListView displayed the original ObservableCollection without converting it to a List.

Disabling PublishTrimmed alone did not resolve the issue in my test. Adding only the Windows App SDK deployment properties also did not resolve it. The application worked when both changes were applied together.

Microsoft documents that .NET self-contained deployment and Windows App SDK self-contained deployment require separate configuration:

Windows App SDK deployment guide for self-contained apps

A similar published WinUI failure with exception code 0xC000027B was resolved using these Windows App SDK deployment properties:

WinUI 3 published unpackaged self-contained app crashes immediately

Please note that WindowsPackageType=None applies to the unpackaged App1 project you shared. I suggest testing this workaround in the same minimal project first. The Microsoft Store project's packaged configuration should be reviewed separately before applying this property to production.

Please let me know whether the newly published App1 build works with this combined configuration.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Jay Pham (WICLOUD CORPORATION) 4,680 Reputation points Microsoft External Staff Moderator

2026-09-17T00:49:38.99+00:00
Hi @Hong ,

I am glad to hear that adding the Microsoft.Windows.CsWinRT NuGet package resolved the packaged WinUI issues while allowing your application to continue using ObservableCollection.

C#/WinRT provides the projection and marshaling layer between C#/.NET and Windows Runtime APIs, including generic collections. Although WinUI receives this support transitively, adding the package directly can make NuGet select and package an explicit C#/WinRT version. This can correct the projection used by the packaged Release build without changing the collection itself.

Based on your validation, the practical resolution is:

dotnet add package Microsoft.Windows.CsWinRT

After adding it, clean bin and obj, restore the project, and create a fresh Release package. I also recommend pinning the version that you tested successfully.

This confirms that replacing ObservableCollection with ToList() is unnecessary. It does not show that ObservableCollection itself was defective; the result instead points to a C#/WinRT projection or dependency-version issue in the packaged build. C#/WinRT documentation

Thank you again for testing this and sharing the resolution with the community.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

1 additional answer

Your answer

Jay Pham (WICLOUD CORPORATION) 4,680 Reputation points Microsoft External Staff Moderator

2026-09-17T00:49:38.99+00:00

Hi @Hong ,

I am glad to hear that adding the Microsoft.Windows.CsWinRT NuGet package resolved the packaged WinUI issues while allowing your application to continue using ObservableCollection.

C#/WinRT provides the projection and marshaling layer between C#/.NET and Windows Runtime APIs, including generic collections. Although WinUI receives this support transitively, adding the package directly can make NuGet select and package an explicit C#/WinRT version. This can correct the projection used by the packaged Release build without changing the collection itself.

Based on your validation, the practical resolution is:

dotnet add package Microsoft.Windows.CsWinRT

After adding it, clean bin and obj, restore the project, and create a fresh Release package. I also recommend pinning the version that you tested successfully.

This confirms that replacing ObservableCollection with ToList() is unnecessary. It does not show that ObservableCollection itself was defective; the result instead points to a C#/WinRT projection or dependency-version issue in the packaged build. C#/WinRT documentation

Thank you again for testing this and sharing the resolution with the community.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Answer 1

Jay Pham (WICLOUD CORPORATION) 4,680 Microsoft External Staff Moderator

I am working the issue and will provide an update soon. Thank you for your patience.

Hong 1,661 Reputation points

2026-09-11T02:08:58.9+00:00

Thanks a lot for the help.

I am trying to migrate my UWP apps to WinUI for the 3rd time. I tried twice and found WinUI unstable and unpredictable. I have just started to use VS 2026 and am hoping WinUI has improved. I read that AOT is more predictable than .Net Native.
Jay Pham (WICLOUD CORPORATION) 4,680 Reputation points Microsoft External Staff Moderator

2026-09-11T02:29:00.7533333+00:00
Hi @Hong ,

Thank you for sharing that context. I understand how frustrating it must be to encounter another issue on your third attempt to migrate from UWP to WinUI.

To help narrow down this specific issue, could you confirm whether Native AOT is enabled in your current WinUI project, or whether you are considering using it? If you’re unsure, please share your .csproj and publish profile with sensitive information removed.

Could you also check whether the ListView is empty when:

Running Release in Visual Studio.

Installing a Release MSIX package locally, without going through Microsoft Store.

Those results will help us distinguish a build/publish configuration issue from something specific to the Store-installed package.
Hong 1,661 Reputation points

2026-09-11T03:16:25+00:00
I was so confused that I thought AOT was used automatically.

This is from the project file:

<PropertyGroup>  <PublishReadyToRun Condition="'$(Configuration)' == 'Debug'">False</PublishReadyToRun> <PublishReadyToRun Condition="'$(Configuration)' != 'Debug'">True</PublishReadyToRun>  <PublishTrimmed Condition="'$(Configuration)' == 'Debug'">False</PublishTrimmed> <PublishTrimmed Condition="'$(Configuration)' != 'Debug'">True</PublishTrimmed> <SupportedOSPlatformVersion>10.0.19041.0</SupportedOSPlatformVersion> </PropertyGroup>

My original question shows ALL the code involving listViewTest, so I am not sure what you mean by "whether the ListView is empty".

After hours of debugging this issue, I realized that the version published to the Microsoft Store behaves exactly the same as the version installed using the submitted app package (i.e., the .msixbundle file), so I have been testing the store version by installing the package locally to save time.

BTW, I should have mentioned that both the release and debug versions started by VS 2026 work flawlessly. Only the store version has this issue.
Jay Pham (WICLOUD CORPORATION) 4,680 Reputation points Microsoft External Staff Moderator

2026-09-11T06:23:01.09+00:00
Hi @Hong ,

Thank you for clarifying, and sorry my earlier question was unclear. I understand now that both Debug and Release work when launched from Visual Studio, while the published package fails whether installed locally or from the Store.

PublishReadyToRun enables ReadyToRun compilation, which is different from Native AOT. The setting I would investigate first is PublishTrimmed, since trimming happens during publishing and can introduce runtime issues. This is a hypothesis to test, not a confirmed cause. learn.microsoft.com

Could you temporarily change your existing non-Debug trimming setting to:

<PublishTrimmed Condition="'$(Configuration)' != 'Debug'">False</PublishTrimmed>

Please leave PublishReadyToRun unchanged, ensure the publish profile does not override this setting, then clean/rebuild and generate a fresh package. Installing it locally is sufficient for this test—there is no need to submit it to the Store.

Does the ObservableCollection example display correctly with that package?

Also, your comment mentions that trimming must remain enabled to avoid crashes. Have you actually encountered a crash with trimming disabled, or was that comment included in the template? If you encountered one, please share the error details.

Thank you.
Hong 1,661 Reputation points

2026-09-11T09:56:32.6533333+00:00

The comment about the crash was a result of spending days debugging the mystery store version crash last year. I confirmed the crash by reproducing it five times in a row with PublishTrimmed disabled yesterday.
Hong 1,661 Reputation points

2026-09-13T00:39:53.8+00:00
I used VS2026 to create a new app and used all the default settings. Added a blank page, then added a ListView to the page. Everything worked as expected (debug, release, and packaged versions all worked).

As soon as I added the following code, the packaged version crashes.

var folders = new ObservableCollection<string> { "OBS 1", "OBS 2", "OBS 3" }; listViewTest.ItemsSource = folders;
Jay Pham (WICLOUD CORPORATION) 4,680 Reputation points Microsoft External Staff Moderator

2026-09-14T04:03:23.2933333+00:00

Hi @Hong

Thank you for providing the minimal reproduction and additional screenshot. I understand that the app targets .NET 10.0 and works in Debug and Release from Visual Studio, but the installed package crashes after assigning an ObservableCollection<string> to ListView.ItemsSource.

I also noted that you have already tested with PublishTrimmed disabled, so there is no need to repeat that test.

To identify the cause, please use Visual Studio > Debug > Other Debug Targets > Debug Installed App Package, reproduce the crash, and share the first exception message and call stack.

Please also provide the exact Visual Studio version, Microsoft.WindowsAppSDK version, and package architecture (x64, x86, or ARM64).

Thank you.

Hong 1,661

Here are the first few exceptions.

Exception thrown at 0x00007FFBE64F2F61 in App1.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
Exception thrown at 0x00007FFCCBFC41CA (KernelBase.dll) in App1.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
Unhandled exception at 0x00007FFC4F9F9C5D (Microsoft.ui.xaml.dll) in App1.exe: 0xC000027B: An application-internal exception has occurred (parameters: 0x000002A9BDD10640, 0x0000000000000003).
Unhandled exception at 0x00007FFCCCB92200 (combase.dll) in App1.exe: 0xC0000602:  A fail fast exception occurred. Exception handlers will not be invoked and the process will be terminated immediately.
Unhandled exception at 0x00007FFC4F9F9C5D (Microsoft.ui.xaml.dll) in App1.exe: 0xC000027B: An application-internal exception has occurred (parameters: 0x0000026925EF9EF0, 0x0000000000000002).

User's image

Here is the minimal project App1

Jay Pham (WICLOUD CORPORATION) 4,680 Reputation points Microsoft External Staff Moderator

2026-09-15T08:35:48.9533333+00:00
Hi @Hong ,

I acknowledge that you have already confirmed that disabling PublishTrimmed does not resolve the crash, and that the locally installed package behaves the same as the Microsoft Store version. There is no need to repeat those checks.

I also understand that converting the collection with ToList() allows the packaged application to display the items. This is currently a valid workaround, but I do not recommend treating it as confirmation that ObservableCollection itself is the root cause. The available output shows a native access violation followed by a 0xC000027B fail-fast in Microsoft.UI.Xaml, but it does not identify the operation that originally caused the failure.

The next diagnostic step is to capture the complete call stack from the exact installed package:

Open Visual Studio and select Debug > Other Debug Targets > Debug Installed App Package.

Select the installed App1 package and reproduce the issue.

When Visual Studio stops at the first access violation, select Show Call Stack.

Copy the complete Call Stack window, including native and external frames if available.

Confirm whether the installed package selected x64, x86, or ARM64 from the bundle.

Microsoft documents this procedure in Run, debug, and test an MSIX package: Debug your app

The complete call stack is needed to distinguish an ObservableCollection projection or XAML binding failure from a Windows App SDK runtime, package initialization, or another native WinUI path. If it identifies a Windows App SDK failure, I can use the supplied minimal project and stack trace as evidence for escalation to the product team.

In the meantime, you may continue using ToList() as a temporary workaround.

If you found my response helpful or informative, I would greatly appreciate it if you could provide feedback by interacting with the system or leaving a comment below.

Thank you.
Hong 1,661 Reputation points

2026-09-15T11:30:53.8766667+00:00
Here are the contents of the call stack window:
[Exception thrown at 0x00007FFBC8C72F61 in App1.exe: 0xC0000005: Access violation reading location 0x0000000000000000.]

00007ffbc8c72f61() Unknown

000001eb1b019618() Unknown 000001eb1b021558() Unknown 000001eb0000001a() Unknown 0000000a25f8d070() Unknown

I used ToList() just to make a point. As I stated in the first sentence of my original question, the posted code is solely for debugging. The actual code of my apps uses ObservableCollection extensively.
Hong 1,661 Reputation points

2026-09-16T11:42:17.67+00:00

Thank you for all your help. Could you turn your comment into an answer for me to accept?

I have found a magic wand that solves all the issues with packaged WinUI apps: CsWinRT. As soon as I installed the NuGet package Microsoft.Windows.CsWinRT, all the issues of Packaged WinUI apps were gone. I wish VS2026 added this package by default.