end18 / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

Rewrite get_process_username() in C for Windows #114

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Here's an extract of the original wj32 patch which implements process username 
retrieval in C, replacing the old implementation using WMI.
This would address the following issues:

- pywin32 dependancy no longer necessary
- removal of psutil/wmi.py script from the code base
- an order of magnitude faster (WMI was deadly slow)

The patch as-is apparently works:

>>> import psutil, os
>>> psutil.Process(os.getpid()).username
'win-7\\giampaolo'
>>>

...but when attempt to retrieve the username of all processes it crashes after 
a while:

>>> import psutil, os
>>> for p in psutil.process_iter():
...     print p.pid, p.name, p.username
...
0 System Idle Process NT AUTHORITY\SYSTEM
4 System NT AUTHORITY\SYSTEM
220 smss.exe NT AUTHORITY\SYSTEM
316 csrss.exe NT AUTHORITY\SYSTEM
364 wininit.exe NT AUTHORITY\SYSTEM
388 csrss.exe NT AUTHORITY\SYSTEM
412 services.exe NT AUTHORITY\SYSTEM
432 lsass.exe NT AUTHORITY\SYSTEM
440 lsm.exe NT AUTHORITY\SYSTEM
560 winlogon.exe NT AUTHORITY\SYSTEM
588 svchost.exe NT AUTHORITY\SYSTEM
648 nvvsvc.exe NT AUTHORITY\SYSTEM
692 svchost.exe NT AUTHORITY\NETWORK SERVICE
804 svchost.exe NT AUTHORITY\LOCAL SERVICE
836 svchost.exe NT AUTHORITY\SYSTEM
876 svchost.exe NT AUTHORITY\SYSTEM
936 audiodg.exe

No error message of any kind is returned. A window is just prompted informing 
that "python has stopped working".
Tried on Windows 7 64 bit, python 2.7 32 bit.

Original issue reported on code.google.com by g.rodola on 10 Oct 2010 at 8:53

Attachments:

GoogleCodeExporter commented 9 years ago
I've tried to debug this a little and it seems the problem occurs when building 
the username string:

    /* Build the full username string. */
    fullName = malloc(( + 1 + nameSize + 1) * sizeof(TCHAR));
    memcpy(fullName, domainName, domainNameSize);
    fullName[domainNameSize] = '\\';
    memcpy(&fullName[domainNameSize + 1], name, nameSize);
    fullName[domainNameSize + 1 + nameSize] = '\0';

This change seems to fix the issue:

- fullName = malloc(( + 1 + nameSize + 1) * sizeof(TCHAR));
+ fullName = malloc(( + 1 + nameSize + 1) * sizeof(PSTR));

Original comment by g.rodola on 10 Oct 2010 at 10:20

GoogleCodeExporter commented 9 years ago
Committed in r669.
I've also added a credits file to mention wj32 cotribution:
http://psutil.googlecode.com/svn-history/r669/trunk/CREDITS
I'm not sure if he's gonna read this but me and Jay really appreciated the work 
he has done. Thanks a lot.

Original comment by g.rodola on 10 Oct 2010 at 11:08

GoogleCodeExporter commented 9 years ago
Sorry, the patch I submitted has a memory leak. In the second "if 
(!GetTokenInformation(..." there needs to be a "free(user);".

Also, the crash occurs because space isn't reserved for the domain name. 
Somehow I left it out - that line needs to be:

fullName = malloc((domainNameSize + 1 + nameSize + 1) * sizeof(TCHAR));

Original comment by wj32...@gmail.com on 11 Oct 2010 at 5:40

GoogleCodeExporter commented 9 years ago
wj32, would you be interested in having commit access and/or become a project 
member?
Me and Jay are more focused on UNIX development and a Windows expert would be 
great to have.

Original comment by g.rodola on 11 Oct 2010 at 7:53

GoogleCodeExporter commented 9 years ago
No, I have my own project (Process Hacker) to run ;) Anyway, I don't know 
enough Python to be of much use to you guys. I would however be glad to help 
out with anything that needs adding/fixing.

Original comment by wj32...@gmail.com on 11 Oct 2010 at 8:00

GoogleCodeExporter commented 9 years ago
Ok, I'm going to CC you in new tickets involving Windows development then.
Thanks again for your help.

Original comment by g.rodola on 11 Oct 2010 at 10:17

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Updated csets after the SVN -> Mercurial migration:
r669 == revision c6c27fae9599

Original comment by g.rodola on 2 Mar 2013 at 11:55