Packaged wasdk app can't even read correct registry value?

[HO-COOH]

Describe the bug

So I am using RegGetValue() to poll registry values. And when changes are made to the value, the polling result returned is completely unpredictable in wasdk packaged app

Steps to reproduce the bug

1. Create a C++ winui3 packaged app (without a Windows application packaging project)
2. Add this code in MainWindow.xaml constructor

        MainWindow()
        {
			std::thread{ [] {
				while (true)
				{
					DWORD value;
					DWORD size = sizeof(value);
					RegGetValueW(
						HKEY_CURRENT_USER,
						LR"(Software\Microsoft\Windows\DWM)",
						L"AccentColor",
						RRF_RT_REG_DWORD,
						nullptr,
						&value,
						&size
					);
					OutputDebugString(std::format(L"{}\n", value).data());
					Sleep(1000);
				}
			} }.detach();
        }

3. Use the same code in a C++ console application project
4. Build and run both, now go to windows personalization settings, change the accent color, observe the output from both. See how they diverge. Open up a regedit you can see the console application is returning the correct result.

Expected behavior

No response

Screenshots

NuGet package version

Windows App SDK 1.6.3: 1.6.250108002

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 24H2 (22621, October 2024 Update)

IDE

Visual Studio 2022

Additional context

At this point, I don't even know what to expect. I thought at least polling should work for me to workaround #4075

Repro

[DarranRowe]

Have you tried ths in a packaged console application or packaged Windows API application that doesn't reference the Windows App SDK?

[HO-COOH]

@DarranRowe I just tried, it works as expected on a packaged console application (although it completely make no sense to package a console application). See my repro in OP

[DarranRowe]

@HO-COOH Maybe it doesn't make any sense. It does do something important, that is to test the packaging itself to remove that from the equation.

However:

4292114432
4292114432
4292114432
4292114432
4291016448
4291016448
4292114432
4292114432
4292114432
4292114432
4292114432
4291016448
4291016448
4292114432
4292114432
4292114432
4292114432

It is changing as expected for me. This is Windows 11 26100.

[HO-COOH]

@DarranRowe Which project is working on your machine?

[DarranRowe]

@HO-COOH

Okay, correction, I got it to trigger, but this is a Windows problem for sure.

If you open up a powershell window and then run Invoke-CommandInDesktopPackage with your package's PFN, AppID and the command being set to regedit.exe, you will notice that the DWM key is in synch with what is displayed in the application. For some reason, it is flushing the registry key to the package's storage and that is getting out of synch. I guess this is why ColorValuesChanged is marked as unsupported.

I'll try to get a guaranteed Windows API reproduction soon, but it is very difficult to get this to trigger in a console application.

[mominshaikhdevs]

although it completely make no sense to package a console application

microsoft/winget-cli#4260 (comment)
(/#5155 (comment))

[DrusTheAxe]

although it completely make no sense to package a console application

It makes perfect sense. Focus less on the console part of your statement and more on the application

[HO-COOH]

@mominshaikhdevs @DrusTheAxe This is not relevant to OP issue, but I said so because msix packaging have already given me plenty of headache. I would stay away from it whenever possible. Data virtualization/isolation, good, I can bare with that, on the premise of a clear documentation, ease of development and good compatibility. And msix so far has not achieved any of these three points:

1. clear documentation: If there is, why are you guys explaining over and over again?
2. ease of development: Wait, where is my headache coming from?
3. good compatibility: WinUI3 is compatible all the way to 17763. Meanwhile, does all msix packaging features supports 17763? Clearly nope

Console application is the easiest type of project to NOT using packaging. WinUI3, harder, but still possible. But I am lazy, you know, people are always lazy. And since there is only packaged project templates for winui3, I might as well use it.

[DarranRowe]

Okay, I didn't manage to get things done. But to give some reasoning why this isn't expected to consistantly work in the first place.

1. The key that is being read is an undocumented value in an undocumented key under a reserved key in the registry. This is unsupported at best.
2. As stated in Understanding how packaged desktop apps run on Windows, "All writes under HKCU are copied on write to a private per-user, per-app location.". I believe after that point, all reads will come from that virtualised location. It is unspecified if a Microsoft library writes to a reserved key, and it isn't that surprising if a library related to DWM writes to the DWM key. While your code may not directly use anything related to DWM, WinUI 3 does. WinUI 3 uses its own implementation of the Visual Layer, and this is a way to access DWM.

The biggest issue is that application packaging is a Windows feature. The registry virtualisation is part of the core packaging functionality and the switch to disable it is also part of the core packaging functionality. So this is a Windows issue.

[HO-COOH]

@DarranRowe So, from your statement, I can conclude that, reading from majority (like literally everything except those created by my application by myself) is undocumented and therefore, unpredictable. Like, how can this even be acceptable?
Complaint aside, the link mentioned nowhere about reading from HKCU. I am only reading, not writing, how is that unpredictable? And if winui3 does access to DWM and have something to do with that key, isn't right here the place to ask?

[DarranRowe]

@HO-COOH

So, from your statement, I can conclude that, reading from majority (like literally everything except those created by my application by myself) is undocumented and therefore, unpredictable. Like, how can this even be acceptable?

Why do you believe that the alternative should be true? Your application can, and should, only ever have control over its own registry keys and files. There is no reason for Windows to try too hard to satisfy people who want to do undocumented things. Microsoft always reserves the right to just outright change these keys and values in a way that will cause your application to crash.

Complaint aside, the link mentioned nowhere about reading from HKCU. I am only reading, not writing, how is that unpredictable?

You may only be writing code to read from the registry, but if a Microsoft library used by the application writes to the registry, then it will appear to come from your application. It is unspecified whether or not a Microsoft library will write to a reserved key. Of course, after the key is written to from the package, any reads will come from the redirected key. So it is unpredictable because it is undocumented as to whether a library will write to reserved keys in the registry.

And if winui3 does access to DWM and have something to do with that key, isn't right here the place to ask?

Maybe, but the same thing will be true. Why would it be a bug for a Microsoft library to write to the Microsoft reserved portion of the registry?

[HO-COOH]

@DarranRowe OK, so, using packaged winui3 app, it's impossible to do something as trivial as getting the current system theme (and my usage is simply to fix the broken caption button color that I shouldn't even be doing in the first place). That sounds like very promising, developers definitely should consider adopting it

[RDMacLachlan]

@HO-COOH ,

Would the following help with your use scenario: microsoft/microsoft-ui-xaml#10056 ?