Jump to content

ProcessClose bug?


Recommended Posts

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.

Link to comment
Share on other sites

  • Developers

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

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

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
Link to comment
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.

Link to comment
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.
Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...