PresentMon Fails to Collect Counters or Generate CSV Until a New Admin Session is Triggered

[dariuszk]

Hi there!

I’ve encountered a strange issue with PresentMon (CLI/UI same behavior) on a Windows 10 machine and could use some help figuring it out.
On one of my machines, PresentMon starts and appears to collect counters (as seen in Process Monitor events), but it doesn’t generate a CSV file, and even printing counters to the console with --output_stdout shows nothing. Here’s the plot twist: I discovered a bizarre workaround that makes it work, but it’s far from ideal ( because I want to collect the country automatically).

Using Process Monitor (Sysinternals), I confirmed there are no obvious file access issues (e.g., permissions for the output directory). However, PresentMon only starts collecting counters if I launch a new shell session as admin—even though the current session is already running with admin privileges! Even more surprising, I don’t need to fully start the new session—simply triggering the "Run as admin" prompt (e.g., right-click CMD, select "Run as admin," then cancel) is enough to make PresentMon suddenly wake up and start working.

In Process Monitor, I noticed that this "trick" triggers a QueryNameInfo operation, which I suspect is related to PresentMon gaining access to query a resource (possibly process name). Additionally, in Event Viewer (Security), I found an event logged when the process unblocks: "Special privileges assigned to new logon." The event details are as follows:

Security ID: SYSTEM  

Account Name: SYSTEM  

Account Domain: NT AUTHORITY  

Logon ID: 0x3E7

Privileges:  
SeAssignPrimaryTokenPrivilege  
SeTcbPrivilege 
SeSecurityPrivilege  
SeTakeOwnershipPrivilege  
SeLoadDriverPrivilege  
SeBackupPrivilege  
SeRestorePrivilege  
SeDebugPrivilege  
SeAuditPrivilege  
SeSystemEnvironmentPrivilege  
SeImpersonatePrivilege  
SeDelegateSessionUserImpersonatePrivilege

The Windows user running PresentMon is a member of the Performance Log Users group, which should provide sufficient permissions for performance counter access. I even tried running PresentMon as a SYSTEM-level process using PsExec -i -s, but this didn’t resolve the issue. It feels like Windows is gatekeeping access to some resource until I "poke" it by triggering a new admin session—or even just starting any other app as admin while PresentMon is running.
Any thoughts on what might be causing this behavior? Could it be a Windows security policy, session isolation, or something else? I’m open to any ideas or suggestions for tools to dig deeper!

[dariuszk]

I attached a debugger to see what’s going on, and from what I can tell, at startup all events go to the PMTraceConsumer::RemoveLostPresent function. Every time TrackPresent is called, it enters RemoveLostPresent(mTrackedPresents[mNextFreeRingIndex]);—so RemoveLostPresent is always triggered. It looks like events are being added to the ring buffer, but they never reach completion, and thus are always treated as lost. After the shell “tickle,” RemoveLostPresent stops being called entirely, which suggests that proper processing of events resumes only after that point.