PendingFileRenameOperations post-install blocks automated install of other software

[PGCCajb]

I'm working with deploying Notepad++ via MECM (formerly SCCM), and specifically, installing it during an "operating-system deployment" task sequence which also installs a variety of other programs.

In the past, this has worked fine. With current versions (I don't know exactly when it started; see below), I am seeing that at some point after the Notepad++ install completes, something else appears to happen, and the "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations" REG_MULTI_SZ entry in the Registry is populated with a variety of NppShell-related paths and filenames; NppShell.dll, NppShell_01.dll, NppShell_02.dll, NppShell_03,dll, NppShell_04.dll, NppShell.msix, NppModernShell.dll, and NppModernShell.msix have all been seen (all present simultaneously in that Registry entry).

This Registry entry is used to record the names of files which should be renamed or deleted when the computer reboots, because they cannot be safely deleted while it's running (e.g. because they're in use, and Windows file-locking semantics prohibits it). When this Registry entry is populated, many (but not all) MSI-based installers will error out and fail to install, on the basis that a system reboot is pending.

We therefore see that at a semi-random point after the installation of Notepad++, our installation task sequence encounters an error while installing a different program, and aborts without completing the rest of its installation process.

I could (and probably will) implement a kludgy workaround by setting the task sequence up to reboot after installing Notepad++, but this is not an entirely satisfactory solution.

For one thing, it does not necessarily solve the problem; if the post-NP++-install actions which cause that key to become populated have not yet occurred by the time we reboot, then they will presumably occur after the reboot, and the errors will occur at that point. Because we do not have a way to synchronously wait for this to happen (aside from a polling loop to wait for this key to populate, which is problematic on multiple fronts), we cannot safely just rely on rebooting to clear the blockage and continue.

For another thing, this problem did not occur with previous versions, and it is distasteful to accept a regression and work around it, rather than trying to get it fixed at the root.

Is there any possibility of getting the installer adjusted so that either this does not happen, or there is a way (perhaps an optional install-time switch) to make the installer block and not exit until this change has finished applying?

I do not know exactly when this started happening. We have seen it with version 8.5.7, but we have also seen that version appear to work fine. The problem was first observed, as far as I know, within the past week; I have guessed that it might be because of a post-install auto-update to a just-released newer version, but partially against that idea is the fact that I have successfully reproduced the issue when installing 8.6.8 with the '/noUpdater' switch. I have not gone so far as to revert to the 8.5.7 installer and add the '/noUpdater' switch to test whether the issue still manifests, but I can do so if necessary.

[GurliGebis]

Does the machine you are deploying Notepad++ to have Notepad++ already installed?

[PGCCajb]

It does not. The "operating-system deployment" part of the context means that we're installing the OS (Windows 11, in this case), and then following up by automatically installing a series of applications; Notepad++ is one of those applications. The environment is therefore about as clean as a Windows install can be, short of doing even more cleanup of the things that get preinstalled along with Win11 than we already do; I do not see any plausible way there can be Notepad++ already present at the time when we invoke the install.

That said, I do have an additional detail: I did implement that kludgy workaround, with a polling loop, and so far it seems to be detecting the "reboot required" Registry entry as populated with Notepad++ entries almost immediately after the install completes. It might be that the aspect of the install which leaves those files present is already synchronous, and we could safely just reboot without the polling loop; that would, however, leave the question of why we were seeing the later failure with seemingly-random different applications, different amounts of time after the install completed, rather than always with the very next one.

[GurliGebis]

Good, just checking. I think updating the code to handle this is easy enough - I will take a look at it once I get time 🙂

[GurliGebis]

@PGCCajb I have created a pull request that should solve this issue. It changes the logic, so it doesn't schedule a deletion of the files if they don't exist.

I find it interesting that Windows schedules it, if the file isn't there. (One would expect it to just ignore it.)

[PGCCajb]

Thanks for taking care of this!

If and when a release (or even an early build) which includes the change is made, I should be able to test the result in some fashion and confirm whether it seems to address the issue. I would ideally prefer to do that with an actual release, but I don't think that will be entirely mandatory.

(I'm not surprised that Windows doesn't check; that's entirely consistent with the same path-of-least-resistance approach which leads to that error-out-if-any-deletions-are-pending behavior. If someone files a bug report about the check not being made, they might change it in a future release - but they might also decide that doing so would break use cases where the file doesn't exist yet but is expected to exist by the time the process finishes, and decline to change anything.)

[PGCCajb]

Oops. I misread the UI and mistakenly closed this. Reopening.

[GurliGebis]

I would expect it to be a case of "what it does it technically wrong, but for backward compatibility, we keep it the way it is".

[donho]

@PGCCajb Could you try the installer of Notepad++ v8.6.9 RC here: https://community.notepad-plus-plus.org/topic/25918/notepad-v8-6-9-release-candidate And confirm the fix of the issue please?

[PGCCajb]

I've manually tested the 8.6.8 installer and the 8.6.9 RC installer, and verified that the former populates that Registry entry and the latter does not.

I want to also do a non-manual test from within the environment where the errors were originally observed (or a close approximation), just to be as sure as reasonably possible that the issue is in fact fixed; however, that will take longer. I may not be able to finish the test today, and if not, the earliest I may be able to do it is Tuesday.