+- **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
+ ```
+
+ **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.
+
+- **User-mode ETW tracing without a UAC prompt — and the kernel logger's hard
+ limit.** Out of the box a standard user cannot start *any* event tracing
+ session, not even a user-mode one naming a single provider:
+
+ ```text
+ xperf -start T -on Microsoft-Windows-Kernel-Process -f trace.etl
+ -> Access is denied. (0x5)
+ ```
+
+ Session control is checked against the security descriptor ETW keeps per
+ provider GUID under `HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security`, whose
+ default grants those rights to SYSTEM, Administrators, the service accounts and
+ `BUILTIN\Performance Log Users` — and to nobody else. So the elevated half puts
+ the account named by `-TraceUser` into that group, and the command above then
+ works unelevated; enabling another account later is just
+ `net localgroup "Performance Log Users" <user> /add`. Membership is read into
+ the access token **at logon**, so sign out and back in first — any new logon
+ does it, and an `ssh` login into the box is the quick way to check without
+ dropping the desktop.
+
+ **Kernel traces are not available this way, and cannot be made to be.**
+ `xperf -on base` and `wpr -start` drive the *NT Kernel Logger*, which is
+ reserved for Administrators and LocalSystem — Microsoft documents Performance
+ Log Users access as explicitly not extending to it. That was measured rather
+ than assumed, and the negative result is recorded here so nobody repeats the
+ experiment: with the account in the group, `SeSystemProfilePrivilege` ("Profile
+ system performance") granted to that group, and an explicit ACE giving the
+ group `TRACELOG_ACCESS_KERNEL_LOGGER` on `SystemTraceControlGuid` — all three
+ in place, across a reboot — `xperf -on base` still answered `NT Kernel Logger:
+ Access is denied. (0x5)`. It is not a check an ACE overrides. The privilege
+ grant and the ACE were dropped again rather than left on the box earning
+ nothing: CPU sampling and whole-system traces are elevated work, with `xperf`,
+ `wpr` or VTune from an Administrator prompt.
+
+ Analysis was never affected — `wpa.exe` opens an existing `.etl` as a plain
+ user. This is only about collection.
+
+ The step runs **first** in the elevated half, and `-EtwRightsOnly` runs it and
+ nothing else, which matters because a full run is dominated by the three Visual
+ Studio passes that take minutes even with nothing to do:
+
+ ```powershell
+ Start-Process powershell -Verb RunAs -ArgumentList '-NoProfile','-ExecutionPolicy','Bypass',
+ '-File','<repo>\setup-windows-with-uac.ps1','-TraceUser','DOMAIN\user','-EtwRightsOnly'
+ ```
+
+ If you ran an earlier revision of this script, it left both of the grants above
+ on the box. 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.
vilimpoc.org / repos / dotfiles / blobdiff