GTVic
27th March 2013 22:50 UTC

64-bit Registry Values Not Written in One Case
My script sets values both under HKCR\Interface and under HKCR\Wow6432Node\Interface

When I run the NSIS compiled EXE it works, I have SetRegView 64 in the script which also has requestexecutionlevel admin. Everything is running in a UAC environment, Windows 7 64.

So far so good.

But when I run a VBS script that runs the NSIS EXE, then the HKCR\Interface values are not set, presumably redirected to HKCR\Wow6432Node\Interface.

The details of the VBS script are that it checks if there are any command line parameters and then it executes itself with admin rights
if WSCript.Arguments.length = 0 then
oShell.ShellExecute "wscript.exe", Chr(34) & strScriptPath & Chr(34) & " uac", "", "runas", 1
end if
where oShell is defined as
Set oShell = CreateObject("Shell.Application")

To run the NSIS compiled EXE which edits the registry, the VBS Script uses oWSH.Exec(runstring) where oWSH is defined as
Set oWSH = CreateObject("WScript.Shell")

Anders
28th March 2013 00:29 UTC

Can you check in Process Explorer to make sure the installer is running at high integrity level?
You could also try Process Monitor and see where it writes in the registry.

Why use oWSH.Exec? Could you try one of the other two methods (Run, ShellExecute) that use ShellExecute internally so we know you are getting UAC elevation handling...

GTVic
28th March 2013 00:58 UTC

Thanks, ShellExecute, Run have no wait option, but I was able to find an intermediary program that will do the waiting. First test went ok.

GTVic
28th March 2013 02:00 UTC

Thanks for the tip.

So in summary I wasn't concerned about running elevated because the entire script is elevated to start, guaranteed. Since the problem NSIS compiled script was working partially, adding 32-bit registry entries, I was not concerned about elevation.

In the end it seems as though oWSH.Exec can force a child process in a 32-bit compatibility mode.

Whereas Run or ShellExecute don't appear to have that restriction. The problem with these is that they cannot wait for the process to finish.

I did find a website Bill Stewart's Site - Miscellaneous Tools. That has a set of elevate tools that allow use of Run or ShellExecute with proper UAC control and will wait for the process to finish.

So that was my solution. I have an NSIS script which downloads/runs another NSIS script which extracts files and runs an extracted VBS script which uses ELEVATE to run a third NSIS script to modify the registry and set both 32-bit and 64-bit values. :confused:

Anders
28th March 2013 02:56 UTC

Run can wait...

Afrow UK
28th March 2013 12:56 UTC

I would avoid using a VBS because wscript/cscript can be disabled by group policy and this has been common with my users in the past (for example those in a domain/workstation environment). You'll just get a message box appear and then your installer will never run. Similar issue can happen with cmd.exe. The only real alternative is to use a MSI wrapper which can run embedded VBS using its own built in interpreter.

Also if you use RequestExecutionLevel admin, you still actually need to check the user is running as an administrator. You can use the UserInfo plug-in for this.

Stu

GTVic
28th March 2013 23:27 UTC

Thanks, this is a very controlled environment so no issues with VBS not working. I've removed the ELEVATE utilities, the only requirement was to use Run in place of Exec.