Sign in to follow this  
Followers 0
scriptstopper

ProcessClose bug?

7 posts in this topic

#1 ·  Posted (edited)

Hi everyone & especially helpers,

ProcessClose("appname.exe") works great on a single laptop with only one user logged in.

HOWEVER; When there are multiple user accounts logged into the same computer (say Windows XP with a console user and a couple of background accounts), running the same app (say Skype.exe),

skype.exe ; Pick skype although any app this is true.

ProcessClose() fails for the user running the script to close his own app.

It only matters that the same app is running in different user sessions more than once. If the app is only running one time on the entire computer, then ProcessClose() works.

The user running the AutoIt script with ProcessClose(), is a member of Users, not Administrators. The user account can't even see other user's instances of skype.exe. With task manager, for instance, the checkbox 'Show processes from all users' is greyed out. This is typical security.

Somehow though, programmatically, AutoIt can 'see' the other instances from the other users. Use the following code to verify:

Log two or more users into the same computer and run the same app

Then run this script:

$list = ProcessList("skype.exe")
for $i = 1 to $list[0][0]
  msgbox(0, $list[$i][0], $list[$i][1])
next

AutoIt will show all instances of the application with multiple users, not only the user running the script. It makes sense that AutoIt should a) only be able to see the script's users applications and B ) of course the OS only allows autoit to close the apps in the current script user's environment.

Edited by scriptstopper

don't think i'm a freeloader. your help has been effective! here's the script contributed - thank you creator and thank you members and thank you authors of autoit!Call Conference Dial-in Script updated from time to time.

Share this post


Link to post
Share on other sites



Why would you think it is possible to kill a process that isn't owned by the current account and the specify account isn't an admin level account?

Jos


Visit the SciTE4AutoIt3 Download page for the latest versions  - Beta files                                How to post scriptsource        Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

Hi Jos,

How are you?

I think you are misinterpreting what I wrote. I am going to fix it RIGHT NOW and let's see if the conclusion is clearer for you..

Thank you very much for the criticism.


don't think i'm a freeloader. your help has been effective! here's the script contributed - thank you creator and thank you members and thank you authors of autoit!Call Conference Dial-in Script updated from time to time.

Share this post


Link to post
Share on other sites

Why would you think it is possible to kill a process that isn't owned by the current account and the specify account isn't an admin level account?

Jos

Please take another look at the question. It has been re-phrased.


don't think i'm a freeloader. your help has been effective! here's the script contributed - thank you creator and thank you members and thank you authors of autoit!Call Conference Dial-in Script updated from time to time.

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

Since you're pestering me to respond, here's my response: I'm not changing it, get over it.

Quite simply you're being silly. Task Manager is a user-interface providing access to the running processes. If it chooses to filter out processes per-user that's it's responsibility since that's how it was designed. AutoIt, on the other hand, is a scripting language. Hard-cording it with some arbitrary limit because some short-sighted user thinks that's how it should be is a terrible idea and will not be done. Work-around the problem if it's an issue. Shouldn't be hard to use ProcessList("processname"), then iterate through the list of returned processes checking the owner of each to find the correct one. Okay, so that means you have to spend a few minutes finding a ProcessGetOwner() function and then another thirty seconds writing a UDF. I'm... sorry?

Edited by Valik
Typo

Share this post


Link to post
Share on other sites

On and for the record, as a man with a set between his legs, ASKING you to respond is not "pestering"

Just because you write some code instead of being a carpenter doesn't entitle you to be rude.

It's common-sense to have some way to easily select processes only from the running user, especially when the local user doesn't have any control over other user's processes anyway.


don't think i'm a freeloader. your help has been effective! here's the script contributed - thank you creator and thank you members and thank you authors of autoit!Call Conference Dial-in Script updated from time to time.

Share this post


Link to post
Share on other sites

On and for the record, as a man with a set between his legs, ASKING you to respond is not "pestering"

It is when I already answered and closed the ticket.

Just because you write some code instead of being a carpenter doesn't entitle you to be rude.

Did it ever occur to you that continuing to pester me for answers when I've already given an answer is rude?

It's common-sense to have some way to easily select processes only from the running user, especially when the local user doesn't have any control over other user's processes anyway.

It's common sense to have some way of easily seeing all processes running, too. As for the local user not having control over other user's processes? Well that really depends on permissions and privileges, not on what some arbitrary person seems to think.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0