My environment: NSIS v3.09 on Windows 10 22H2 x64
I think InstallDirRegKey is not working correctly on Windows 10 x64, I did several tests but it apparently is not collecting the registry value.
Maybe it's a bug or it's just happening to me.
Could someone confirm it please?
PS: I am attaching a sample script.
InstallDirRegKey not working on Windows 10 x64
21 posts
Where are you writing the value? NSIS does not write it for you...
According to https://nsis.sourceforge.io/Reference/InstallDirRegKey InstallDirRegkey should overwrite the value of InstallDir, in other words, the installation directory which is visible in the Page instfiles.Originally Posted by Anders View PostWhere are you writing the value? NSIS does not write it for you...
That page does not contain the word "write". You must write it yourself or point it to your UninstallString value.
If InstallDir is set, it is assigned to $InstDir. Then if InstallDirRegKey is set and present in the registry, its value is assigned to $InstDir. All of this happens before .onInit.
If InstallDir is set, it is assigned to $InstDir. Then if InstallDirRegKey is set and present in the registry, its value is assigned to $InstDir. All of this happens before .onInit.
I have also tried setting both InstallDir and InstallDirRegKey but even in that case InstallDirRegKey fails on my Windows 10 x64.Originally Posted by Anders View PostThat page does not contain the word "write". You must write it yourself or point it to your UninstallString value.
If InstallDir is set, it is assigned to $InstDir. Then if InstallDirRegKey is set and present in the registry, its value is assigned to $InstDir. All of this happens before .onInit.
Could you check if it works for you in your environment?
You need to use WriteRegStr to write the value.
If you are using Regedit, for HKLM you need to look in the wow node under Software.
If you are using Regedit, for HKLM you need to look in the wow node under Software.
I don't want to write the value to the registry, I want to pick up a value from the registry and use this value as Destination Folder.

I just realized a mistake in a comment above, the installation directory is not visible in the Page instfiles, it is visible in the Page directory.
Sorry for the misunderstanding.
Sorry for the misunderstanding.
Yes, your script works unchanged on my 10 64-bit machine.
You can use Process Monitor to watch NSIS read the value...
You can use Process Monitor to watch NSIS read the value...
I don't know how to use Process Monitor but I also tried the ReadRegStr instruction, which works correctly, so the problem is not that the register cannot be read.
I tested on two other Windows 10 x64 computers and InstallDirRegKey also failed on them.
Additionally I did tests on an old computer with 32-bit Windows XP and surprisingly InstallDirRegKey worked correctly on it.
I tested on two other Windows 10 x64 computers and InstallDirRegKey also failed on them.
Additionally I did tests on an old computer with 32-bit Windows XP and surprisingly InstallDirRegKey worked correctly on it.
Start Process Monitor and press Ctrl+L to open the filter dialog:

Fill in the fields and click OK and then run the installer:

Keep in mind that if you are not administrator and elevate with a different user in the UAC dialog, HKCU will belong to the administrator user.
Fill in the fields and click OK and then run the installer:
Keep in mind that if you are not administrator and elevate with a different user in the UAC dialog, HKCU will belong to the administrator user.
Also keep in mind that InstallDirRegKey does some minor validation on the value it reads, using the NSIS MRU string is not the best thing to test with, if the filename it reads there exists as a file it will probably fail!
RequestExecutionLevel user
!define REGDIR 'HKLM "Software\Microsoft\Windows\CurrentVersion" "CommonFilesDir"' ; Just an example, use the $COMMONFILES in a real installer
InstallDirRegKey ${REGDIR}
Function .onInit
ReadRegStr $0 ${REGDIR}
MessageBox MB_OK InstallDirRegKey=$InstDir$\nReadRegStr=$0
Quit
FunctionEnd
Section
SectionEnd Interestingly with the registry key in your example InstallDirRegKey works correctly in my environment.
Could you try a longer key like the one shown in the image?

Could you try a longer key like the one shown in the image?
Viewing HKLM in regedit gives you different view, 32-bit InstallDirRegKey will effectively read from HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall if you are using the native regedit on 64-bit Windows
I'm not understanding, what you're trying to say is that InstallDirRegKey can't read keys from HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall on a 64-bit Windows?
By the way, HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall looks like this, there is no Notepad2-mod_is1 key

