A PendingFileRenameOperations entry is present after Burn exit.

[DS-AndOrz]

WiX Version

4.0.4 and 5.0.0-rc.1

.NET or MSBuild or Visual Studio Version

.NET 8.0.200

HeatWave Version

1.0.2.1

Windows Version

Win10 Enterprise Version 2004 Build 19041.4046

Repro Repo

No response

Repro Steps

1. Build a minimal Bundle.exe I tested with a "WixStandardBootstrapperApplication" and a managed CustomBA with WiX Version 4.0.4 and 5.0.0.
2. Clear the %temp% folder and make sure the system does not have a pending reboot. I use a Powershell script that does the same registry checks as the engine.
3. Install the Bundle
4. Before you close the success dialog check the %temp% folder for existing *.tmp files. At this point no .tmp file exists and no reboot is pending.
5. Close the Bundle with the "Close" button or a "Engine.Quit(0)" in the CustomBA.
6. A new .tmp file exists in the %temp% folder and a pending reboot exists in the system.

I wasn't able to repo this with a v3.11.2.4516 Bundle so it may be introduced with v.4.

Actual Result

The registry key "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations" has a value so that a system reboot is needed now.

Expected Result

As nothing in the chain required a reboot after the apply finished the bundle should close without generating a pending reboot.

CAD_CAM_Prerequisites_2.0.0_20240317103602.cleanroom.log CAD_CAM_Prerequisites_2.0.0_20240317103602.log CAD_CAM_Prerequisites_2.0.0_20240317103753.elevated.log

Acknowledgements

• [X] I acknowledge that this is a fully completed bug report. It is not a question or attempt to get help debugging my issue (because those should be sent to Discussions).

[barnson]

It's not a general problem with bundles, at least in v5.0.0-rc.2. You might try ProcMon to see how/when it's being written.

[DS-AndOrz]

I have to recheck this with a v5.0.0-rc.2 stdba bundle. I had some ProcMon events from a run and it was pointing to the elevated engine process. Have to update stuff to 3.14.1 first so hopefully tomorrow.

[DS-AndOrz]

I had the chance to check it again but it is still present in the 5.0.0-rc.2 StdBA bundle. Created a repository with the things I did. I also added some ProcMon logs. From the logs I still think that something is not released when the elevated engine closes. This empty directory should also be gone after the engine closes right?

[DS-AndOrz]

https://github.com/DS-AndOrz/wix5rc2issue8053

[chrpai]

I see your bundle is running a couple of installers. One of them has probably put the entry there. The entry is a request to delete a temp file on reboot. From the installers perspective the actual file has been moved to a temp folder and is effectively deleted while the actual delete will occur on next boot. From a UX perspective, I don't see a problem here.

[Kakaouette]

Hi. I ran into the same issue on a project. I have been able to pinpoint the problem to the ExePackage element; when I create a bundle that contains an ExePackage - which doesn't require any restart on its own, a DEL****.tmp file is created in the Temp folder and a PendingFileRenameOperation is added for that file.

This is how my temp folder looked after installing a bundle that contained another bundle as an ExePackage:

When copying the DEL88AE.tmp file out, I get the renamed BIT65DB.tmp version instead and the file size jumps from 1,047 KB to 168,025 KB:

I created a repo with the code used to demonstrate the issue: https://github.com/Kakaouette/WiXPendingReboot/tree/main Please note the projects were all created with Heatwave 1.0.4 on VS2022 17.9.5, and the tests were carried out on a Virtual Machine with Windows 10 - Update 1909 - 64 bit.