That log narrows things considerably. With `/qn` the whole install runs server-side, and the engine thread now dies **2 milliseconds** after grabbing the mutex — before it opens the package database, before the restore-point check, before a single action. It never even got far enough to fail at something.
That rules out everything package-specific: the MSI contents, the driver, the service, the target folder, disk space. The elevated msiexec engine is being terminated at startup. Note also that no `APPCOMPAT` line appears here — but that's not exoneration, it's because the client never opened the package this time. The shim lead is still open.
**The one test that splits this in half**
Try any other MSI on the same machine — 7-Zip's MSI, PowerToys, anything:
```
msiexec /i "C:\path\to\something-else.msi" /qn /L*v C:\other.log
```
If that also returns 1603 with the same two-line server session, Windows Installer itself is broken and Tailscale is irrelevant. If it installs fine, something is targeting this specific package — almost certainly security software, since Tailscale installs a network driver.
**Four registry checks that produce exactly this signature**
```powershell
# 1. IFEO debugger hijacking msiexec — instant death, hits .exe and .msi alike
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\msiexec.exe" -EA SilentlyContinue
# 2. Installed shim database (this is where your Win8.1 override likely lives, since Layers was clean)
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom" /s
# 3. DLLs force-loaded into every process
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows" -Name AppInit_DLLs,LoadAppInit_DLLs -EA SilentlyContinue
Get-ItemProperty "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Windows" -Name AppInit_DLLs,LoadAppInit_DLLs -EA SilentlyContinue
# 4. Installer service state and key ACL
sc.exe qc msiserver
(Get-Acl "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer").Access |
Where-Object IdentityReference -match 'SYSTEM|Administrators' | Format-Table IdentityReference,RegistryRights
```
`Custom` in check 2 is the one I'd bet on for the Windows 8.1 values — an installed `.sdb` doesn't show up under `Layers`, which is why your query came back clean. If a tweaking/debloat script was ever run on this box, that's a likely source.
**And the event log, which I still need**
The engine thread dying that fast often leaves a crash record naming the faulting module:
```powershell
Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-2)} |
Where-Object ProviderName -match 'MsiInstaller|Application Error|Windows Error Reporting|Application Hang' |
Select-Object TimeCreated,Id,ProviderName,Message | Format-List
```
If a third-party AV or EDR is installed on this machine, name it — that plus the faulting-module line usually ends the investigation. On the pending renames: those are typically harmless leftovers, but if you haven't actually rebooted since seeing them, do that first so we can stop counting it as a variable.
