registry reads in 64bit OS-- Part II

[jassing]

SUF7 cannot reliably read the registry in 64bit os's

I thought I had a (aleit ugly) solution, which was to shell out to reg.exe and query values/trees and redirect it to a file.

I use Debug.Print() to put the exact command line I run in File.Run() if I copy/paste that debug output to a cmd.exe window -- all is fine (works as expected)

however, some entries don't properly get 'queried' when I use File.Run() from suf7 -- again; the exact same line works fine from cmd.exe (same user)

is file.run() a wrapper for ShellExecute() ? Is it operating at a different user / rights level than the current user?

I went so far as to write to a batch file, then call the batch file from SUF7 -- same results, that same batch file works perfectly from cmd.exe (again, same user, same login session etc)

I desperately need a viable & reliable way to read the registry under 32 & 64bit os's....

Anyone have any thoughts?

[Brett]

File.Run uses CreateProcess which will in turn cause the spawned process to inherit the permissions of the setup. File.Open uses ShellExecute. You could try it instead.

[jassing]

File.Run uses CreateProcess which will in turn cause the spawned process to inherit the permissions of the setup. File.Open uses ShellExecute. You could try it instead.

Thanks Brett -- I'll try File.Open() -- I need to issue an entire command line (with parameters) but I can try doing a .cmd file instead to "see" if that works.

any other ideas on how to read the registry reliably, other than shelling to reg.exe?

[Brett]

I assume that the problem with SUF70 setups on 64-bit OSs is that it is running as a 32-bit process and therefore WOW64 is kicking in and redirecting requests to the 32-bit part of the registry. Is that what you mean by "unreliable"? Or have you uncovered problems other than that?

The way to fix it would be to try turning off WOW64 redirection from the setup before making the Registry calls. Here is a post that might help:

http://www.indigorose.com/forums/showthread.php?t=14532&highlight=WOW64

[jassing]

File.Run uses CreateProcess which will in turn cause the spawned process to inherit the permissions of the setup. File.Open uses ShellExecute. You could try it instead.

I think I may be brain dead...
I used this code (all in startup actions):

Debug.ShowWindow(true);
Debug.SetTraceMode(true);

TextFile.WriteFromString("c:\\test.cmd","Reg.exe query \"HKLM\\Software\\Microsoft\\Microsoft SQL Server\" /v InstalledInstances >c:\\test1.txt",false);
cmd = _SystemFolder.."\\cmd.exe /c c:\\test.cmd";
Debug.Print(cmd .."\r\n");

File.Open(cmd, "c:\\", SW_MINIMIZE);

Debug.Print( _tblErrorMessages[ Application.GetLastError() ] .. "\r\n");
Dialog.Message("test","done");

when I run the resulting installer it doesn't produce a file & I get the debug output shown (attached), yet I COPY the command being run and it works w/o problem. (the dos box shows it worked correctly)

[jassing]

I assume that the problem with SUF70 setups on 64-bit OSs is that it is running as a 32-bit process and therefore WOW64 is kicking in and redirecting requests to the 32-bit part of the registry. Is that what you mean by "unreliable"? Or have you uncovered problems other than that?

The way to fix it would be to try turning off WOW64 redirection from the setup before making the Registry calls. Here is a post that might help:

http://www.indigorose.com/forums/sho...ighlight=WOW64

Brett -- Actually -- shelling to reg.exe should do a 'better' job (in theory) if that were the case -- but actually it does a worse job of grabbing the data. the Registry.<actions> actually work for the most part, just some registry entries can't be read -- and so far, I haven't found a pattern as to why one can be read and another can't.

As for the refernced thread -- I did try the "modfied code" already -- I still have these issues.

Adam has been able to reproduce the issue -- and he (at least appears to me) is as stuck as I am.

[jassing]

The way to fix it would be to try turning off WOW64 redirection from the setup before making the Registry calls. Here is a post that might help:

http://www.indigorose.com/forums/sho...ighlight=WOW64

I revisited it and here's an intersting result, w/o making the call to disablewow

this code does not generate an error:

	local tProcesses = System.EnumerateProcesses();
  local cID = "";
  local cFile = "";
  TextFile.WriteFromString(cLog,"** Enumerating Processes\r\n", true);
  for cID, cFile in tProcesses do

calling disablewow -- the for line generates an error that I'm trying to index a nil.

