- Three separate things are in the way, and all three have to be dealt with:
-
- 1. Creating or controlling *any* ETW session — even a user-mode one naming a
- single provider — is checked against the security descriptor ETW keeps per
- provider GUID under `HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security`,
- whose **default** grants the session-control rights to SYSTEM,
- Administrators, the service accounts and `BUILTIN\Performance Log Users`,
- and to nobody else.
- 2. Switching on the *kernel* provider needs the `SeSystemProfilePrivilege` user
- right ("Profile system performance"), held by default only by
- Administrators and `NT SERVICE\WdiServiceHost` — that is the one `wpr`
- names.
- 3. The kernel logger is not covered by that default descriptor.
- `SystemTraceControlGuid` — the session both `xperf -on` and `wpr` drive —
- carries an explicit one that does not mention Performance Log Users. With
- 1 and 2 in place a user-mode session starts and the privilege is held, and
- `xperf -on base` *still* answers "NT Kernel Logger: Access is denied" while
- `wpr`'s error changes to a bare `0x80070005`; even reading that descriptor
- comes back access-denied, which is the tell. So an ACE for the group is
- added with `EventAccessControl`, `TRACELOG_ACCESS_KERNEL_LOGGER` included.
-
- The privilege and the ACE both go to the **group**, and the account then goes
- into the group, so membership alone is the switch and enabling another account
- afterwards is just `net localgroup "Performance Log Users" <user> /add`.
- `SeDebugPrivilege` is deliberately *not* granted: CPU sampling and stack walks
- of your own processes do not need it, and it is equivalent to handing out
- administrator. Worth being clear about the cost: a member of that group can
- capture system-wide kernel traces — process, image, file and registry activity
- across every account on the box, paths and command lines included.
-
- 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
- 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,
- unelevated:
+ **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: