Unable to write to #HKEY_LOCAL_MACHINE on Windows 10, 11

[Oso]

I'd like to run my background process automatically when a user logs in and I found that by far the most convenient way for me, was to set the appropriate registry key in #HKEY_LOCAL_MACHINE during the first instance that the programme is executed. This worked well on Windows Server 2016, but Windows 10 and 11 ignore it. They do however allow me to create the key in #HKEY_CURRENT_USER.

Is this now a restriction in Windows that we cannot get around? The reason I'd like to be able to do this with #HKEY_LOCAL_MACHINE is because if the software is installed for a user, IT-department staff will need to remember to re-run it and re-create the key, if the machine is later reconfigured for a new member of staff. This isn't a big thing — I can live with this anyway — but I thought it worthy of mention here, in case (a) others have a workaround for this or (b) it helps anyone else in future (because this took me a while to realise).

Code: Select all

#APPNAME           = "ClientA";                                          ; Application name (used in setting registry key)

; **
; ** Write auto run key
; **
; ** Pass parameters   key.l      : #HKEY_CURRENT_USER for start at user logon
; **                                #HKEY_LOCAL_MACHINE for start with all users
; **                   value.s    : Application name (not necessarily the same as the executable)
; **                   state.b    : 1 = Set, 0 = Unset
; **
Procedure StartWithLogin(key.l, value.s, state.b)
  
  Protected path.s = "Software\Microsoft\Windows\CurrentVersion\Run"    ; Use RunOnce to run once only

  Protected string.s = Chr(34) + ProgramFilename() + Chr(34)            ; Full path to the executable
  Protected curkey.l
  
  If state.b                                                            ; If setting true
    RegCreateKey_(key, @path, @curkey)
    RegSetValueEx_(curkey, @value, 0, #REG_SZ, @string, Len(string) * 2)
  Else                                                                  ; Setting false, so remove key
    RegOpenKey_(key, @path, @curkey)
    RegDeleteValue_(curkey, @value)
  EndIf
  RegCloseKey_(curkey)                                                  ; Close the key
  
EndProcedure

StartWithLogin(#HKEY_LOCAL_MACHINE, #APPNAME, 1)                        ; Write registry key to autostart
; Change above line to #HKEY_CURRENT_USER and it works

As an aside to this, I've been struggling a bit to find a convenient way to auto-run a background process that doesn't require users to go to a lot of trouble to configure it manually. During development, I used the Windows Task Scheduler, set to "At logon", which works very well but isn't easy for users to set up.

A service would be great but it seemed too complex. I saw there's an sc.exe that can be used to create services, but haven't had time to try it. Has anyone else used this successfully?

[mk-soft]

I assume that you have to compile the program with the option 'Request Adminitrator Mode'.


For services I have this basis
Link: Base for Services

[ChrisR]

I've just looked on a Windows 7 Virtual Machine.
I have the same access rights as on my Windows 10 PC:

For HKM\Software\Microsoft\Windows\CurrentVersion\Run, the user is in read-only mode and the administrator has full rights.
And for Hkey_Current_User, both user and administrator have full rights.
So you don't need EnableAdmin compiler flag if you do it for the Current user
But you need it if you want to be able to write in the HKLM run key

I assume that on your Windows Server 2016, the user has administrator rights.

[Oso]

Thanks both, mk-soft and ChrisR, that's interesting as both systems (10 and 11) are being tested with administrator users. No, I didn't select the "Request Administrator mode" in compiler settings. I'll try again with that enabled and report back.

Yes, the Server 2016 is an administrator's account, but so are the other two. Seems odd that really, but the tickbox may resolve it. Let's see.

[Oso]

I've tried this now, selecting the tick-box in the compiler options "Request Administrator mode". The effect this has, is that the application now prompts for administrator priviledge (without a password) and successfully writes the HKM\Software\Microsoft\Windows\CurrentVersion\Run key.

So yes, that's the reason behind the inability to write the key. It didn't prompt for that before the compiler tick-box was selected, which I suppose makes sense.

I hadn't expected this, because the test user was an administrator account anyway. It isn't the 'administrator' account, but an account called 'Admin' with the administrators' group assigned to it.

On the Windows Server system, I happened to be testing under the 'Administrators' account, so that perhaps explains the variation there.

[fryquez]

On the Windows Server system, I happened to be testing under the 'Administrators' account, so that perhaps explains the variation there.

Yes, the build-in Administrator account does always have full admin rights.
All other members of the administrator group are effected by UAC. They can request admin rights on demand.

[Oso]

the build-in Administrator account does always have full admin rights. All other members of the administrator group are effected by UAC. They can request admin rights on demand.

Thanks fryquez that explains it clearly then. We can't really run it in background, if it expects to update the HKM registry, because running in background prevents it from prompting for elevated rights. I'll probably re-work it so that it only writes the the registry when first installed and not thereafter.

[AZJIO]

Oso
You can make a separate file that is intended to be written to the registry with administrator privileges. That way, you don't have to do the entire program with administrator privileges. At the time of writing to the registry, you will be prompted to allow startup.

[Oso]

Oso
You can make a separate file that is intended to be written to the registry with administrator privileges. That way, you don't have to do the entire program with administrator privileges. At the time of writing to the registry, you will be prompted to allow startup.

Thanks AZJIO I suppose that's one way of doing it, yes. At the moment it's all inside a single background process, but the first time the process is run, the user is responsible for double-clicking it (to start it going). The process then reads a .ini parameter file that the user can amend before running it. One of the settings in the parameter file is "run automatically with user-logon", or "run manually", so that's what it sets in the registry.

I think I've tried to be too clever with it But that aside, it is already working very well.

I'm going to have a look at creating a service also, because it's something I want to understand better, so I'm pleased to see mk-soft's link to that.