+- **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