Can't delete registry keys within HKCR during OOBE

N

NCSGeek

Member
Messages
43
Reaction score
8
Hello. I have a script that runs post-setup that deletes some registry keys:
@"HKEY_LOCAL_MACHINE\Software\Classes\DesktopBackground\Shell\Personalize",
@"HKEY_LOCAL_MACHINE\Software\Classes\DesktopBackground\Shell\Display",
@"HKEY_CLASSES_ROOT\AppXzwr976v2e060wada4gabrk1x69h2dbwy\shell",
@"HKEY_CLASSES_ROOT\AppXhk4des8gf2xat3wtyzc5q06ny78jhkqx\shell",
@"HKEY_CLASSES_ROOT\AppX4ztfk9wxr86nxmzzq47px0nh0e58b8fw\shell"

The ones in HKLM work but not the last four in HKCR. Thing is, if I run this script as a user with admin permissions, it successfully removes all five. So obviously something is going on where somehow the environment during OOBE/Post-setup is causing this.

Can anyone help?
 
HKEY_CLASSES_ROOT is a virtual registry path, it works much like HKEY_CURRENT_USER.

1. HKCU points to the current user's profile. If you're a different user, then Windows loads a different reg hive as HKCU.

2. HKCR is a blend of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes. If there are duplicated subkeys, the HKCU version always wins.

When you run any task from Post-Setup (Before logon), it runs as SYSTEM. The HKCU would be SYSTEM's profile, and you're trying to delete keys from either SYSTEM's profile (first) or HKLM.

When you run from Post-Setup (After logon), it runs as you but with Admin rights. The HKCU would be your own profile. That's the subtle distinction between the two options.
 
garlin said:
HKEY_CLASSES_ROOT is a virtual registry path, it works much like HKEY_CURRENT_USER.

1. HKCU points to the current user's profile. If you're a different user, then Windows loads a different reg hive as HKCU.

2. HKCR is a blend of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes. If there are duplicated subkeys, the HKCU version always wins.

When you run any task from Post-Setup (Before logon), it runs as SYSTEM. The HKCU would be SYSTEM's profile, and you're trying to delete keys from either SYSTEM's profile (first) or HKLM.

When you run from Post-Setup (After logon), it runs as you but with Admin rights. The HKCU would be your own profile. That's the subtle distinction between the two options.
Click to expand...
Thank you for your reply. So are you saying that if I run this script after logon, it'll work?
 
Last edited:
These are related to the default Apps (ie. Notepad)? Have you removed or disabled the User Choice Protection Driver? It's probably blocking changes to File Type Associations owned by an UWP app.

SYSTEM would have rights, but UCPD would block Admin users.
 
garlin said:
These are related to the default Apps (ie. Notepad)? Have you removed or disabled the User Choice Protection Driver? It's probably blocking changes to File Type Associations owned by an UWP app.

SYSTEM would have rights, but UCPD would block Admin users.
Click to expand...
Yes, these are context menu entries from Notepad (edit, print, printto). As for User Choice Protection Driver, I doubt I disabled it since I dont really touch the drivers section but you can have a look at my preset here.

I tried deleting HKEY_CURRENT_USER\Software\Classes\AppXzwr976v2e060wada4gabrk1x69h2dbwy\Shell\Edit while logged in and that did not delete the context menu entry. Only deleting the HKCR key seems to do that.

I appreciate your time and help. Overall it's a minor thing but I appreciate it. It's the last thing I really need to fix with my preset/image.

edit:
I'll add that I tried deleting these keys instead as well but as I said above, only deleting the HKCR ones seem to work.

HKEY_LOCAL_MACHINE\Software\Classes\AppXzwr976v2e060wada4gabrk1x69h2dbwy\shell
HKEY_LOCAL_MACHINE\Software\Classes\AppXhk4des8gf2xat3wtyzc5q06ny78jhkqx\shell
HKEY_LOCAL_MACHINE\Software\Classes\AppX4ztfk9wxr86nxmzzq47px0nh0e58b8fw\shell
 
Last edited:
UCPD is a sneaky service masquerading as a kernel driver. It only has one mission: to block specific reg changes related to Taskbar and File Type Associations (for security reasons). Because it works at the kernel level, it can block processes with Admin rights.

You need to disable it from Services (or remove the entire component if you have licensed NTLite).
 
garlin said:
UCPD is a sneaky service masquerading as a kernel driver. It only has one mission: to block specific reg changes related to Taskbar and File Type Associations (for security reasons). Because it works at the kernel level, it can block processes with Admin rights.

You need to disable it from Services (or remove the entire component if you have licensed NTLite).
Click to expand...
I can definitely try that. (I do have a license)

Although why would it work when logged in if it was a windows component blocking it? Does that component not in effect during that time?
 
I had a different thought, when running the script from (After logon) we get a race condition where Windows isn't done with UWP app provisioning.

When a new account is created, nothing interesting happens until the first desktop logon. Windows finally does the new user provisioning, which includes setting up all the default Apps (UWP). This provisioning is partially complete by the time you see the desktop. If you have ever tried clicking the Store app, or Paint immediately as soon as the desktop appears, you will notice it doesn't work.

The app isn't completely configured for your user profile. The process is continuing in the background, rather than force you to wait a few more minutes before you see a desktop. The (After logon) task is firing off, and since we're in the middle of user provisioning, it's not guaranteed which one (task or provisioning) runs last.

If you run your reg script on an already provisioned account, it removes the keys.

If your script runs, and provisioning isn't finished, then it may undo or ignore your changes. In theory, adding a programmed delay before applying the reg script would always mean it works. But that's not really practical for anyone.

The only to force it would be to force register those apps, just so you can remove their reg keys right afterwards.

New.bat:
Code: 
@echo off
powershell Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.Notepad_8wekyb3d8bbwe
powershell Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.Paint_8wekyb3d8bbwe

reg delete ...
 
garlin said:
I had a different thought, when running the script from (After logon) we get a race condition where Windows isn't done with UWP app provisioning.

When a new account is created, nothing interesting happens until the first desktop logon. Windows finally does the new user provisioning, which includes setting up all the default Apps (UWP). This provisioning is partially complete by the time you see the desktop. If you have ever tried clicking the Store app, or Paint immediately as soon as the desktop appears, you will notice it doesn't work.

The app isn't completely configured for your user profile. The process is continuing in the background, rather than force you to wait a few more minutes before you see a desktop. The (After logon) task is firing off, and since we're in the middle of user provisioning, it's not guaranteed which one (task or provisioning) runs last.

If you run your reg script on an already provisioned account, it removes the keys.

If your script runs, and provisioning isn't finished, then it may undo or ignore your changes. In theory, adding a programmed delay before applying the reg script would always mean it works. But that's not really practical for anyone.

The only to force it would be to force register those apps, just so you can remove their reg keys right afterwards.

New.bat:
Code: 
@echo off
powershell Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.Notepad_8wekyb3d8bbwe
powershell Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.Paint_8wekyb3d8bbwe

reg delete ...
Click to expand...
Interesting. I had a feeling it must've been something like that. I appreciate the insight, for now I made my script make a one-time scheduled task to cleanup the extra keys on next user logon and that works fine, though a delay would probably be cleaner if I could ge the timing right (or detect when provisioning is finished?)
 
The PS command immediately registers the named app, instead of allowing Windows to eventually catch up to it. I use that technique to force winget to be usable in a script, otherwise it's the same problem of waiting for an indeterminate delay.
 
You must log in or register to reply here.
Back
Top