TS: OpenProcess fails
Manfred Möbus
a process with a given process id exists on my computer - I use this to
check if a certain process which once registered itself with its process
id is still executing.
While this works well on my workstation, it fails when my program runs
on terminal server.
The handle returned is 0 and GetLastError returns Error_Access_Denied.
This result is even returned when I use the process id of the calling
process.
In case of an invalid process id, GetLastError returns
Error_Invalid_Parameter, which is different. So I might use this
information to find out if a process still exists, but I would prefer to
find a better documented way.
What kind of access rights are needed to perform the function
OpenProcess. The user executing the querying process is member of the
Administator group on the terminal server.
Thanks for any help
Manfred
------------------my return address contains additional 'f' letters to
fools spammers. You should remove them all to come to the actual
address.
Phil Wilson
should find some sample msdn code to set it.
Manfred Möbus <moe...@fafefb.de> wrote in message
news:371B5965...@fafefb.de...
Felix Kasza [MVP]
> I am using OpenProcess(ProcessQueryInformation,FALSE,anId) to query, if
> a process with a given process id exists on my computer - I use this to
> check if a certain process which once registered itself with its process
> id is still executing.
Not a good idea at all, as a PID may be reused. If that happens while
you are not looking, you have a problem. I think a better solution might
be to open the process once (or, if you launch it, to keep the handle
from CreateProcess()). If ever you want to know whether the process is
still going, call WaitForSingleObject() on its handle.
> While this works well on my workstation, it fails when my program runs
> on terminal server.
Is the target process running in the same TS session?
--
Cheers,
Felix.
If you post a reply, kindly refrain from emailing it, too.
Note to spammers: fel...@mvps.org is my real email address.
No anti-spam address here. Just one comment: IN YOUR FACE!
John Paulsson
"Manfred Möbus" wrote:
> I am using OpenProcess(ProcessQueryInformation,FALSE,anId) to query, if
> a process with a given process id exists on my computer - I use this to
> check if a certain process which once registered itself with its process
> id is still executing.
>
> While this works well on my workstation, it fails when my program runs
> on terminal server.
I'm having problems with some system processes under the standard NT Wks
and Server. One of these system services is the "csrss.exe" process, are you
sure you can open this successfully on your Workstation? If so, how?
// jP
Felix Kasza [MVP]
> I'm having problems with some system processes under the standard NT Wks
> and Server.
If you have it, enable SeDebugPrivilege, which overrides the ACL on the
process object. If you don't, you'll need to be SYSTEM to open csrss.
John Paulsson
"Felix Kasza [MVP]" wrote:
> John,
>
> > I'm having problems with some system processes under the standard NT Wks
> > and Server.
>
> If you have it, enable SeDebugPrivilege, which overrides the ACL on the
> process object. If you don't, you'll need to be SYSTEM to open csrss.
>
Ahh, interesting. Is SeDebugPrivilege a specific flag for the OpenProcess()
function or a security level? But have to try it later on. Isn't it dangerous
to let an enduser application have debug privilegies? Because I've seen PSAPI
examples from MSDN which hasn't solved this issue at all.
// jP
Felix Kasza [MVP]
> Ahh, interesting. Is SeDebugPrivilege a specific flag for the OpenProcess()
> function or a security level?
It is a privilege. To see it used, take a peek at
http://mvps.org/win32/processes/fkill.html.
> Isn't it dangerous to let an enduser application have debug privilegies?
Well, privs are user-specific, and any app that a user runs gets a copy
of his then-current privileges to play with. So, yes, letting J. Random
Luser have the debug privilege is as close to a total system compromise
as you can come without nailing the password list to the church door.
Obviously, this is why it is given to admins only by default.
The idea behind SeDebugPrivilege being able to override security on
process objects is that you wouldn't ever be able to debug a service
running as SYSTEM without it. (Well, two or three possibilities do come
to mind, but they are all klugy.)
Slava M. Usov
> The idea behind SeDebugPrivilege being able to override security on
> process objects is that you wouldn't ever be able to debug a service
> running as SYSTEM without it. (Well, two or three possibilities do come
> to mind, but they are all klugy.)
One addition: you don't *actually* have to enable SeDebugPrivilege when
running as admin in order to do something about the csrss.exe and its
buddies. They are all equipped with security descriptors that allow
everything to system and restricted access to admin, but the restricted
(hehe) access includes READ_CONTROL | WRITE_DAC, so you, theoretically,
could, first, open the process objects for READ_CONTROL | WRITE_DAC, update
the DACL to include whatever specific right you need (like
PROCESS_TERMINATE), and then reopen the process for that particular access.
Practically, though, these manipulations may only be done by admin, who
already possesses the SeDebugPrivilege shortcut...
I often think, why the hell they decided to allow potentially full access,
but with a "feature" of requiring to do some magic to gain it (I talk only
about administrators here; for others, there is no access whatsoever, even
with quirks - and I'm ignoring the getadmin bug). A sort of fool proofing?
Should be configurable, at the very list... it is such a bother to use some
other utility to stop that (specifically, inetinfo.exe) process, rather than
just click "Terminate" in the Task Manager. Same applies to affinity
business, which is only useful for fine tuning services on SMP machines,
but - oops - you can't do that with the taskman. What the hell do they think
a merit of tweaking affinity of MSWORD.EXE?
-- Slava
Please send any replies to this newsgroup.
Felix Kasza [MVP]
> you don't *actually* have to enable SeDebugPrivilege [...] you,
> theoretically, could, first, open the process objects [...],
> update the DACL [...], and then reopen the process for that
> particular access.
If you knew me personally, Slava, you'd know I am _far_ too lazy for all
that. :-)
> it is such a bother to use some other utility to stop that
> (specifically, inetinfo.exe) process
I strongly suspect that the reasoning is either, as you say,
fool-proofing (so J. Random Luser can't kill everything in sight without
doing some extra work), or just random chance (i.e., the way the default
DACL is set up, and nobody really was interested in what taskmgr.exe can
or cannot do).
> Same applies to affinity business, [...] but - oops - you can't do
> that with the taskman.
I don't see much sense here. That would require some manual interaction
every time the process gets started, far too much of a nuisance. Either
a process takes care of itself wrt affinity, or it doesn't ...
Slava M. Usov
> If you knew me personally, Slava, you'd know I am _far_ too lazy for all
> that. :-)
I suspected that :-) BTW, have you ever noticed, in order to do something a
new smart way, a person must be lazy enough - otherwise it's so apt to do
that the good old routine way...
> I don't see much sense here. That would require some manual interaction
> every time the process gets started, far too much of a nuisance. Either
> a process takes care of itself wrt affinity, or it doesn't ...
I disagree here. Take some 4-way SMP machine, for example, and imagine it's
used as IIS and MS SQL server. Most serious admins I know would certainly
desire to separate CPUs the processes are running on. Can you set affinity
of these processes from *inside* them? No. While sometimes the vendor of the
SMP machine provides some utility for setting affinities, chances are you
don't have one (gotta admit, though, that *now* almost all of them seem to
bundle the utility). And if you don't have it, you might guess you could use
the Task Manager for it - but no! As for the fact that one would have to set
the affinities every time the process starts, for 4-way (and up) servers
these events are really rare and carefully administered, so it's not usually
a problem.
Actually, though, with time passing, this is less and less of a problem,
because, as I said, most vendors are aware.
Felix Kasza [MVP]
> Take some 4-way SMP machine, for example, and imagine it's
> used as IIS and MS SQL server.
I wouldn't set affinities on those. Both use IOCPs to dispatch threads,
both control concurrency themselves through the IOCPs, and neither will
profit from running on what amounts to two 2way boxes. I tend to see the
problem the other way round: High-end server software that ignores SMP
issues has a fundamental design flaw.
Slava M. Usov
> > Take some 4-way SMP machine, for example, and imagine it's
> > used as IIS and MS SQL server.
>
> I wouldn't set affinities on those. Both use IOCPs to dispatch threads,
> both control concurrency themselves through the IOCPs, and neither will
> profit from running on what amounts to two 2way boxes.
True, but... on heavily used systems, when threads of chief processes
compete for CPUs, this *might* make sense, because restricting some
processes to disjoint subsets of CPUs may:
1. Make "affinitizied" execution more deterministic and thus stabilize its
response times. This does hurt the overall throughput, but still makes the
system *look* more responsive in the user's eyes (infamous human factor).
Some admins consider this very important, because most of help desk calls
are not due to major system breakdown, but due to perceived jerky behavior.
2. More subtle but important issues of cache hits locality and consistency.
Some SMP systems are made of modular CPU blocks, like two 4-way CPU boards.
While the intra-board buses are very high-speed, the inter-board bus is not.
And a thread drifting from one board to another may result in very poor
overall system performance. In this case it's almost mandatory to make one
process execute on board 1, and another on board 2. This effectively results
in one machine operating like two machines, but, still, the inter-board link
has still more capacity than even full-duplex 100 Mb Ethernet (with all
networking overhead taken into account), and that's the primary reasons such
designs exist.
Having said that, I also have to say that it was not my aim to convince
everybody that once he's got an SMP box, his first goal is to tweak
affinities. No. I'm just well aware of how most hardcode sysadmins see that,
and they *like* to have this ability. And, unfortunately, the Task Manager
is a toy with this regard.