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
+ ```
+
+ **Running it needs no elevation, but hardware sampling does.** A standard user
+ gets the User-Mode Sampling analyses — `vtune -collect hotspots` and threading
+ — and they work: measured here, collection and finalization, exit 0. Hardware
+ event-based sampling (`uarch-exploration`, `memory-access`, `hotspots -knob
+ sampling-mode=hw`) wants administrator, and VTune says so in a warning at the
+ top of every unelevated run. Note the failure it actually gives 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. Unlike ETW there is no group to join for this
+ — the Linux driver can be handed to a `vtune` group, but on Windows the
+ documented answer is to run as administrator.
+
- **Tracing without a UAC prompt.** `xperf` and `wpr` fail for a standard user in
two different ways, because two different things are missing:
Two consequences worth knowing. A privilege and a group membership are both
read into the access token **at logon**, so the account must sign out and back
in for 1 and 2 — any new logon does it, and an `ssh` login into the box is the
- quick way to check without dropping the desktop. (The ACE in 3 is machine
- state, read when a session starts, so it applies immediately.) And this only
+ quick way to check without dropping the desktop. The ACE in 3 is machine state
+ instead, and a logon does nothing for it: ETW reads these descriptors into a
+ cache, so it takes a **reboot** — with the ACE written and readable, `xperf -on
+ base` was still denied from a fresh shell on the running system. Plan on both
+ on a first run. And this only
helps a **non-admin** account: UAC hands an administrator a filtered token
carrying just five harmless privileges, so an admin's ordinary shell still
cannot trace however the policy reads. Verify from the target account,
vilimpoc.org / repos / dotfiles / blobdiff