-
-
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
Name field sometimes None on Windows #627
Comments
Hmmm... interesting. I've never seen
The reason we have two implementations for the same thing is because the first method is faster (so we attempt it first) but it fails with The code you pasted shows we can potentially use a third method to determine the process name, that is I'm not sure where Line 276 in 2c76acd
...then reinstall from sources. If you don't have Visual Studio (hence you cannot reinstall) you can figure out where _pswindows.py is located with:
...modify it in place, then re-run your code. |
For future reference: I've tried As for the issue at hand, I still can't figure out where |
I think that is because Line 290 in 3916125
I guess there are more similar issues since my program stop working after upgraded to psutil v3.0.1. |
Ahhh wait. I didn't realize you were using
|
...as for the other errors after upgrading to psutil 3.0.1: I removed a lot of deprecated APIs in 3.x so it's likely you'll get into |
Sorry for my absence on this issue! This bug is actually tricky to reproduce - I got it when I was running Blender and rendering with NVIDIA CUDA - somehow, psutil was unable to pick up the blender-app.exe render process, while my (unelevated) task manager was. If you have a NVIDIA card and some spare time, you can try to reproduce this bug by downloading Blender, enabling GPU rendering, opening a Cycles scene, and rendering it. While rendering, try to use I definitely would like to test this further - I have VS/VC++ installed, so it's easy for me to rebuild. When I get a chance (sometime late this month or next month), I'll try to reproduce the bug again, and when I do, get some (hopefully helpful) debugging info for you! |
I think there's no bug here. You're getting |
The bug isn't that it's returning None due to In the code snip above, I was able to successfully access Windows services (WMI/winmgmts) to determine the PID and process name. Depending on the OS, there may be other alternate APIs that can access this info as well. (Like you said, Task Manager/ProcExp may hinge on various services for their information... and if they can, it might be possible for you, too!) |
Installing psutil as a windows service is not an option (assuming it's even possible). We already extensively discussed this possibility.
|
print repr(psutil._psplatform.cext.proc_name(p.pid)) this lines showed all the process names on my system instead of None. when using as_dict() Seems to be something funky with as_dict and name. See my example below.
python 2.7.4 windows 7 home, psutil 3.0.1 |
You were right: there was a (serious) bug preventing to retrieve process name for PIDs owned by another user. From now on psutil will be able to retrieve name for all processes. See 1c27b34. |
Sometimes, for some odd reason, the psutil returns a process with a name of
None
.For instance, using this code:
I'll get output like this:
So I then tried playing with win32api a bit to grab the file name:
Which resulted in this error:
Supposedly, you can do some Windows magic to ask for special privileges for making OpenProcess work, but it seemed a bit too hacky at the time, so I avoided it. (You may opt to try this in the future, though!
OpenProcessToken
is the starting point.)I took a cursory look at your code, and it looks like you use OpenProcess as well for process information. (I might be wrong about how you use it... feel free to correct me!)
To work around the issue, I wrote this:
This does the trick for me, yielding:
For now, using the above code will be a workaround in case this happens.
It looks like using WMI might be an interesting vector to try. (It might even potentially fix #549... maybe.) What do you think?
The text was updated successfully, but these errors were encountered: