- 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:
-
- ```powershell
- whoami /priv | findstr SeSystemProfilePrivilege
- xperf -on base ; xperf -stop C:\Temp\trace.etl
- ```
-
- Analysis never needed any of this — `wpa.exe` opens an existing `.etl` as a
- plain user. This is only about collection.
-
- The rights step runs **first** in the elevated half, and `-EtwRightsOnly` runs
- it and nothing else. It is seconds of LSA and registry work where a full run is
- dominated by the three Visual Studio passes, which take minutes even with
- nothing to do:
+ 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:
vilimpoc.org / repos / dotfiles / blobdiff