By the way, HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall looks like this, there is no Notepad2-mod_is1 key
32 bit applications are redirected from HKEY_LOCAL_MACHINE\SOFTWARE\YOURKEY to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\YOURKEY.
HKEY_CURRENT_USER is not affected.
This can be problematic if interop between a 64 and a 32 bit app needed. For example, a compiled 32 bit NSIS installer and your 64 bit app.
Do you already have the HKEY_CURRENT_USER\SOFTWARE\NSIS\MRU key? If not exists, use InstallDir before InstallDirRegKey to specify the initial location - probably your users will need it, too.
By name, HKEY_CURRENT_USER\SOFTWARE\NSIS\MRU painfully looks like a registry key for NSIS to keep the Most Recently Used item for something, maybe it is "random" overwritten when you have tested it. Use your name / nickname / company name instead of someone else under the SOFTWARE key.
Maybe your end user is not admin? Then add RequestExecutionLevel user to avoid triggering the UAC prompt. Also avoid "installer" in the name of the executable.
You have to explicitly write back the chosen install dir to the registry, so is necessary in section Main.
Attached a commented version, "it works on my machine", 64 bit W10 compiled with NSIS 3.09
HKEY_CURRENT_USER is not affected.
This can be problematic if interop between a 64 and a 32 bit app needed. For example, a compiled 32 bit NSIS installer and your 64 bit app.
Do you already have the HKEY_CURRENT_USER\SOFTWARE\NSIS\MRU key? If not exists, use InstallDir before InstallDirRegKey to specify the initial location - probably your users will need it, too.
By name, HKEY_CURRENT_USER\SOFTWARE\NSIS\MRU painfully looks like a registry key for NSIS to keep the Most Recently Used item for something, maybe it is "random" overwritten when you have tested it. Use your name / nickname / company name instead of someone else under the SOFTWARE key.
Maybe your end user is not admin? Then add RequestExecutionLevel user to avoid triggering the UAC prompt. Also avoid "installer" in the name of the executable.
You have to explicitly write back the chosen install dir to the registry, so is necessary in section Main.
Attached a commented version, "it works on my machine", 64 bit W10 compiled with NSIS 3.09
should have been You have to explicitly write back the chosen install dir to the registry, so WriteRegStr HKCU "SOFTWARE\VICOKOBY" "InstallLocation" "$InstDir" is necessary in section Main.Originally Posted by adamxpeter View PostYou have to explicitly write back the chosen install dir to the registry, so is necessary in section Main.
The registry redirector isolates 32-bit and 64-bit applications by providing separate logical views of certain portions of the registry on WOW64.
but you are making this much harder than it has to be, just do
RequestExecutionLevel admin
!define REGDIR 'HKLM "Software\MyApp" "InstallLocation"'
InstallDirRegKey ${REGDIR}
Section
WriteRegStr ${REGDIR} $InstDir
SectionEnd I do not need to write a value in the registry, I need to know where a program is installed to install an addon in that same folder, since the user can choose where to install that program, the default folder may not be the correct one.
t seems that InstallDirRegKey is unable to read values from HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall subkeys, I understand this is due to how 64-bit Windows handles 32-bit applications, the Registry Redirector thing.
Anyway, thank you both for your help.
t seems that InstallDirRegKey is unable to read values from HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall subkeys, I understand this is due to how 64-bit Windows handles 32-bit applications, the Registry Redirector thing.
Anyway, thank you both for your help.
If you want to do something non-standard, ReadRegStr in .onInit
So your problem is that the already installed software is a 64 bit one.Originally Posted by vicokoby View PostIt seems that InstallDirRegKey is unable to read values from HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall subkeys, I understand this is due to how 64-bit Windows handles 32-bit applications, the Registry Redirector thing.
Check this solution: https://stackoverflow.com/questions/...-64-bit-system despite it's writing nature.
https://nsis.sourceforge.io/Reference/SetRegView
Sets the registry view affected by registry commands. On Windows x64 there are two views. One for 32-bit applications and one for x64 applications. By default, 32-bit applications running on x64 systems under WOW64 have access only to the 32-bit view. Using SetRegView 64 allows the installer to access keys in the x64 view of the registry.
Affects DeleteRegKey, DeleteRegValue, EnumRegKey, EnumRegValue, ReadRegDWORD, ReadRegStr, WriteRegBin, WriteRegDWORD, WriteRegStr and WriteRegExpandStr.
Does not affect InstallDirRegKey. Instead, the registry can be read using ReadRegStr in .onInit.