Unable to write registry key/value

[RickC]

Windows 10 x64. I'm logged in with an account in the Administrators group and using AHK 1.1.24.01 Unicode 32-bit.

I can use this .REG file which works fine:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer]
"ShowDriveLettersFirst"=dword:00000004

When the file is double-clicked and merged I can see the key/value created immediately in Regedit.

I don't understand why I can't achieve the same result using this code snippet (part of a much longer Windows 10 configuration script):

Code: Select all

if not A_IsAdmin
{
   Run *RunAs "%A_ScriptFullPath%"  ; Requires v1.0.92.01+
   ExitApp
}

RegWrite, REG_DWORD, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer, ShowDriveLettersFirst, 0x00000004

What am I doing wrong?

[qwerty12]

I bet you it's in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Explorer

See if adding SetRegView 64 before the RegWrite does anything.

[RickC]

I bet you it's in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Explorer

See if adding SetRegView 64 before the RegWrite does anything.

Thank you so much! You were absolutely right. First time I've run into this before and it threw me completely.

As my overall script has dozens of registry writes, do I use SetRegView 64 once just before the first RegWrite then SetRegView Default after the last RegWrite or just before every RegWrite entry that needs it (with corresponding SetRegView Default after the RegWrite entry that needs it)? The help file doesn't mention this at all so I don't know if it's persistent or resets after each call.

[qwerty12]

Thank you so much! You were absolutely right. First time I've run into this before and it threw me completely.

Thank you for doing what many OPs do not and actually describing your environment ^-^

As my overall script has dozens of registry writes, do I use SetRegView 64 once just before the first RegWrite then SetRegView Default after the last RegWrite or just before every RegWrite entry that needs it (with corresponding SetRegView Default after the RegWrite entry that needs it)? The help file doesn't mention this at all so I don't know if it's persistent or resets after each call.

You should be good to go just calling SetRegView 64 once and the setting should stick with all Reg* commands, with one possible exception: if I'm reading the help page right, you should call it as early as possible (like near the top of your script) to ensure it takes effect everywhere in the script, because the setting won't propagate to new AutoHotkey threads that are already running beforehand (like from a timer function that was started prior to calling SetRegView).

As for setting the view back to Default, I'd say that's only needed in your case if you want to write to Keys in WOW6432Node without actually specifying WOW6432Node in every Key.

[RickC]

You should be good to go just calling SetRegView 64 once and the setting should stick with all Reg* commands, with one possible exception: if I'm reading the help page right, you should call it as early as possible (like near the top of your script) to ensure it takes effect everywhere in the script, because the setting won't propagate to new AutoHotkey threads that are already running beforehand (like from a timer function that was started prior to calling SetRegView).

As for setting the view back to Default, I'd say that's only needed in your case if you want to write to Keys in WOW6432Node without actually specifying WOW6432Node in every Key.

Thank you once again for your prompt, detailed and very easy-to-understand answer. Just what I needed.

Now all I have to do is work out how I can change ownership on a Windows Defender registry key using just AHK. Time to hit "Search"!

[qwerty12]

Now all I have to do is work out how I can change ownership on a Windows Defender registry key using just AHK. Time to hit "Search"!

To take your words at face-value, my answer is:
I wrote an installer script for myself to install the old, non-UWP Sticky Notes with Windows 10 AU and because I can't use dism for this, I at least settled on making sure the security descriptors matched what was in the manifest file for the SN package, so I have some small insight into this.
With pure AHK_L, it's, erm, a fun process. My only experience in Windows security thus far (reading a book on it and there's a really good set of articles on codeproject somewhere by a guy called oshah that I'm planning to take a look at soon) has been work I did on writing that installer, so while I wouldn't take my word as gospel and assume this is mistake-free, I do believe I have the basics down pat.

Assuming your script is elevated, it's something like first opening the process token, looking up the SeTakeOwnershipPrivilege and possibly (I'm not sure) the backup and restore privileges by name and adjusting the token. The user flipeador has some good stuff on that sort of thing. You may also find good stuff on the old forum. And then you get a handle to the Registry key in question (so you can't use the AHK Reg* functions - you need to DllCall RegOpenKeyEx etc. with ACCESS_SYSTEM_SECURITY := 0x01000000 | WRITE_DAC := 0x00040000 | WRITE_OWNER := 0x00080000)) and then you can pass the handle to the standard security functions. Since I'd be too lazy to work with the DACL structures, I'd look into duplicating the current SD, and DllCalling ConvertStringSecurityDescriptorToSecurityDescriptor with an SDDL that's pretty lenient, and then writing the new SD with the right function (in my case, this was SetKernelObjectSecurity since the SDDL I was working with defined all the aspects of the SD). Then as soon as I'm done writing, I'd restore the old SD right away

(If this is actually simpler than I'm making it sound, and someone just posts what you're asking for, due to my inexperience, I apologise in advance)

What I'd do instead:

Since the only reason I can think of to take ownership over Defender's keys is to disable it, I'd like to point out that Defender can be disabled by setting group policies for it. This can be done from the Registry, and I don't think those keys need control wrested from them. With my installer, what I did was use NSudo to start my AutoHotkey script with the TrustedInstaller token. I needed to write files with the owner set as TrustedInstaller, so I didn't have a choice. This way, I didn't need to take ownership of the keys beforehand and everything was nice and simple.

[RickC]

Thank you @qwerty12. Your very helpful previous reply was (mostly) so over my head that I would need a long ladder just to tickle your toes.

I have no wish to remove or disable 'Windows Defender'. I just want to switch off its privacy settings, i.e. that of 'Cloud-based Protection':

Code: Select all

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Spynet]
"SubmitSamplesConsent"=dword:00000000

and 'Automatic sample submission':

Code: Select all

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Spynet]
"SpyNetReporting"=dword:00000000

Basically, I've 'mapped' each and every 'Privacy' setting to its registry equivalent but these two resist my attempts to amend them.

I'm not very good at AHK scripting from scratch. I'm more of an AHK 'amender', i.e. I search for and amend others' code to my needs. (Hmmm... makes me sound like a virus. )

All I'm trying to do is to create an AHK script that will automate the 101 (probably 1001) changes that I have to remember to do for every Win 10 'upgrade' for me, my family and friends, most of which appear to be simple registry settings.

PS - The info about NSudo was very interesting (hence the delay in my replying to your last post) but way more than I hope to ever need.

[qwerty12]

Sorry. For what it's worth, it's going over my head too after reading my ramblings again...

Ah! For those settings in particular, don't change the settings there; instead, look at the Registry Values set in part three of this guide. As long as your script is running elevated under an admin account, you should be able to write to the Policies subkey without a hitch. The only downside (in the case of these settings, I'm kinda using that term loosely to be honest) to using the policy Keys is that the only way those particular settings can be changed in the future is to write to the Registry keys directly again or run gpedit.msc - the usual options to change them from the Defender settings will be greyed out.

Sorry, I don't have code to take ownership of Registry keys with AHK code (I'm not smart enough to do it properly. Also to the best of my knowledge, I don't think there's a tool included with Windows that does it either - you'd need SetACL or the subinacl.exe program included with some old Windows Resource Kits), but if it's just those Defender settings giving you problems, then hopefully it's not needed.

[RickC]

Ah! For those settings in particular, don't change the settings there; instead, look at the Registry Values set in part three of this guide.

I was hoping to be able to avoid utilities like SubinACL so that AskVG article and its info about restricting Windows Defender from the registry was just what I needed. Thank you once again.