+- **Windows Performance Analyzer is not part of Visual Studio.** VS has its own
+ Performance Profiler, which is a different, `.diagsession`-based tool and
+ cannot open an `.etl`. WPA ships with `xperf` and `wpr` in the Windows
+ Performance Toolkit, which exists in exactly two places: as an optional
+ *feature* of the Windows SDK (`OptionId.WindowsPerformanceToolkit`) and inside
+ the Windows ADK, which bundles the same toolkit. Whether the SDK install that
+ Visual Studio performs selects that feature varies by version, so the elevated
+ half **detects first** — `%ProgramFiles(x86)%\Windows Kits\10\Windows
+ Performance Toolkit`, its 64-bit twin, and the ADK location — and only falls
+ back to `winget install Microsoft.WindowsADK` when nothing is there. It then
+ re-asserts that directory on the machine `PATH` (the toolkit's own installer
+ usually does this, and the Start Menu gets *Windows Kits > Windows Performance
+ Toolkit* shortcuts for WPA and WPR). To install just the toolkit instead of the
+ whole ADK, run the standalone SDK setup with
+ `winsdksetup.exe /features OptionId.WindowsPerformanceToolkit /q`. A newer WPA
+ also exists in the Microsoft Store (`winget install --id 9N0W1B2BXGNZ --source
+ msstore`); it is not installed here because the Store source needs an
+ interactive, signed-in session, which the unattended elevated half does not
+ have.
+- **Intel VTune Profiler is reported, not installed.** The elevated half prints
+ whether it is on the box, its version, and the path to `vtune.exe`; if it is
+ missing it prints the download page instead (and says so if the CPU is not
+ Intel). Automating the install is not worth it here: the offline installer is a
+ ~750 MB download from a URL carrying a per-release GUID with no "latest"
+ redirect behind it, so every new build would mean editing a hard-coded link,
+ and it is only worth having on Intel silicon since hardware event-based
+ sampling reads Intel PMU counters. It does install unattended if you want it
+ scripted elsewhere:
+
+ ```powershell
+ intel-vtune-<version>_offline.exe -a --silent --cli --eula accept
+ ```
+
+ **Run it from an administrator account, elevated.** Hardware event-based
+ sampling (`uarch-exploration`, `memory-access`, `hotspots -knob
+ sampling-mode=hw`) requires it, and VTune warns about that at the top of every
+ unelevated run. Worth knowing that the failure it gives there is *"cannot
+ recognize the processor"*, which reads like a hardware problem and is not one:
+ the drivers (`sepdrv5`, `sepdal`, `vtss`) are installed and running, and VTune
+ identifies the PMU through them. There is no group to join to get around it —
+ the Linux driver can be handed to a `vtune` group, but on Windows the
+ documented answer is to run as administrator.
+
+- **Collect traces from an elevated Administrator session. Non-elevated
+ collection was tried here and abandoned.** The attempt was to put one ordinary
+ account into `BUILTIN\Performance Log Users`, which appears in the default
+ security descriptors ETW keeps per provider GUID under
+ `HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security`, and collect without a UAC
+ prompt. It does not survive contact with the real workflow: `xperf -on base`
+ and `wpr -start` drive the *NT Kernel Logger*, reserved for Administrators and
+ LocalSystem, and granting the group `SeSystemProfilePrivilege` ("Profile system
+ performance") plus an explicit ACE for `TRACELOG_ACCESS_KERNEL_LOGGER` on
+ `SystemTraceControlGuid` — all three in place, across a reboot — still answered
+
+ ```text
+ xperf: error: NT Kernel Logger: Access is denied. (0x5).
+ ```
+
+ It is not a check an ACE overrides, and the same wall turned up often enough
+ elsewhere that the whole approach was dropped rather than carried as a
+ half-working path. **Sign in to an administrator account and run `xperf`, `wpr`
+ and VTune from an elevated prompt.** Analysis is the exception and never needed
+ any of this: `wpa.exe` opens an existing `.etl` as a plain user.
+
+ If an earlier revision of these scripts ran on a box, it left that account in
+ the group. Take it back out with:
+
+ ```powershell
+ net localgroup "Performance Log Users" DOMAIN\user /delete
+ ```
+
+ Two revisions also granted the privilege and the ACE. Undo the privilege in
+ `secpol.msc` > Local Policies > User Rights Assignment > "Profile system
+ performance" by removing Performance Log Users. The ACEs sit in the
+ `{9e814aad-3204-11d2-9a82-006008a86939}` value under
+ `HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security`: strip the `LU` entries
+ from that descriptor rather than deleting the value, which also carries entries
+ for SYSTEM, Administrators and two service accounts.
+