Re: WTSQuerySessionInformation

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I guess I can agree with you that the MSDN documentation is not clear on the subject.

Even for 2000 and XP and 2003 that MSDN page contradicts itself, contradicts its contradictions, and declarifies its contracontradictions.

Fortunately I don't need to figure this out for 2000 and XP and 2003 (not this time anyway). Fortunately I only need it for Vista, where the page very clearly says


"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message news:OMgxdTFfHHA.2216@xxxxxxxxxxxxxxxxxxxxxxx
Session zero has stopped being `the console session` starting from Vista.
That's why in Vista the section currently elected to be the console
(and sometimes `incidentally` bound to the glass terminal) shall be retrieved
with an explicit API call.
I guess I can agree with you that the MSDN documentation is not clear on the subject.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message news:ubENYBCfHHA.2376@xxxxxxxxxxxxxxxxxxxxxxx
The ActiveConsole may be in the middle of changing session ownership

Yes we agree that if the console is in the middle of changing ownership then it's not clear what I should do. My previous posting mentioned that and you mentioned that. But meanwhile, there's the other 99% where things are pretty clear and I should try to perform as specified.

How about: there's a particular event and I will notify only users that can do something about it.

That is not what the spec calls for. The spec calls for notifying the user who is affected by the event, if the user is logged in at the console. The spec calls for not notifying the user who is affected by the event if the user isn't logged in. The spec doesn't mention the possibility of notifying other users. I think we can presume that a user, who personally registers for notification of the event, doesn't want some other user to be notified just because some other user is logged in at the console when it happens.

Thnk about the headless servers where the console does not really exist.

No kidding. If a user finds a way to register for event notification on a console that doesn't exist, and the user doesn't log into a console that doesn't exist, then the user won't get notifications on a console that doesn't exist. This result seems to be both conformant to the spec and easy to achieve.

On the MSDN:
I'm not sure what the comment is.
It looks to me standard reference documentation for the API.

Are you serious? Here, maybe you should read these parts of it again:

http://msdn2.microsoft.com/en-us/library/aa383838.aspx
To determine whether your application is running on the physical console,
you can do the following:
As described previously, call WTSQuerySessionInformation and specify
WTS_CURRENT_SESSION for the SessionId parameter and WTSSessionId for the
WTSInfoClass parameter. The session ID returned in ppBuffer is zero for
the Terminal Services console session.

Got it. If the session ID is zero then I'm running on the physical console.
If the session ID is nonzero then I'm running elsewhere (either serving a
remote user or patiently waiting for a fast switcher to come back).

Applications run in the console session only if the machine administrator (not just a member of the Administrators group) logs on to the physical console. Usually, only services can run in session zero, and applications run in other sessions.

Got it. If the session ID is zero then I'm running on the physical console
AND the machine administrator is logged in. If the session ID is nonzero
then either I'm running on the physical console and a normal user or other
member of the administrators group is logged in or I'm running elsewhere.
Well, at this point in time I don't care if the machine administrator is
logged in or not, I only care if I'm running on the local console. So if
the session ID is zero (and user is machine administrator) OR the session ID
is some undocumented magic number (and user is normal or other member of
administrators group) then I'm running on the physical console. If the
session ID is neither zero nor the undocumented magic number then I'm
running elsewhere.

Windows Server 2003 and Windows XP: Session zero might not be attached to the physical console. This is because session zero can be attached to a remote session.

Got it. If the session ID is zero then I might be running on the physical
console (and maybe or maybe not the user is the machine administrator,
depending on which preceding rule we believe), or I might be running in a
remote session. If the session ID is an undocumented magic number then
maybe we might figure out if I'm running on the physical console (depending
on which preceding rule we believe). If the session ID is neither zero nor
the undocumented magic number then I'm running elsewhere -- no, wait...

the next user to log on uses session one

OK, there's not a simple undocumented magic session ID number which tells us
if we're running on the physical console, but there's an undocumented magic
algorithm that can figure it out. Why do I think I'm getting warmer now?

Windows 2000 Server and Windows 2000 Professional: Session zero will be attached only to the physical console.

Theoretically that's OK. I don't have to care about Windows 2000 for this
particular piece of code... maybe.

Windows Vista:

Um, no. This page doesn't single out Windows Vista. Obviously Windows
Vista has the same rules as Windows XP. That's why there haven't been tons
of articles telling us how to change tons of code to deal with the
differences between Windows XP and Windows Vista. Well, either that, or
else Windows Vista obviously has the same rules as Windows 2000. Well,
either that, or we're still waiting for specifications to be decided for
Windows Vista.




