Blogs

The Case of the Unexpected PsList Error

  • Comments 18
  • Likes

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 as one of my troubleshooting steps. Instead of reporting apage full of statistics like I expected, however, PsList printed its banner, an error message, and exited:

 

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 message indicated 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 Windows Vista and I set out to learn what.

Putting my original troubleshooting mission on hold, I launched Process Monitor and repeated the PsList command with Process Monitor looking on. I didn’t have a firm expectation that it would reveal the cause of the problem, but experience has taught me that Process Monitor (and its predecessors Filemon and Regmon) often solves seemingly unexplainable problems like this. I scanned the 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 (note the presence of two new performance-related groups, Performance Log Users and Performance Monitor Users):

 

I quickly 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 what permissions Windows XP assigns the key. I switched to a Windows XP test system and viewed the key’s permissions. Sure enough, Interactive Users have read access, explaining why PsList works as a standard user on Windows XP systems:

I then pondered the reason for the change. I suspected the new permissions close an information disclosure hole, but after some thought I concluded that they aren’t closing any hole.  The PerfLib key is where performance providers register their counters and DLLs, so when a tool like PsList queries a counter the performance API loads the associated DLL into the querying process 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 like Internet Information Server (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. While locking down the key prevents the performance API from determining what counters are available and what 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 Windows Vista Service Pack 1 (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 in 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!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks Mark, I was hoping this would be corrected soon.

  • Why use the perf stuff over whatever taskmgr and process explorer uses?

  • Is this why TCPView doesn't list process name and icons anymore?

  • Why did some of the other comments (including one from Mark) disappear from this post?

  • So what about the unresponsive process that leads you to launch PsList in the first place ?

    I'd like to know how you handle a process consuming CPU, because it happens from time to time and i'd be glad to learn from you.

    Thanks anyway.

  • Nice job. mark.

    I love your posts in this blog.

  • Great Article. Very useful.

    However, it would be possible for my c++ application to gain read access to the PerfLib key? (having access to HKEY_PERFORMANCE_DATA key without adding manually the Interactive Group to the PerfLib’s permissions).

  • Thats a very good point Souplounite maybe that will be the next blog entry.

    You wouldn't have access to the key decoder you would have to load the performance dll's in your application using LoadLibrary() and then using GetProcAddress() on the on the functions you would want to use. It would be easier just to alter the permission.

    nice work mark the sysinternals tools are invaluable to any sys admin/developer. Also I seen some debate on how they are packaged and I love the small single exe! installer pffff.

  • hmmmm when ever i hear the words "Windows Vista" i cringe.

    - Steve

  • pslist under vista...

    If I run in a cmd.exe that has been run as administrator, this works fine.  pskill similarly.   Aren't there processes that the user launched that the user should be able to see and kill? isn't this just a security bug in windows?

  • Ah, thanks for that...    

    I noticed that as soon as I migrated to Vista, but couldn't figure out why the change was done.  Didn't seem to have the necessary security impact...

    Glad this will be resolved shortly.

  • FYI - I had a surprisingly tough time refinding your blog.

    The bookmark I had for your blog is now a dead link:

    http://www.microsoft.com/technet/sysinternals/Blog/

    Shouldn't a redirect to the current location have been maintained?

  • Thank you very much for sharing your thoughts. It is always great pleasure to read your posts.

  • The same thing occurs on Server 2003, it appears. I am running a standalone 2K3 machine, and pslist.exe gives the same "Failed to take process snapshot on %computername%" when run in a remote desktop session as a user. It works when run under an administrative account, and the same workaround you supply above has solved the issue for my user account.

  • So,

    I deleted the MMCSS service (sc delete MMCSS) just for test, but how do I re-create it? can you make a .reg file  including info of this service?