Installation Bug?

Rory O'Brien

I am a newbie and installed Notepad++ v8.8.3 today. I ran the installation executable and it halted about 95% through the process after extracting NppShell.dll and starting an execute statement. (I could not see which file it executed).
I had to kill the process and ran the installation file again with the same result but with the slight variant that a Notepad++ icon appeared on the desktop and the application seems to work.

Does anyone have any ideas as to what happened and how I can cure the problem?

PC is:
OS = MS Windows 11 Pro for Workstations, Version 10.0.26100 Build 26100
System = Dell Precision 7920 Tower
Processor = 2 x Intel® Xeon® Silver 4208 CPU @ 2.10GHz, 2095 Mhz, 8 Core(s), 16 Logical Processor(s)
BIOS Version/Date Dell Inc. 2.48.0, 09/06/2025
SMBIOS Version 3.2
BIOS Mode UEFI
Installed Physical Memory (RAM) 96.0 GB

PeterJones

@Rory-O-Brien ,

Installation often requires UAC privileges, especially for something like activating the NppShell.dll. I know there are rare times where Windows doesn’t pop the UAC elevation request to the front, so when that happens, you might want to Alt+Tab and see if Windows is hiding the permission request. (I’m not an expert on the installer process – though there are some regulars here who are – so if that doesn’t solve it, you might have to wait for someone else to chime in.)

mpheath

@Rory-O-Brien

There is a checkbox to check to stop the log page from automatically closing. If the log closed then the extraction of files would be basically finished. I can only suggest checking system event logs and program logs that may scan and block processes. More details may help to expose the source of the issue.

The v8.8.3 installer may work like previous versions though the uninstaller appears to be bugged regarding the unregistering of the context menu extension as I found today viewing the log.

Process	$winSysDir	Target
install x64	`$WINDIR\System32`	Redirects to `C:\Windows\SysWOW64`
install x86	`$WINDIR\SysWOW64`	`C:\Windows\SysWOW64`
uninstall	No value assigned	`\regsvr32.exe`
uninstall	No value assigned	`\rundll32.exe`

The install system path both target the 32 bit system directory so the creation of a variable named $winSysDir seems pointless when the builtin $SYSDIR would be adequate. $SYSDIR also works for the uninstall process so instead of targeting the root of the current drive as to the empty value of $winSysDir, it will target the 32 bit system directory.

whindsaks questioned the use of $winSysDir a few weeks ago in a commit comment . Nobody responded at that time.

For a 32 bit process, like the installer is, to access the 64 bit system directory, the file system redirector may need to be temporarily disabled while the access is needed. The alias $WINDIR\SysNative can also access the 64 bit system directory with Windows Vista+ from a 32 bit process. $winSysDir fails to achieve this 64-bit access as the active file system redirector changes the direction and I do not see how previous installers accessed it either without absolute paths so it has been accessing the 32 bit system directory for a long time.

@xomx can you confirm and consider a solution.