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 standard
registry functions directed at the virtual HKEY_PERFORMANCE_DATA key, so the error message means that PsList was
unable to query the virtual performance keys. When you point PsList at a remote system and don't have administrative
rights on that system or the system isn't running the Remote Registry service, then PsList reports the same error, but I
had never seen the message when using PsList to look at a local system. Something was different about Vista, and I set
out 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 the
PerfLib 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's
permissions. 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 such
as PsList queries a counter, the performance API loads the associated DLL and calls functions in the DLL that return the desired data. Because the
DLLs 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's
therefore the responsibility of a performance data source, which might be the kernel or an application such as Microsoft IIS, to prevent unauthorized
access to its performance data.
Preventing read access to the PerfLib key is therefore the equivalent of having a performance DLL implement security. Although locking down
the key prevents the performance API from determining which counters are available and which DLLs provide performance data, with the exception
of add-on applications, the core registrations are constant from system to system. That means that a process can circumvent any protection the
locked-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, but
I 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 tools
like PsList as a standard user.
Another case closed by Process Monitor!
End of Article
Register
