Powershell: Set-Property HKCU:\ Registry Provider No Longer works on 7.1.0

[watersb]

Steps to reproduce

A neat trick to set Dark Mode on Windows 10, works on PowerShell 5.1 and on PowerShell 7.0.0

  Set-ItemProperty `
  -Name SystemUsesLightTheme `
  -Value 0 `
  -Path  HKCU:\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize

Expected behavior

The registry key value should change, and Windows 10 changes the system appearance (Window title bars, toolbars, Explorer views

You can also see this property change its value by inspecting it with RegEdit. Using the REG.EXE command from the shell inspects this value:

>  reg.exe query HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize
    ColorPrevalence    REG_DWORD    0x0
    EnableTransparency    REG_DWORD    0x1
    AppsUseLightTheme    REG_DWORD    0x0
    SystemUsesLightTheme    REG_DWORD    0x1

Actual behavior

PowerShell Get-Property retrieves the modified value as expected. But the actual value in the Registry remains unchanged, and the Windows system appearance does not change.

> Get-ItemProperty -name SystemUsesLightTheme    -Path  HKCU:\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize

SystemUsesLightTheme : 0
PSPath               : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Softwar
                       e\Microsoft\Windows\CurrentVersion\Themes\Personalize
PSParentPath         : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Softwar
                       e\Microsoft\Windows\CurrentVersion\Themes
PSChildName          : Personalize
PSDrive              : HKCU
PSProvider           : Microsoft.PowerShell.Core\Registry


> reg.exe query HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize
    ColorPrevalence    REG_DWORD    0x0
    EnableTransparency    REG_DWORD    0x1
    AppsUseLightTheme    REG_DWORD    0x1
    SystemUsesLightTheme    REG_DWORD    0x1

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0-preview.1
PSEdition                      Core
GitCommitId                    7.1.0-preview.1
OS                             Microsoft Windows 10.0.19041
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[NoMoreFood]

I cannot reproduce this issue on 7.1.0-preview.1 (64-bit). Can you search all of HKCU for SystemUsesLightTheme to see if it's getting set somewhere else?

[watersb]

The only other instance of this property is in the HKU\, as displayed in RegEdit.

Computer\HKEY_USERS\S-1-5-21-...\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize

This is an interesting bug for me because it's reproducible on this laptop, and seems like flipping a bit that should work but doesn't.

Tomorrow I will try this on some other Win10 devices. This one is a little HP Stream 11 Pro G4 EE.

I can grab some screen shots with Steps Recorder, if that would help.

Thanks for the suggestions, Hmm...

[watersb]

Was able to reproduce the issue on an x86 (32-bit) Windows 10 1863.

PowerShell 5 - the registry property is changed, and the Windows user
interface switches dark/light mode.

PowerShell 7.1 preview - the registry provider acts as if it is changing
the property value, get/set stays consistent there (you get the same value
that you just set), but the registry is not changed and the Windows UI mode
does not change.

Is there a Windows system image (virtual machine) that I should be testing
against?

I am using the package from GitHub releases, in particular the MSIX
AppPackage for Windows x86 or x86_64.

[vexx32]

@watersb there are known issues with the MSIX package being sandboxed by the OS, so I'm guessing that's likely to be your issue. Until the PS team are able to nail down exactly how to workaround the builtin sandboxing for MSIX apps in an approved fashion, you're likely to have that issue with the MSIX version.

[watersb]

Yes, I began to suspect the packaging method was a factor, after I could
reproduce the issue on my x86 tablet yet others were not seeing this
problem.

Thanks for following up with that info. MSIX is interesting.

[watersb]

This actually WORKSFORME on 7.1.0-preview2 when I switched away from the MSIX - packaged distribution.

[adityapatwardhan]

MSIX is not a supported package at this time. It will be available in the Microsoft Store and we will clarify our position then.

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.