v5: Burn engine fails to elevate

[MatthiasRInst]

On some systems, our bootstrapper (WiX 5.0.0) fails to elevate. We do not use IEngine.Elevate(), so the user gets a UAC prompt when the Apply phase starts.

Log file says:

[39B4:32BC][2024-11-05T12:52:59]i299: Plan complete, result: 0x0
[39B4:32BC][2024-11-05T12:52:59]i300: Apply begin
[39B4:32BC][2024-11-05T12:52:59]i010: Launching elevated engine process.
[39B4:32BC][2024-11-05T12:53:39]i011: Launched elevated engine process.
[39B4:32BC][2024-11-05T12:53:39]e000: Error 0x80070006: Failed to wait for child to connect to pipe.
[39B4:32BC][2024-11-05T12:53:39]e000: Error 0x80070006: Failed to connect to elevated child process.
[39B4:32BC][2024-11-05T12:53:39]e000: Error 0x80070006: Failed to actually elevate.
[39B4:32BC][2024-11-05T12:53:39]e000: Error 0x80070006: Failed to elevate.

The "elevated" log file says:

[3130:3570][2024-11-05T12:53:34]i009: Command Line: '-q -burn.elevated ***** ***** *****'
[3130:3570][2024-11-05T12:53:39]e000: Error 0x8007006d: Failed to read size of verification secret from parent pipe.
[3130:3570][2024-11-05T12:53:39]e000: Error 0x8007006d: Failed to verify parent cache pipe: BurnPipe.{AA95F2E7-0ED5-4548-8436-80AF743E0E40}.Cache
[3130:3570][2024-11-05T12:53:39]e000: Error 0x8007006d: Failed to connect to unelevated process.
[3130:3570][2024-11-05T12:53:39]e000: Error 0x8007006d: Failed to run elevated mode.
[3130:3570][2024-11-05T12:53:39]i021: Exit code: 0x8007006d

This leaves me puzzled. Any idea about what happened here, why it may have happened, or what to do about it? As of now, I even have no idea about which pipes are supposed to be set up and which secrets are supposed to be verified.

[robmen]

Looks like something very low-level is going awry. You'll want to search for those log messages in the burn codebase and stick a debugger on it.

[mosBrkr]

Did you find a solution for that issue? We are actually facing the same behavior on some machines.

[kerrywicks]

I've just run into this issue myself when upgrading from Wix 4.0 to Wix 5.0.2 - however, I'm only getting this error message when attempting to uninstall via Apps and Features.

Silent install works correctly, and uninstalling using the actual installer (not from the link in Apps and Features) works without issue. Is there something else that needs to be set for ARP now?

Designer_100_20241219163207.log
Designer_100_20241219163121_000_Designer100.log

After comparing some older install logs, it looks like the only difference is that the burn.clean.room is no longer being used (which is as expected given the Wix 5.0 changes), and this only seems to be an issue when the installer has a UAC prompt when triggered via Apps and Features.

[kerrywicks]

Do you get the issue on all cases on certain machines, or just in specific scenarios?

[MatthiasRInst]

It is rather sporadic, which is of course the worst situation when trying to troubleshoot.

I think (but have not done a real bookkeeping) it occurs more often when I start my Bootstrapper exe with elevation right away, so that I am not asked for admin credentials when Burn starts the elevated engine.

[kerrywicks]

Hmm - I'm wondering how close our scenarios are in this case - I can get my install to work (through a UI and silently) without issue. It's only when I try and uninstall via Apps and features that I get an issue. It's very consistent on my end.

I'm currently going through my code and making sure that I'm generating only 1 handle for my UI window (or 1 'fake' one for silent installs) just to see if this resolves the handle issue.

[MatthiasRInst]

Apps & Features means that you have to start the Bootstrapper exe with elevation right from the start, what happens when after installing you double-click your Install.exe or Bootstrapper.exe in your diskset (with UI) in order to uninstall?

[kerrywicks]

It works entirely as expected - so in both cases, the UAC window pops up. I click OK - I then get my installer pop up. I click the 'Uninstall' button - when double clicking, the uninstall works as intended. From the Apps and Features, it fails immediately, and I get directed to my installation failed screen. I've attached 2 logs for the uninstall if you're feeling curious - one when executed from the installer via double click, and one from Apps and Features.

Uninstall_DoubleClick.log
Uninstall_AppFeaturees.log

What is your installer developed in? Is it C++ or .Net, or something else? I've done mine in C# .Net, and I do make use of calling the EnsureHandle method to get the IntPtr for use in Apply i.e.

var handle = new WindowInteropHelper(this).EnsureHandle();

I have that set up in the view (which is a Window), or I make a window in the case of a silent installation. I then have the handle stored in the viewmodel so I can call back to it and keep things consistent when calling methods in the Engine that need it.

[wmanning]

As @MatthiasRInst said it seems initially the elevated process and the three pipes are valid. The unelevated parent process then waits on the first pipe. It doesn't get a response from the child so it then waits on the child process to check if it's still running. That returns E_HANDLE.

The seems to imply that the child process handle was closed before WaitForSingleObject is called. Even if the child process terminates it's file handle remains valid until the parent process closes the handle. I think that's how it works:
https://stackoverflow.com/questions/69752777/on-windows-do-i-have-to-call-waitforsingleobject-after-calling-createprocess

@MatthiasRInst are you building the wixtoolset source code or did you just use the wix pbd files with the debugger. Would be interesting to add more debug lines to see if the file handle is still valid and/or closed before WaitForSingleObject is called. Might narrow down the problem.