Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 4

System Search - 64-bit registry and WIN64DUALFOLDERS


My goal is to have a LaunchConditon that halts progress if some version of sqlcmd.exe cannot be found in an expected location. I'll keep my example limited to SQL 2008 for simplicity.

I have a registry search to define a SQL2008TOOLSLOCATION property, and then I look for sqlcmd.exe inside this path (see screenshots for the 2 system searches).

The LaunchCondition is ensuring that SQL2008SQLCMDEXE exists.

On 32-bit machines, SQL2008TOOLSLOCATION is getting set to the expected C:\Program Files\Microsoft SQL Server\100\Tools\Binn , and as sqlcmd.exe exists here, the LaunchCondition passes.

On 64-bit machines however, both C:\Program Files\Microsoft SQL Server\100\Tools\Binn and C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn exist, but sqlcmd.exe is only installed to C:\Program Files\Microsoft SQL Server\100\Tools\Binn.

Checking the msi log, I see this in the AppSearch section:

MSI (c) (64:D8) [12:14:34:441]: WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters in 'C:\Program Files\Microsoft SQL Server\100\Tools\Binn\' folder path. (mask argument = 0, the folder pair's iSwapAttrib member = 0).
AppSearch: Property: SQL2008TOOLSLOCATION, Signature: NewSignature1
MSI (c) (64:D8) [12:14:34:550]: PROPERTY CHANGE: Adding SQL2008TOOLSLOCATION property. Its value is 'C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\'.

So the 64-bit portion of the registry has the path that I'm after, but even though I've specified the registry search to look in the 64-bit registry, something keeps steering it toward the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\100\Tools\ClientSetup Path value, and thus setting it to Program Files (x86) location which is no good for me.

Might anyone know why the search is behaving this way, or a way to ensure the Wow6432Node is not searched in this case?

Thanks much!

Labels (1)
0 Kudos
(1) Reply
Level 4

After some more research, I believe I've found the cause and a solution.

Perhaps of important note is that my installer was 32-bit (Intel in Template Summary).

This WIN64DUALFOLDERS substitution thing seems to kick in any time [ProgramFilesFolder] is referenced in a 32 bit installer, which mine was as the default install location, as well as in the expected value of the Path in my registry System Search for the SQL Server Tools. However, the fact that I need to read SOME 64-bit specific area of the machine (the registrry in this case), I need to make a 64-bit specific installer (by replacing Intel with x64 in my template summary). After doing so, the installer retrieved the appropriate (64-bit) registry entry. Because none of my components are marked as 64-bit (by design), the default installation location, which I've set to [ProgramFilesFolder], correctly defaults to C:\Program Files (x86)\MyCompany\MyApp .

I have other 32-bit installers that work fine on 64-bit machines, but as I'm not doing anything specific with the 64-bit registry or ProgramFiles64Folder in those, I never hit the issue with a registry lookup until now.

So I'll just need a 32-bit and 64-bit version of this particular project (and any others where I might need to interrogate the ProgramFiles64Folder or 64-bit registry).

0 Kudos