-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't read process name (and many other prop) on Windows 2012 #599
Comments
This isn't a bug. This is just Windows 2012 having better permissions. Run your python script at the same level of permissions or the same user. Sysinternal's PsExec may help. |
I'm not sure: I have lot of tools I can run with unprivileged user to see almost any information on any process, nothing to do with Windows 2012 security. What I except is to do same things with psutil too. |
What other tools are you using and are you sure they aren't elevating themselves? |
You can use Process Explorer or anything else, also Task Manager, with an unprivileged user. I think the bug is in _psutil_windows.pyd |
Task Manager doesn't show the other processes until you select "Show Processes from All users" which has a UAC elevation icon next to it. |
No, I'm not an Administrator, just member of Users group and I'm almost sure I can use even old program without UAC support. I think in some function, as psutil_proc_exe, PROCESS_QUERY_LIMITED_INFORMATION should be used instead of PROCESS_QUERY_INFORMATION. I'm going to rebuild _psutil_windows.pyd with this patch just to give it a try. |
Process Explorer is able to do that because it is installed as a system driver whereas psutil is not. Since this is a question which comes up very often I think we better add a new section in the doc describing the privileges limitations of psutil on Windows. I like your suggestion about PROCESS_QUERY_LIMITED_INFORMATION though so I'm looking forward to see what you'll find out. |
You would still need elevated privileges for Process Explorer to install the driver. |
procex.exe was just unzipped on the desktop and it was never installed or executed by an administrator Unfortunately PROCESS_QUERY_LIMITED_INFORMATION can't help with OpenProcess() and AccessDenied... I have the same error. There is a solution on MSDN thet may help, at least to read the process name and some other info and it may be implemented as a fallback: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686701.aspx Again, Process Explorer work with unprivileged user, not installed as a driver, not elevated, never executed as Administrator, and can show ANY process on the server, like any 'ps' do. |
@abravetti: thanks for the insight. I committed 29defce. With this we can get the name() of all running processes, no matter what your privileges are. It seems we might do the same for exe(). I will look into that later. |
It seems we can't determine the exe() after all, only the name(). |
great! thank you! |
* master: use 'with open' to make sure file is closed test_process_create_time: always test against the rounded time too don't test physical cpu count on systems that don't include it don't test num_ctx_switches on unsupported kernels fix compilation warning about possible misuse of XDECREF fix race condition in wait_for_file fix flake8 error fix permission errors when running from /root fix giampaolo#607: DUPLEX_UNKNOWN is not defined on old RedHat versions fix giampaolo#606: Process.parent() may swallow NoSuchProcess exceptions (#race-condition) attempt to fix xargs on OSX giampaolo#602: move pre-commit hook into a separate file fix giampaolo#602: add GIT pre-commit hook fix failing test on Windows C styling: if unification forgot to close the handle fix giampaolo#599 (Windows): process name() can now be determined for all PIDs add test windows: refactoring of the alternative process info implementation fix typo in documentation
I'm not able tu read the process name of a Windows Service running psutil with an unprivileged user.
Windows XP:
Windows 2012:
The text was updated successfully, but these errors were encountered: