+# ---------------------------------------------------------------------------\r
+# ETW session control for an ordinary account\r
+#\r
+# Creating or controlling an event tracing session - even a user-mode one naming\r
+# a single provider - is checked against the security descriptor ETW keeps per\r
+# provider GUID under HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security. The\r
+# default grants the session-control rights (TRACELOG_CREATE_ONDISK,\r
+# TRACELOG_CREATE_REALTIME, TRACELOG_GUID_ENABLE, TRACELOG_LOG_EVENT) to SYSTEM,\r
+# Administrators, the service accounts and BUILTIN\Performance Log Users, and to\r
+# nobody else. Its own description says members "may ... enable trace providers,\r
+# and collect event traces", and that is what membership buys:\r
+#\r
+# xperf -start MySession -on Microsoft-Windows-Kernel-Process -f trace.etl\r
+# xperf -stop MySession\r
+#\r
+# runs unelevated for a member and is "Access is denied. (0x5)" for everyone\r
+# else. Enough to trace your own application's providers without a UAC prompt.\r
+#\r
+# Membership is read into the access token at LOGON, so the account has to sign\r
+# out and back in. Any NEW logon does it - an ssh login into this box is one,\r
+# which is the quick way to check without dropping the desktop.\r
+#\r
+# WHAT THIS DOES NOT BUY: system-wide kernel traces. `xperf -on base` and\r
+# `wpr -start` drive the NT Kernel Logger, which is reserved for Administrators\r
+# and LocalSystem - Microsoft documents Performance Log Users access as\r
+# explicitly NOT extending to it. Measured here, so that nobody repeats it: with\r
+# the account in the group, SeSystemProfilePrivilege ("Profile system\r
+# performance") granted to that group, and an explicit ACE giving the group\r
+# TRACELOG_ACCESS_KERNEL_LOGGER on SystemTraceControlGuid - all three in place,\r
+# across a reboot - xperf still answered\r
+#\r
+# xperf: error: NT Kernel Logger: Access is denied. (0x5).\r
+#\r
+# It is not a check an ACE overrides. Those two grants were dropped again rather\r
+# than left on the box earning nothing, and CPU sampling and whole-system traces\r
+# are elevated work: run xperf, wpr or VTune from an Administrator prompt.\r
+#\r
+# Analysis needs none of this either way - wpa.exe opens an existing .etl as a\r
+# plain user.\r
+# ---------------------------------------------------------------------------\r
+Write-Step 'ETW session control (non-elevated user-mode tracing)'\r
+$PerfLogUsersSid = 'S-1-5-32-559' # BUILTIN\Performance Log Users\r
+try {\r
+ # Fall back to the console user when the caller did not name one: with\r
+ # over-the-shoulder elevation that is the person who started\r
+ # setup-windows.bat, which is who wants to trace.\r
+ $target = $TraceUser\r
+ if (-not $target) {\r
+ $target = (Get-CimInstance Win32_ComputerSystem -ErrorAction SilentlyContinue).UserName\r
+ if ($target) { Write-Host " No -TraceUser given; using the console user $target" }\r
+ }\r
+\r
+ if (-not $target) {\r
+ Write-Warning 'No account to add to Performance Log Users (pass -TraceUser DOMAIN\user).'\r
+ Write-Warning 'To do it later:'\r
+ Write-Warning ' net localgroup "Performance Log Users" DOMAIN\user /add'\r
+ } else {\r
+ # Resolve to a SID first: it validates the name, and it is what the\r
+ # membership check compares, so a member spelled ".\claude" in one place\r
+ # and "LATISLAB\claude" in another is still recognised as the same account.\r
+ $targetSid = (New-Object System.Security.Principal.NTAccount($target)).Translate(\r
+ [System.Security.Principal.SecurityIdentifier])\r
+\r
+ # By SID, never by name: "Performance Log Users" is localised, and\r
+ # Get-LocalGroup -SID is how this stays correct on a non-English box.\r
+ $group = Get-LocalGroup -SID $PerfLogUsersSid\r
+\r
+ # Get-LocalGroupMember throws on a group holding a SID that no longer\r
+ # resolves (a known Windows 10 bug), so a failure to READ the membership\r
+ # must not stop us from writing it - fall through and let the add report.\r
+ $already = $false\r
+ try {\r
+ $already = @(Get-LocalGroupMember -SID $PerfLogUsersSid |\r
+ Where-Object { $_.SID.Value -eq $targetSid.Value }).Count -gt 0\r
+ } catch {\r
+ Write-Host " (could not enumerate $($group.Name) members: $($_.Exception.Message))" -ForegroundColor DarkGray\r
+ }\r
+\r
+ if ($already) {\r
+ Write-Host " OK: $target is already in $($group.Name)"\r
+ } else {\r
+ try {\r
+ Add-LocalGroupMember -SID $PerfLogUsersSid -Member $targetSid.Value\r
+ } catch {\r
+ # "already a member" is only reachable when the enumeration above\r
+ # failed, and is not an error. Matched on the type NAME rather\r
+ # than in a typed catch clause: catch types are resolved when the\r
+ # script is PARSED, before the LocalAccounts module has been\r
+ # autoloaded, so naming the type there is a parse error that\r
+ # would take the whole script down.\r
+ if ($_.Exception.GetType().Name -ne 'MemberExistsException') { throw }\r
+ }\r
+ Write-Host " Added $target to $($group.Name)"\r
+ }\r
+\r
+ Write-Host ''\r
+ Write-Host " $target must sign out and back in before this takes effect." -ForegroundColor Yellow\r
+ Write-Host ' Then, from that account (NOT elevated):' -ForegroundColor Yellow\r
+ Write-Host ' xperf -start T -on Microsoft-Windows-Kernel-Process -f trace.etl' -ForegroundColor Yellow\r
+ Write-Host ' xperf -stop T' -ForegroundColor Yellow\r
+ }\r
+} catch {\r
+ Write-Warning "Performance Log Users membership failed: $($_.Exception.Message)"\r
+ Write-Warning 'Do it by hand with:'\r
+ Write-Warning ' net localgroup "Performance Log Users" <user> /add'\r
+}\r
+\r
+if ($EtwRightsOnly) {\r
+ # `exit` inside the try still runs the finally below, so the transcript is\r
+ # stopped and the log is left readable by the non-elevated caller.\r
+ Write-Host "`n-EtwRightsOnly: skipping the installs." -ForegroundColor Green\r
+ exit 0\r
+}\r
+\r
+\r