Then the shim is confirmed — on a real Windows 10 install, `VersionNT = 603` / `WindowsBuild = 9600` cannot happen naturally. Those are Windows 8.1 values, and `APPCOMPAT: Compatibility mode property overrides found` is msiexec telling you it accepted an override. Something is actively lying to the installer about the OS, and that's very likely why both the MSI and the EXE die.
Two things to correct from your reply, though: the "Update and restart" entry in the power menu only reflects *Windows Update* reboots. `MsiSystemRebootPending = 1` is usually set by leftover `PendingFileRenameOperations`, which never shows up there. So it's still worth checking directly:
```powershell
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name PendingFileRenameOperations -EA SilentlyContinue
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
```
**Finding the compat layer**
Run this in an elevated PowerShell — it dumps every compatibility layer set on the machine:
```powershell
'HKCU:','HKLM:' | ForEach-Object {
$k = "$_\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"
if (Test-Path $k) {
Write-Host "`n=== $k ==="
$p = Get-ItemProperty $k
(Get-Item $k).Property | ForEach-Object { "{0} -> {1}" -f $_, $p.$_ }
}
}
```
Look for anything referencing `msiexec.exe`, the Tailscale `.msi`, or the `.exe`. A value like `WIN8RTM` or `WIN81RTM` is your culprit. Delete it:
```
reg delete "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "C:\Windows\System32\msiexec.exe" /f
```
Two other places it can come from:
- **An inherited environment variable.** If you launched the installer from a shell or file manager that itself runs in compatibility mode, `__COMPAT_LAYER` propagates to every child process. Check in the same window you launch installers from: `echo %__COMPAT_LAYER%` (cmd) or `$env:__COMPAT_LAYER` (PowerShell). Empty is what you want.
- **An installed shim database.** Check `reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom"` — entries under `msiexec.exe` there mean an `.sdb` was installed, which some "optimizer" and crack/repack tools do.
The Program Compatibility Assistant is the usual author of these: it watches installers fail, then offers "reapply recommended settings," and if that was ever accepted for msiexec, every subsequent MSI inherits the lie.
**Then test with the shim explicitly cleared**, from an elevated cmd:
```
set __COMPAT_LAYER=
msiexec /i "C:\Users\1\Downloads\tailscale-setup-1.102.2-amd64.msi" /qn /L*v C:\ts2.log
```
Then check the new log: `findstr /C:"WindowsBuild" /C:"APPCOMPAT" C:\ts2.log`. If it now reports build 19041 and no appcompat line, the shim is gone — and if it still fails at that point, we're onto a different cause and the Event Viewer output I asked for becomes the next step.