The Case of the Unexpected PsList Error

Not long after I deployed Windows Vista on my main desktop system, I noticed that a process became unresponsive and appeared to be consuming excessive amounts of CPU. I had a command prompt handy, so I ran PsList to dump detailed information about the process. (For more information about the PsList utility, go to http://www.microsoft.com/technet/sysinternals/utilities/pslist.mspx.) Instead of reporting a page full of statistics like I expected, however, PsList presented the error message Failed to take process snapshot on MR-OPTERON.

PsList obtains information from the system performance counters, which an application accesses using standardregistry functions directed at the virtual HKEY_PERFORMANCE_DATA key, so the error message means that PsList wasunable to query the virtual performance keys. When you point PsList at a remote system and don't have administrativerights on that system or the system isn't running the Remote Registry service, then PsList reports the same error, but Ihad never seen the message when using PsList to look at a local system. Something was different about Vista, and I setout to learn what.

Putting my original troubleshooting mission on hold, I launched Process Monitor (http://www.microsoft.com/technet/sysinternals/processesandthreads/processmonitor.mspx) and repeated the PsList command with Process Monitor looking on. I scanned the resulting trace looking for anomalous error codes, because when they're present they almost always point to the source of a problem, and found an access denied error.

For some reason, PsList, running as a standard user because I hadn't elevated the command prompt from which I ran it, was unable to open thePerfLib registry key for read access. I was perplexed because on Windows XP I had been able to run PsList as a standard user. I launched regedit, navigated to the key, and viewed its permissions. As I suspected, standard users aren't members of any of the groups the permissions grant access to.

I confirmed that to be the reason for PsList's failure by granting the Interactive Users group read access to the key and verifying that PsList subsequently worked. Now I was left with the question of which permissions XP assigns the key. I switched to an XP test system and viewed the key'spermissions. Interactive Users have read access, explaining why PsList works as a standard user on XP systems.

I then pondered the reason for the change. The PerfLib key is where performance providers register their counters and DLLs, so when a tool suchas PsList queries a counter, the performance API loads the associated DLL and calls functions in the DLL that return the desired data. Because theDLLs execute in the context of the process into which they load, they can't implement security that can't be easily circumvented by the process. It'stherefore the responsibility of a performance data source, which might be the kernel or an application such as Microsoft IIS, to prevent unauthorizedaccess to its performance data.

Preventing read access to the PerfLib key is therefore the equivalent of having a performance DLL implement security. Although locking downthe key prevents the performance API from determining which counters are available and which DLLs provide performance data, with the exceptionof add-on applications, the core registrations are constant from system to system. That means that a process can circumvent any protection thelocked-down key is attempting to provide by directly loading performance DLLs and calling their data functions.

To make a long story short, I filed a bug against Vista SP1 and Windows Server 2008 to have Interactive Users added back to PerfLib's permissions. The reliability and diagnostics team reported back that the permissions changed inadvertently during the release of Windows Server 2003, butI convinced them it didn't make sense, so inVista SP1 and Windows Server 2008 you won't need to edit PerfLib's permissions to be able to run toolslike PsList as a standard user.

Another case closed by Process Monitor!