I had some timing points
nStart = GetTick();
Debug.Print("Time to complete... (GetTick()-nStart).."\r\n");

GetTick was a function that got the cpu ticks.
without calling disablewow -- it worked fine
with calling disablewow -- on the GetTick()-nStart code lines -- everyone genrated an "attempt to do arithmetic on a string" error.

[Eagle]

for clarity\comment etc.:

disabling FS redirection does not in itself disable\bypass the
WOW64 registry redirection\reflection for 32bit detected images.

so more needs to be done to have FULL access to All reg data
on 64 bit OSs. As we know some parts of the registry hive on
64bit OSs are plain and simple Not available to 32Bit Apps directly,
due to a 'filtered and alternate' registry hive created by WOW64.

to be honest I have'nt had any issues using FS disable, then doing
the cmd.exe ... reg.exe ....stuff:

however, I either do a 'save' reg hive\load hive or a 'copy' target key\s
to a temp reg key (fully accessable by the 32bit runtime).

once this is done. Re-Enable FS redirection then you can perform any type
of registry stuff, using the builtin IR reg actions and go from there.

I have been using the methods described without issue and yes it is a
rough way of doing things(that works), for a specific purpose.

At present I believe there is a .vbs script on msdn that that enables
a 32 bit image to access the 'alternate 64 bit registry view':

32 bit process accesses the 64 bit hive, 64bit proccess can access
specficially the '32bit' hive and vise versa.

There is also a hex tag that can be placed via calls to regopenkeyex
createkeyex etc that tells WOW64 to mind its own business
and allow access to the 'Real' unrestricted registry hive\key.

My hope is that Brett and the Team tackle with FS and Registry redirection
and offer a solution, cuppla suggestions:
via new 64bit actions\plugin(with 64bit file header)-resource dll.
(this could be offerred as a separate and purchasable resource)

I would be more than happy to pay for an IR offerred solution.

[jassing]

Thanks Eagle -- I'v tried everything -- I had high hopes for the disabling wow64 but it introduced very odd problems thru-out the installer.

I'm loosing a lot of money on this project since I cannot support 64bit oses, and I don't have enough time to rewrite it in something else and be "on time".

Lemme ask you this - what I did was to call the disablewow function at 'on startup' and then the disable/fix 'on shutdown' -- is that how you use it?

Regarding IR fixing the registry -- I wouldn't hold your breath -- they're releasing other products and don't have dedicated "suf7" staff -- they rotate, so it'll be months I fear...

[Eagle]

My rule of thumb is this:

do nothing, then only when needed to access 64 bit stuff:
call the disableFSfunc, do what ya gotta do,
then straight away, call the re-enable func.

hth.

I may be able to help a bit more for some specific stuff.

I have two apps that need to do some 64 bit stuff, I have
been pushing for more 'IR 64bit support' for over 2 years,
I honestly don't know why something has'nt been done about.
64bit is here to stay and as the need for speed continues,
64 bit support will become almost a must have for Software developers.

Installers need this support big time...

Other creaters of installer products have either a support .exe or
some solutions ....I have nothing but good things to say about IR,
however they are lagging behind in this area.

[jassing]

do nothing, then only when needed to access 64 bit stuff:
call the disableFSfunc, do what ya gotta do,
then straight away, call the re-enable func.

I'll give that a try -- I'm just doing SO many registry reads, that I didn't want to go thru everywhere -- maybe I'll just make some wrapper functions
disable
read the registry
enable

I have two apps that need to do some 64 bit stuff, I have
been pushing for more 'IR 64bit support' for almost 18 months,
I honestly don't know why something has'nt been done about.

bummer -- I've only been on this issue for a month -- well; we can hope something happens sooner.

[Eagle]

Hopefully things will come soon, again the quickest, safest way is
to copy a reg tree to a created temp key in hklm\software\microsoft\syswow6432node\ of the registry
or HKCU, then re-enable FS, its real quick, you can cleanup the reg on
shutdown or whever suits.

[jassing]

Hopefully things will come soon, again the quickest, safest way is
to copy a reg tree to a created temp key in hklm\software\microsoft\syswow6432node\ of the registry
or HKCU, then re-enable FS, its real quick, you can cleanup the reg on
shutdown or whever suits.

I am working with the entire hklm and hkcu trees, just reading it...
the biggest problem is I cannot (I may not have rights) to edit the registry -- I just need to read the keys...

[Eagle]

I've been toying with a .vbs script from msdn, currently testing things,
avoids any reg copy stuff, allows access to 'alternate registry view'.

reg.exe /export to file is another way..but still cumbersome etc.

I'll post here a tried and tested solution when'if I can.

[jassing]

I've been toying with a .vbs script from msdn, currently testing things,
avoids any reg copy stuff, allows access to 'alternate registry view'.

reg.exe /export to file is another way..but still cumbersome etc.

I'll post here a tried and tested solution when'if I can.

I'd be happy to post my code -- currently only for reg READ stuff -- but it's a "direct replacement" for Registery.<action> -- just change Registry. to Registry64.

It only shells to reg.exe for 64bit OS's -- and you're right (of cours!) doing the kernel32 call before & after what I need removes wonkiness from the rest of the installer.