secureuxtheme_uninstall(00000008) returned 80070002

[rodolfol95]

Just after this Commits on Jan 28, 2023

[Separate main logic into a library with C FFI interface 

if I run themetool and try to install it throws me that error last working version was 12/14/22

[Casstastrophe]

This is because the January 28 commits included a change to which error codes are accepted when renaming system colors. Prior to the change, both success and "ERROR_PATH_NOT_FOUND" (the 0x80070002 error code you're hitting) were accepted: https://github.com/namazso/SecureUxTheme/blob/b99225316ee125d391e717c13f5a49d0abbdf8f5/ThemeTool/MainDialog.cpp#L428 but after the change only success is accepted: https://github.com/namazso/SecureUxTheme/blob/e7cba5ebd5a163ac0f5436b701bd279805554b00/ThemeLib/install.cpp#L586.

This normally would be fine, since the new code checks if a DefaultColors key exists at all before bothering to rename it, but it seems to be interleaving WOW64_32 registry keys with normal keys. On my system the verification method correctly identified DefaultColors keys under HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Themes\DefaultColors, but then attempts to delete keys from HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\DefaultColors, and fails out when that key doesn't exist.

On previous versions, only the standard registry keys were ever accessed for DefaultColors:

I was able to get around this by manually deleting both the DefaultColors and DefaultColors_Backup keys from both locations, since it won't bother trying to delete DefaultColors if it can't find any existing versions of it. DefaultColors_Backup needs to be deleted as well since the install process starts by running the uninstall process, which renames the backup keys to DefaultColors, causing the above issue. Deleting both will get a successful install.

[rodolfol95]

Oddly I just got a fresh installation of Windows and needed to use your tool still not working latest version

1684550534446 > secureuxtheme_uninstall(00000008) returned 80070057

[rodolfol95]

This is because the January 28 commits included a change to which error codes are accepted when renaming system colors. Prior to the change, both success and "ERROR_PATH_NOT_FOUND" (the 0x80070002 error code you're hitting) were accepted:

https://github.com/namazso/SecureUxTheme/blob/b99225316ee125d391e717c13f5a49d0abbdf8f5/ThemeTool/MainDialog.cpp#L428

but after the change only success is accepted: https://github.com/namazso/SecureUxTheme/blob/e7cba5ebd5a163ac0f5436b701bd279805554b00/ThemeLib/install.cpp#L586

. This normally would be fine, since the new code checks if a DefaultColors key exists at all before bothering to rename it, but it seems to be interleaving WOW64_32 registry keys with normal keys. On my system the verification method correctly identified DefaultColors keys under HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Themes\DefaultColors, but then attempts to delete keys from HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\DefaultColors, and fails out when that key doesn't exist.

On previous versions, only the standard registry keys were ever accessed for DefaultColors:

I was able to get around this by manually deleting both the DefaultColors and DefaultColors_Backup keys from both locations, since it won't bother trying to delete DefaultColors if it can't find any existing versions of it. DefaultColors_Backup needs to be deleted as well since the install process starts by running the uninstall process, which renames the backup keys to DefaultColors, causing the above issue. Deleting both will get a successful install.

For me both keys exist which one it's the right to be deleted WOW6432Node or the regular route still I did a clean windows install on a brand new pc and still having 1684550534446 > secureuxtheme_uninstall(00000008) returned 80070057 when using latest version