"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message news:uEnZFpAfHHA.4552@xxxxxxxxxxxxxxxxxxxxxxx
The ActiveConsole may be in the middle of changing session ownership
(for example, a FUS switch, or other TS-in/TS-out scenarios.
Depending on how reliable/resilient your code needs to be,
there might be some complicated schema that monitors session change events
from the session control manager.

On the design:
`There's a particular event that is relevant only at the console`.
How about: there's a particular event and I will notify only users that
can do something about it.
Thnk about the headless servers where the console does not really exist.

On the MSDN:
I'm not sure what the comment is.
It looks to me standard reference documentation for the API.


"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message news:%23DrPWa9eHHA.4128@xxxxxxxxxxxxxxxxxxxxxxx
OK, I've called WTSGetActiveConsoleSessionId in several situations including this one, and I'll try to find what API gets the current session ID. Actually this makes me figure out that there might not be a solution, because the physical console might be in the middle of changing ownership at the time.

The reason for finding out whether I'm running on the physical console or not, in this case, is one particular situation that came up yesterday. When detecting one kind of event that's being monitored, if the affected user is logged in at the console then I should call WTSSendMessage, but if the affected user isn't logged in at the console then I should do nothing.

Meanwhile, what do you think about that MSDN page?
http://msdn2.microsoft.com/en-us/library/aa383838.aspx


"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message news:eE%23T$t5eHHA.4020@xxxxxxxxxxxxxxxxxxxxxxx
How about WTSGetActiveConsoleSessionId ?
You compare the current session ID with e active console ID,
and, you should be done.
Why needing to know that is relevant is maybe the next good questions

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message news:%23tH1n4yeHHA.4128@xxxxxxxxxxxxxxxxxxxxxxx
http://msdn2.microsoft.com/en-us/library/aa383838.aspx
To determine whether your application is running on the physical console,
you can do the following:
As described previously, call WTSQuerySessionInformation and specify
WTS_CURRENT_SESSION for the SessionId parameter and WTSSessionId for the
WTSInfoClass parameter. The session ID returned in ppBuffer is zero for
the Terminal Services console session.

Got it. If the session ID is zero then I'm running on the physical console. If the session ID is nonzero then I'm running elsewhere (either serving a remote user or patiently waiting for a fast switcher to come back).

Applications run in the console session only if the machine administrator (not just a member of the Administrators group) logs on to the physical console. Usually, only services can run in session zero, and applications run in other sessions.

Got it. If the session ID is zero then I'm running on the physical console AND the machine administrator is logged in. If the session ID is nonzero then either I'm running on the physical console and a normal user or other member of the administrators group is logged in or I'm running elsewhere. Well, at this point in time I don't care if the machine administrator is logged in or not, I only care if I'm running on the local console. So if the session ID is zero (and user is machine administrator) OR the session ID is some undocumented magic number (and user is normal or other member of administrators group) then I'm running on the physical console. If the session ID is neither zero nor the undocumented magic number then I'm running elsewhere.

Windows Server 2003 and Windows XP: Session zero might not be attached to the physical console. This is because session zero can be attached to a remote session.

Got it. If the session ID is zero then I might be running on the physical console (and maybe or maybe not the user is the machine administrator, depending on which preceding rule we believe), or I might be running in a remote session. If the session ID is an undocumented magic number then maybe we might figure out if I'm running on the physical console (depending on which preceding rule we believe). If the session ID is neither zero nor the undocumented magic number then I'm running elsewhere -- no, wait...

the next user to log on uses session one

OK, there's not a simple undocumented magic session ID number which tells us if we're running on the physical console, but there's an undocumented magic algorithm that can figure it out. Why do I think I'm getting warmer now?

Windows 2000 Server and Windows 2000 Professional: Session zero will be attached only to the physical console.

Theoretically that's OK. I don't have to care about Windows 2000 for this particular piece of code... maybe.

Windows Vista:

Um, no. This page doesn't single out Windows Vista. Obviously Windows Vista has the same rules as Windows XP. That's why there haven't been tons of articles telling us how to change tons of code to deal with the differences between Windows XP and Windows Vista. Well, either that, or else Windows Vista obviously has the same rules as Windows 2000. Well, either that, or we're still waiting for specifications to be decided for Windows Vista.

Meanwhile, back at the unfunny farm:

How can I figure out if I'm running on the physical console? (In Vista.)









.

Relevant Pages

  • Re: WTSQuerySessionInformation
    ... The ActiveConsole may be in the middle of changing session ownership ... because the physical console might be in the middle of changing ownership ... If the session ID is zero then I'm running on the physical ... This page doesn't single out Windows Vista. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WTSQuerySessionInformation
    ... OK, I've called WTSGetActiveConsoleSessionId in several situations including this one, and I'll try to find what API gets the current session ID. ... Actually this makes me figure out that there might not be a solution, because the physical console might be in the middle of changing ownership at the time. ... If the session ID is zero then I'm running on the physical console. ... This page doesn't single out Windows Vista. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WTSQuerySessionInformation
    ... Yes we agree that if the console is in the middle of changing ownership then it's not clear what I should do. ... the Terminal Services console session. ... then either I'm running on the physical console and a normal user or other ... This page doesn't single out Windows Vista. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WTSQuerySessionInformation
    ... You compare the current session ID with e active console ID, ... nonzero then either I'm running on the physical console and a normal user ... This page doesn't single out Windows Vista. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: problems using ProcessIdToSessionId
    ... >>doesn't mean the user using your program is sitting at the ... > Lol. ... And, since the session originated on the console, it was in fact session #0; ... you simply "stole" the session away from the physical console and ...
    (microsoft.public.win32.programmer.kernel)