DLLs not included correctly on package installation

[TurboPhil]

We built a package for one of our LabVIEW executables, which should include several DLLs in the support folder. For some reason, when we attempt to install the package, not all the DLLs are showing up. Instead, there are several GUID files (files with no extension, and just a GUID hexadecimal filename) in the support directory. Based on the number of these files and their sizes, it appears that these are actually the DLLs, but the installation process fails to rename them back to their original names.

We have removed and reinstalled the package multiple times, and every time we see the same result. The executable cannot run because it is missing DLLs; the DLLs are apparently there, but just not named properly.

There are no errors reported by the installation process that might indicate a problem prevented the rename of the GUID files.

There were also no errors reported at package build time (we are building the packages as part of our CI pipeline).

What sorts of problems might cause this? Is there anything else we can/should be doing to avoid this problem? If we can't understand what is happening, it's going to seriously degrade our confidence in using NI Packages at all...

[CL_eisenwr]

How are you building the package in your CI? Via a project Build Specification, NI Package Builder, or manually via nipkg.exe?

[TurboPhil]

We are building via project build specification.

Update: I rebuilt again and tried uninstalling/installing, and was still seeing the same problem. However, on one uninstall attempt (using "nipkg.exe remove {package}" CLI), I noticed it reported "Error -125071: A system reboot is needed to complete the transaction."

I went ahead and tried rebooting the machine, and the subsequent install successfully created the DLLs.

Any idea what might be requiring a reboot? And any idea why the reboot requirement is apparently nondeterministic? We are using packages for distribution of our executables, and we would very much like to avoid reboots when we just want to update to a new executable version.

[Scott_Richardson]

One thought, could there be any active indexing or scanning of the files during installation that could be preventing NIPM from renaming them from the temporary name to the final name and thus that failure causes NIPM to schedule the rename during reboot?

[TurboPhil]

That's an interesting though, Scott. I suppose it's possible that could have been what caused the problem originally.

But even after manually deleting those files (which it allowed me to do, so the lock was not persistent), all attempts to do the install again were failing until I rebooted. So it's like Windows must've flagged the installer itself as being not-completable without a reboot. I guess I need to do some more Googling to see if there is any more info on what's happening behind the scenes...(but I welcome any ideas/suggestions in the meantime).

[TurboPhil]

I suspect the problem is indeed that something was locking these files during an install or uninstall (although what specifically was holding them open is TBD), as described above, and that the problem persists until reboot because the installation process flagged these files in the registry under Session Manager/PendingFileRenameOperations.

Unfortunately, I can't tell now that I have rebooted that system, so we'll have to keep an eye out for this if it occurs again. I'll try to follow up if I can catch such a situation for sure, but including more detail here for now in case anyone else stumbles across this thread with a similar issue.

[Scott_Richardson]

Thanks for the update. Historically I have seen similar issues with software build processes getting impacked by such issues. I agree that determining the process that locks the files is not easy if reproducing the issue is not easy or non-determinant.