Re: WTSQuerySessionInformation

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



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 Terminal Services console session. ... 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
    ... 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
    ... 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)