_STARPID & @PID[] after START /ELEVATED
- Thread starter vefatica
- Start date
- May
- 13,802
- 211
I don't understand your remark. TASKLIST shows the PID of a process started with "START /ELEVATED" so I'd think @PID[] should be able to get it. I don't know about START/_STARTPID ... Does it use CreateProcess()?
rconn
Administrator
- May
- 13,681
- 256
Staff member
It does not use CreateProcess(); that API cannot start elevated tasks from a non-elevated process. START /elevated uses ShellExecuteEx(), which does not return a PID. It does return a process handle, but Windows will not let a non-elevated process query process information for an elevated process. (It'd be a useless pile of security junk if it did allow that!)
- May
- 13,802
- 211
What about @PID[]?
rconn
Administrator
- May
- 13,681
- 256
Staff member
What about it?
If you're an admin user, @PID will use an undocumented API to return a pseudo-PID (not the real one, but one that Windows will associate with the process).
However, it's useless, because you cannot actually do anything with the PID. Even if you had the real one, Windows will still not let you do anything with that PID unless you're running in an elevated process. (In which case, TCC would have used CreateProcess(), and this whole exercise would have been pointless.)
So unless you just like to look at PIDs and imagine what you would do with them if you could actually do anything with them (and you can't), you can just substitute @RANDOM.
If you're an admin user, @PID will use an undocumented API to return a pseudo-PID (not the real one, but one that Windows will associate with the process).
However, it's useless, because you cannot actually do anything with the PID. Even if you had the real one, Windows will still not let you do anything with that PID unless you're running in an elevated process. (In which case, TCC would have used CreateProcess(), and this whole exercise would have been pointless.)
So unless you just like to look at PIDs and imagine what you would do with them if you could actually do anything with them (and you can't), you can just substitute @RANDOM.
- May
- 13,802
- 211
As an admin uner UAC, @PID[elevated] is 0. Running elevated, it returns the actual PID ... the one seen in TaskMgr.
And that PID's not entirely useless. My WHICHWIN can filter on it to show its (and only its) windows. There's probably more you could do with it (but probably nothing too exciting).
Vince, I am not quite sure what you meant when you said "As an admin user UAC". If you are running Windows 7 (and I tend to believe that you are from previous postings but I could be wrong) there are no "true" "Administrative" users unless you "dug up", "revived", and unhid the true "Administrator" account. First user created on a Windows 7 machine is only a pseudo-administrator (i.e., will be bugged by UAC unless UAC is turned off), and programs that were not launched "elevated" are not administrative at all, and have no "access" to administrative things. - Dan
- May
- 13,802
- 211
That's me ... the pseudo-admin ... and I can do a lot without having to ask or reply to UAC at all ... run any of the MSC plugins (configure services, change security policy), configure network stuff, and more. I can seamlessly do nearly anything "administrative" (except set the time) without dealing with UAC.
Vince, Please excuse me if this is a stupid question. Didn't you have to turn UAC off entirely for that to be the case? I haven't turned mine off because it helps to keep me from making stupid mistakes (which, as I have said previously, I'm quite fond of). I do keep an "Elevated" TCC session running at all times, but I try real hard to avoid using it when I don't actually require administrative privileges. - Dan
- May
- 13,802
- 211
No, I have not turned UAC off. It simply lets me do those things. If you are the "pseudo-admin" just type something like "services.msc" or "secpol.msc" (+ enter) in the start menu.