Prev: Getting subnet mask with GetAdaptersAddresses
Next: CreateProcessAsUser from CredProv on Vista/Longhorn Server
From: Ivan Brugiolo [MSFT] on 3 Nov 2006 14:09
You don't connect *TO* a terminal.
You connect a terminal to a session.

You need to have an application running
in the session attached to the glass terminal.
First of all, you need to get the session bound to glass.
In the following example it's session #1, while your remote session is #2
G:\>qwinsta /server:ivanbrug-t1-b
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
console USTLSUUser 1 Active
rdp-tcp#0 2 ConnQ rdpwd
rdp-tcp 65536 Listen

Creating processes bound to a session is a matter of using
WTSQueryUserToken / CreateProcessAsUser.
Once you have a process in the session bound to the glass terminal,
you can get all of your non-remote video stack with it's properties and
capabilities.

--
--
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


"Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
news:802D4C4B-BB23-4648-BADA-ECFDD4494CD4(a)microsoft.com...
> Hi Ivan,
>
> Thanks for your immediate response, there are some points I wish to
> clarify:
> How can I connect to the 'glass termninal' ? My application is launched
> from
> the remote desktop session, the station\desktop used are the ones
> extracted
> from that session, which, according to what you say doesn't really
> represent
> the remote session desktop, to be able to present GUI on the remote
> desktop
> session I have to use the 'glass termninal', BUT, how can I get the
> station\desktop of the 'glass termninal' ????
>
> --
> Nadav
> http://www.sophin.com
>
>
> "Ivan Brugiolo [MSFT]" wrote:
>
>> Let me clarify some concepts first:
>> The entire video stack is sessionized.
>> When you talk about windowstation\desktop,
>> you are always speaking about 2 dimension of a 3 dimensional space.
>>
>> The system works this way:
>> Session X is attached to a terminal.
>> A terminal is the logical collction of input/HID devices and display
>> drivers.
>> When you TS into a machine, you attach an existing session (or a new
>> session)
>> to the remote terminal, and, the `glass` or `physical` terminal
>> is attached to a temporary session.
>>
>> In your case, when you TS to a machine, you may connect to session #0,
>> that, in certain legacy operative system is sometimes incidentally
>> shared by the services, or, you may connect to session #x, (with x != 0).
>> In any case, the "physical terminal" would be connected to
>> a session that is NOT the one you are using in mstsc.exe.
>>
>> That means that video hardware acceleration (and video capture / video
>> output)
>> is available only to the Winlogon.exe and csrss.exe processes
>> that runs in the session attached to the physical console.
>>
>> To solve your problem, you need to have your applications always running
>> in the session attached at the `glass termninal`, and, from ony other
>> session,
>> you need to communicate with those applications, and, gather data from
>> there.
>>
>> Now, this is easy done in a Server SKU, where you have 2 floating
>> session.
>> You can always "lock" the session attached to the glass terminal in such
>> a
>> way
>> that nothing interfears, and, in the second remote session you can
>> "control"
>> the physical terminal.
>>
>> --
>> --
>> 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
>>
>>
>> "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
>> news:2CCA5E63-14CA-4F09-BA4F-90686230F82B(a)microsoft.com...
>> > Hi,
>> >
>> > Prolog:
>> > 1. I am writing a DirectShow/DirectX oriented application.
>> > 2. This application has no real interaction with DirectShow/DirectX
>> > object
>> > other then enumerating available video & audio capture sources and
>> > presenting
>> > the capture properties.
>> > 3. This application is used to remotely manage our product on customer
>> > sites.
>> > 4. For remote management and customer support we use Microsoft's remote
>> > desktop application.
>> > 5. DirectX / Direct show is NOT supported by remote desktop.
>> > 6. Capture device enumeration fail to show all devices while executing
>> > within a remote desktop session
>> > 7. Capture device enumeration DOESN'T fail when executed by a services
>> > started through a remote desktop session.
>> >
>> > Were am I getting to?
>> > **********************
>> > Taking the above in mind ( and paragraph 7 especially ), if the service
>> > could present a GUI on the remote desktop session the problem would
>> > have
>> > been
>> > resolved, this can be done by strictly specifying the windows station
>> > and
>> > desktop to be used by the service, following is what I was doing to
>> > achieve
>> > that:
>> > a. I have created a Win32 launcher application that starts a custom
>> > service
>> > b. The launcher application is intended to be launched from the remote
>> > desktop session.
>> > c. Prior to starting the service the launcher application queries for
>> > the
>> > windows station and desktop it uses ( expected to be the desktop and
>> > stations
>> > associated with the remote desktop session from which it was
>> > executed ).
>> > d. The Application start the service providing it with the
>> > station\desktop
>> > names as startup arguments.
>> > e. The service starts ( as SYSTEM account ) and create ( using
>> > CreateProcess
>> > ) the management application ( the same application referred to at the
>> > 'Prolog' ) setting STARTUPINFO::lpDesktop to the station\desktop pair
>> > extracted from the remote desktop session by the launcher application.
>> > f. The Management application starts with SYSTEM privileges ( as it was
>> > created by the service ), however the GUI of the application is NOT
>> > created
>> > on the remote desktop session, rather, it is created on the default
>> > station\desktop pair ( WinSta0\Desktop ).
>> > g. Inspecting the station\desktop queried by the launcher application
>> > on
>> > [d]
>> > I can see that the default station\desktop ( WinSta0\Desktop ) were
>>
From: Nadav on 5 Nov 2006 05:00
Hi Ivan,

- Thanks for your response, What U suggest works fine when dealing with
WinXP ( that enable a single remote desktop session ), however, this doesn't
apply to Win2003 where multiple simultaneous sessions are available, on
Win2003 the application is getting created on a desktop/session otherthen the
WST session I am connected through.
- To resolve that I was extracting the WST Session in use through the
launcher application in the followng way:
1. I have used ProcessIdToSessionId(GetCurrentProcessId(), &dwSessionId), It
gave an ID different then the one provided by 'WTSGetActiveConsoleSessionId'
2.
DuplicateTokenEx(hToken,MAXIMUM_ALLOWED,NULL,SecurityIdentification,TokenPrimary, &hTokenDup)
3. CreateEnvironmentBlock
4. CreateProcessAsUser

THE RESULT:
CreateProcessAsUser failes with GetLastError == 87 ( The parameter is
incorrect. )

Why does this happen? how can I resolve that?

Keep in mind that this happen only on Win2003 and NOT on WinXP.

--
Nadav
http://www.sophin.com


"Ivan Brugiolo [MSFT]" wrote:

> You don't connect *TO* a terminal.
> You connect a terminal to a session.
>
> You need to have an application running
> in the session attached to the glass terminal.
> First of all, you need to get the session bound to glass.
> In the following example it's session #1, while your remote session is #2
> G:\>qwinsta /server:ivanbrug-t1-b
> SESSIONNAME USERNAME ID STATE TYPE DEVICE
> services 0 Disc
> console USTLSUUser 1 Active
> rdp-tcp#0 2 ConnQ rdpwd
> rdp-tcp 65536 Listen
>
> Creating processes bound to a session is a matter of using
> WTSQueryUserToken / CreateProcessAsUser.
> Once you have a process in the session bound to the glass terminal,
> you can get all of your non-remote video stack with it's properties and
> capabilities.
>
> --
> --
> 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
>
>
> "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
> news:802D4C4B-BB23-4648-BADA-ECFDD4494CD4(a)microsoft.com...
> > Hi Ivan,
> >
> > Thanks for your immediate response, there are some points I wish to
> > clarify:
> > How can I connect to the 'glass termninal' ? My application is launched
> > from
> > the remote desktop session, the station\desktop used are the ones
> > extracted
> > from that session, which, according to what you say doesn't really
> > represent
> > the remote session desktop, to be able to present GUI on the remote
> > desktop
> > session I have to use the 'glass termninal', BUT, how can I get the
> > station\desktop of the 'glass termninal' ????
> >
> > --
> > Nadav
> > http://www.sophin.com
> >
> >
> > "Ivan Brugiolo [MSFT]" wrote:
> >
> >> Let me clarify some concepts first:
> >> The entire video stack is sessionized.
> >> When you talk about windowstation\desktop,
> >> you are always speaking about 2 dimension of a 3 dimensional space.
> >>
> >> The system works this way:
> >> Session X is attached to a terminal.
> >> A terminal is the logical collction of input/HID devices and display
> >> drivers.
> >> When you TS into a machine, you attach an existing session (or a new
> >> session)
> >> to the remote terminal, and, the `glass` or `physical` terminal
> >> is attached to a temporary session.
> >>
> >> In your case, when you TS to a machine, you may connect to session #0,
> >> that, in certain legacy operative system is sometimes incidentally
> >> shared by the services, or, you may connect to session #x, (with x != 0).
> >> In any case, the "physical terminal" would be connected to
> >> a session that is NOT the one you are using in mstsc.exe.
> >>
> >> That means that video hardware acceleration (and video capture / video
> >> output)
> >> is available only to the Winlogon.exe and csrss.exe processes
> >> that runs in the session attached to the physical console.
> >>
> >> To solve your problem, you need to have your applications always running
> >> in the session attached at the `glass termninal`, and, from ony other
> >> session,
> >> you need to communicate with those applications, and, gather data from
> >> there.
> >>
> >> Now, this is easy done in a Server SKU, where you have 2 floating
> >> session.
> >> You can always "lock" the session attached to the glass terminal in such
> >> a
> >> way
> >> that nothing interfears, and, in the second remote session you can
> >> "control"
> >> the physical terminal.
> >>
> >> --
> >> --
> >> 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
> >>
> >>
> >> "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
> >> news:2CCA5E63-14CA-4F09-BA4F-90686230F82B(a)microsoft.com...
> >> > Hi,
> >> >
> >> > Prolog:
> >> > 1. I am writing a DirectShow/DirectX oriented application.
> >> > 2. This application has no real interaction with DirectShow/DirectX
> >> > object
> >> > other then enumerating available video & audio capture sources and
> >> > presenting
> >> > the capture properties.
> >> > 3. This application is used to remotely manage our product on customer
> >> > sites.
> >> > 4. For remote management and customer support we use Microsoft's remote
> >> > desktop application.
> >> > 5. DirectX / Direct show is NOT supported by remote desktop.
> >> > 6. Capture device enumeration fail to show all devices while executing
> >> > within a remote desktop session
> >> > 7. Capture device enumeration DOESN'T fail when executed by a services
> >> > started through a remote desktop session.
> >> >
> >> > Were am I getting to?
> >> > **********************
> >> > Taking the above in mind ( and paragraph 7 especially ), if the service
> >> > could present a GUI on the remote desktop session the problem would
> >> > have
> >> > been
> >> > resolved, this can be done by strictly specifying the windows station
> >> > and
> >> > desktop to be used by the service, following is what I was doing to
> >> > achieve
> >> > that:
> >> > a. I have
From: Nadav on 5 Nov 2006 05:53
Problem resolved, when creating the process with Inherit handles set to false
the process is created properly, HOWEVER, capture device information is still
NOT AVAILABLE!!! this information is available ONLY when creating the process
under a non WST session, hence, under \Windows\WindowStations & \Desktop all
capture devices are available while under
Sessions\%SessionId%\Windows\WindowStations& \Desktop capture devices are NOT
available

Why does this happen, how can it be resolved ?

--
Nadav
http://www.sophin.com


"Nadav" wrote:

> Hi Ivan,
>
> - Thanks for your response, What U suggest works fine when dealing with
> WinXP ( that enable a single remote desktop session ), however, this doesn't
> apply to Win2003 where multiple simultaneous sessions are available, on
> Win2003 the application is getting created on a desktop/session otherthen the
> WST session I am connected through.
> - To resolve that I was extracting the WST Session in use through the
> launcher application in the followng way:
> 1. I have used ProcessIdToSessionId(GetCurrentProcessId(), &dwSessionId), It
> gave an ID different then the one provided by 'WTSGetActiveConsoleSessionId'
> 2.
> DuplicateTokenEx(hToken,MAXIMUM_ALLOWED,NULL,SecurityIdentification,TokenPrimary, &hTokenDup)
> 3. CreateEnvironmentBlock
> 4. CreateProcessAsUser
>
> THE RESULT:
> CreateProcessAsUser failes with GetLastError == 87 ( The parameter is
> incorrect. )
>
> Why does this happen? how can I resolve that?
>
> Keep in mind that this happen only on Win2003 and NOT on WinXP.
>
> --
> Nadav
> http://www.sophin.com
>
>
> "Ivan Brugiolo [MSFT]" wrote:
>
> > You don't connect *TO* a terminal.
> > You connect a terminal to a session.
> >
> > You need to have an application running
> > in the session attached to the glass terminal.
> > First of all, you need to get the session bound to glass.
> > In the following example it's session #1, while your remote session is #2
> > G:\>qwinsta /server:ivanbrug-t1-b
> > SESSIONNAME USERNAME ID STATE TYPE DEVICE
> > services 0 Disc
> > console USTLSUUser 1 Active
> > rdp-tcp#0 2 ConnQ rdpwd
> > rdp-tcp 65536 Listen
> >
> > Creating processes bound to a session is a matter of using
> > WTSQueryUserToken / CreateProcessAsUser.
> > Once you have a process in the session bound to the glass terminal,
> > you can get all of your non-remote video stack with it's properties and
> > capabilities.
> >
> > --
> > --
> > 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
> >
> >
> > "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
> > news:802D4C4B-BB23-4648-BADA-ECFDD4494CD4(a)microsoft.com...
> > > Hi Ivan,
> > >
> > > Thanks for your immediate response, there are some points I wish to
> > > clarify:
> > > How can I connect to the 'glass termninal' ? My application is launched
> > > from
> > > the remote desktop session, the station\desktop used are the ones
> > > extracted
> > > from that session, which, according to what you say doesn't really
> > > represent
> > > the remote session desktop, to be able to present GUI on the remote
> > > desktop
> > > session I have to use the 'glass termninal', BUT, how can I get the
> > > station\desktop of the 'glass termninal' ????
> > >
> > > --
> > > Nadav
> > > http://www.sophin.com
> > >
> > >
> > > "Ivan Brugiolo [MSFT]" wrote:
> > >
> > >> Let me clarify some concepts first:
> > >> The entire video stack is sessionized.
> > >> When you talk about windowstation\desktop,
> > >> you are always speaking about 2 dimension of a 3 dimensional space.
> > >>
> > >> The system works this way:
> > >> Session X is attached to a terminal.
> > >> A terminal is the logical collction of input/HID devices and display
> > >> drivers.
> > >> When you TS into a machine, you attach an existing session (or a new
> > >> session)
> > >> to the remote terminal, and, the `glass` or `physical` terminal
> > >> is attached to a temporary session.
> > >>
> > >> In your case, when you TS to a machine, you may connect to session #0,
> > >> that, in certain legacy operative system is sometimes incidentally
> > >> shared by the services, or, you may connect to session #x, (with x != 0).
> > >> In any case, the "physical terminal" would be connected to
> > >> a session that is NOT the one you are using in mstsc.exe.
> > >>
> > >> That means that video hardware acceleration (and video capture / video
> > >> output)
> > >> is available only to the Winlogon.exe and csrss.exe processes
> > >> that runs in the session attached to the physical console.
> > >>
> > >> To solve your problem, you need to have your applications always running
> > >> in the session attached at the `glass termninal`, and, from ony other
> > >> session,
> > >> you need to communicate with those applications, and, gather data from
> > >> there.
> > >>
> > >> Now, this is easy done in a Server SKU, where you have 2 floating
> > >> session.
> > >> You can always "lock" the session attached to the glass terminal in such
> > >> a
> > >> way
> > >> that nothing interfears, and, in the second remote session you can
> > >> "control"
> > >> the physical terminal.
> > >>
> > >> --
> > >> --
> > >> 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
> > >>
> > >>
> > >> "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
> > >> news:2CCA5E63-14CA-4F09-BA4F-90686230F82B(a)microsoft.com...
> > >> > Hi,
> > >> >
> > >> > Prolog:
> > >> > 1. I am writing a DirectShow/DirectX oriented application.
> > >> > 2. This application has no real interaction with DirectShow/DirectX
> > >> > object
> > >> > other then enumerating available video & audio capture sources and
> > >> > presenting
> > >> > the capture properties.
> > >> > 3. This application is used to remotely manage our product on customer
> > >> > sites.
> > >> > 4. For remote management and c
From: Ivan Brugiolo [MSFT] on 5 Nov 2006 14:55
Are you absolutely sure that your process is created in the session
that is bound to the glass terminal ?
If you execute a simple code that enumerates the display devices,
do you ger RDPDD as your display driver, or something that
reflects the fact that you have an ATI, nVidia, etc video-card ?

--
--
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


"Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
news:D9CFD8FF-90AB-4C20-A02F-8EB3CE19F527(a)microsoft.com...
> Problem resolved, when creating the process with Inherit handles set to
> false
> the process is created properly, HOWEVER, capture device information is
> still
> NOT AVAILABLE!!! this information is available ONLY when creating the
> process
> under a non WST session, hence, under \Windows\WindowStations & \Desktop
> all
> capture devices are available while under
> Sessions\%SessionId%\Windows\WindowStations& \Desktop capture devices are
> NOT
> available
>
> Why does this happen, how can it be resolved ?
>
> --
> Nadav
> http://www.sophin.com
>
>
> "Nadav" wrote:
>
>> Hi Ivan,
>>
>> - Thanks for your response, What U suggest works fine when dealing with
>> WinXP ( that enable a single remote desktop session ), however, this
>> doesn't
>> apply to Win2003 where multiple simultaneous sessions are available, on
>> Win2003 the application is getting created on a desktop/session otherthen
>> the
>> WST session I am connected through.
>> - To resolve that I was extracting the WST Session in use through the
>> launcher application in the followng way:
>> 1. I have used ProcessIdToSessionId(GetCurrentProcessId(), &dwSessionId),
>> It
>> gave an ID different then the one provided by
>> 'WTSGetActiveConsoleSessionId'
>> 2.
>> DuplicateTokenEx(hToken,MAXIMUM_ALLOWED,NULL,SecurityIdentification,TokenPrimary,
>> &hTokenDup)
>> 3. CreateEnvironmentBlock
>> 4. CreateProcessAsUser
>>
>> THE RESULT:
>> CreateProcessAsUser failes with GetLastError == 87 ( The parameter is
>> incorrect. )
>>
>> Why does this happen? how can I resolve that?
>>
>> Keep in mind that this happen only on Win2003 and NOT on WinXP.
>>
>> --
>> Nadav
>> http://www.sophin.com
>>
>>
>> "Ivan Brugiolo [MSFT]" wrote:
>>
>> > You don't connect *TO* a terminal.
>> > You connect a terminal to a session.
>> >
>> > You need to have an application running
>> > in the session attached to the glass terminal.
>> > First of all, you need to get the session bound to glass.
>> > In the following example it's session #1, while your remote session is
>> > #2
>> > G:\>qwinsta /server:ivanbrug-t1-b
>> > SESSIONNAME USERNAME ID STATE TYPE
>> > DEVICE
>> > services 0 Disc
>> > console USTLSUUser 1 Active
>> > rdp-tcp#0 2 ConnQ rdpwd
>> > rdp-tcp 65536 Listen
>> >
>> > Creating processes bound to a session is a matter of using
>> > WTSQueryUserToken / CreateProcessAsUser.
>> > Once you have a process in the session bound to the glass terminal,
>> > you can get all of your non-remote video stack with it's properties and
>> > capabilities.
>> >
>> > --
>> > --
>> > 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
>> >
>> >
>> > "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
>> > news:802D4C4B-BB23-4648-BADA-ECFDD4494CD4(a)microsoft.com...
>> > > Hi Ivan,
>> > >
>> > > Thanks for your immediate response, there are some points I wish to
>> > > clarify:
>> > > How can I connect to the 'glass termninal' ? My application is
>> > > launched
>> > > from
>> > > the remote desktop session, the station\desktop used are the ones
>> > > extracted
>> > > from that session, which, according to what you say doesn't really
>> > > represent
>> > > the remote session desktop, to be able to present GUI on the remote
>> > > desktop
>> > > session I have to use the 'glass termninal', BUT, how can I get the
>> > > station\desktop of the 'glass termninal' ????
>> > >
>> > > --
>> > > Nadav
>> > > http://www.sophin.com
>> > >
>> > >
>> > > "Ivan Brugiolo [MSFT]" wrote:
>> > >
>> > >> Let me clarify some concepts first:
>> > >> The entire video stack is sessionized.
>> > >> When you talk about windowstation\desktop,
>> > >> you are always speaking about 2 dimension of a 3 dimensional space.
>> > >>
>> > >> The system works this way:
>> > >> Session X is attached to a terminal.
>> > >> A terminal is the logical collction of input/HID devices and display
>> > >> drivers.
>> > >> When you TS into a machine, you attach an existing session (or a new
>> > >> session)
>> > >> to the remote terminal, and, the `glass` or `physical` terminal
>> > >> is attached to a temporary session.
>> > >>
>> > >> In your case, when you TS to a machine, you may connect to session
>> > >> #0,
>> > >> that, in certain legacy operative system is sometimes incidentally
>> > >> shared by the services, or, you may connect to session #x, (with x
>> > >> != 0).
>> > >> In any case, the "physical terminal" would be connected to
>> > >> a session that is NOT the one you are using in mstsc.exe.
>> > >>
>> > >> That means that video hardware acceleration (and video capture /
>> > >> video
>> > >> output)
>> > >> is available only to the Winlogon.exe and csrss.exe processes
>> > >> that runs in the session attached to the physical console.
>> > >>
>> > >> To solve your problem, you need to have your applications always
>> > >> running
>> > >> in the session attached at the `glass termninal`, and, from ony
>> > >> other
>> > >> session,
>> > >> you need to communicate with those applications, and, gather data
>> > >> from
>> > >> there.
>> > >>
>> > >> Now, this is easy done in a Server SKU, where you have 2 floating
>> > >> session.
>> > >> You can always "lock" the session attached to the glass terminal in
>> > >> such
>> > >> a
>> > >> way
>> > >> that nothing interfears, and, in the second remote session you can
>> > >> "control"
>> > >> the physical term
From: Nadav on 7 Nov 2006 03:32
Well, what I actually trying to do is to enumerate my audio capture devices,
this is done using DirectShow and CoCreateInstance(CLSID_SystemDeviceEnum),
the list of audio capture devices returned when executed in a WTS had some
absent devices ( such as Osprey audio capture ).

Using sysinternals process explorer I can clearly see that my application is
created in a WST session ( \Sessions\1\Windows\WindowStations\WinSta0 ) while
for an application running on a non WST session the window station is
\Windows\WindowStations\WinSta0.
--
Nadav
http://www.sophin.com


"Ivan Brugiolo [MSFT]" wrote:

> Are you absolutely sure that your process is created in the session
> that is bound to the glass terminal ?
> If you execute a simple code that enumerates the display devices,
> do you ger RDPDD as your display driver, or something that
> reflects the fact that you have an ATI, nVidia, etc video-card ?
>
> --
> --
> 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
>
>
> "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
> news:D9CFD8FF-90AB-4C20-A02F-8EB3CE19F527(a)microsoft.com...
> > Problem resolved, when creating the process with Inherit handles set to
> > false
> > the process is created properly, HOWEVER, capture device information is
> > still
> > NOT AVAILABLE!!! this information is available ONLY when creating the
> > process
> > under a non WST session, hence, under \Windows\WindowStations & \Desktop
> > all
> > capture devices are available while under
> > Sessions\%SessionId%\Windows\WindowStations& \Desktop capture devices are
> > NOT
> > available
> >
> > Why does this happen, how can it be resolved ?
> >
> > --
> > Nadav
> > http://www.sophin.com
> >
> >
> > "Nadav" wrote:
> >
> >> Hi Ivan,
> >>
> >> - Thanks for your response, What U suggest works fine when dealing with
> >> WinXP ( that enable a single remote desktop session ), however, this
> >> doesn't
> >> apply to Win2003 where multiple simultaneous sessions are available, on
> >> Win2003 the application is getting created on a desktop/session otherthen
> >> the
> >> WST session I am connected through.
> >> - To resolve that I was extracting the WST Session in use through the
> >> launcher application in the followng way:
> >> 1. I have used ProcessIdToSessionId(GetCurrentProcessId(), &dwSessionId),
> >> It
> >> gave an ID different then the one provided by
> >> 'WTSGetActiveConsoleSessionId'
> >> 2.
> >> DuplicateTokenEx(hToken,MAXIMUM_ALLOWED,NULL,SecurityIdentification,TokenPrimary,
> >> &hTokenDup)
> >> 3. CreateEnvironmentBlock
> >> 4. CreateProcessAsUser
> >>
> >> THE RESULT:
> >> CreateProcessAsUser failes with GetLastError == 87 ( The parameter is
> >> incorrect. )
> >>
> >> Why does this happen? how can I resolve that?
> >>
> >> Keep in mind that this happen only on Win2003 and NOT on WinXP.
> >>
> >> --
> >> Nadav
> >> http://www.sophin.com
> >>
> >>
> >> "Ivan Brugiolo [MSFT]" wrote:
> >>
> >> > You don't connect *TO* a terminal.
> >> > You connect a terminal to a session.
> >> >
> >> > You need to have an application running
> >> > in the session attached to the glass terminal.
> >> > First of all, you need to get the session bound to glass.
> >> > In the following example it's session #1, while your remote session is
> >> > #2
> >> > G:\>qwinsta /server:ivanbrug-t1-b
> >> > SESSIONNAME USERNAME ID STATE TYPE
> >> > DEVICE
> >> > services 0 Disc
> >> > console USTLSUUser 1 Active
> >> > rdp-tcp#0 2 ConnQ rdpwd
> >> > rdp-tcp 65536 Listen
> >> >
> >> > Creating processes bound to a session is a matter of using
> >> > WTSQueryUserToken / CreateProcessAsUser.
> >> > Once you have a process in the session bound to the glass terminal,
> >> > you can get all of your non-remote video stack with it's properties and
> >> > capabilities.
> >> >
> >> > --
> >> > --
> >> > 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
> >> >
> >> >
> >> > "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
> >> > news:802D4C4B-BB23-4648-BADA-ECFDD4494CD4(a)microsoft.com...
> >> > > Hi Ivan,
> >> > >
> >> > > Thanks for your immediate response, there are some points I wish to
> >> > > clarify:
> >> > > How can I connect to the 'glass termninal' ? My application is
> >> > > launched
> >> > > from
> >> > > the remote desktop session, the station\desktop used are the ones
> >> > > extracted
> >> > > from that session, which, according to what you say doesn't really
> >> > > represent
> >> > > the remote session desktop, to be able to present GUI on the remote
> >> > > desktop
> >> > > session I have to use the 'glass termninal', BUT, how can I get the
> >> > > station\desktop of the 'glass termninal' ????
> >> > >
> >> > > --
> >> > > Nadav
> >> > > http://www.sophin.com
> >> > >
> >> > >
> >> > > "Ivan Brugiolo [MSFT]" wrote:
> >> > >
> >> > >> Let me clarify some concepts first:
> >> > >> The entire video stack is sessionized.
> >> > >> When you talk about windowstation\desktop,
> >> > >> you are always speaking about 2 dimension of a 3 dimensional space.
> >> > >>
> >> > >> The system works this way:
> >> > >> Session X is attached to a terminal.
> >> > >> A terminal is the logical collction of input/HID devices and display
> >> > >> drivers.
> >> > >> When you TS into a machine, you attach an existing session (or a new
> >> > >> session)
> >> > >> to the remote terminal, and, the `glass` or `physical` terminal
> >> > >> is attached to a temporary session.
> >> > >>
> >> > >> In your case, when you TS to a machine, you may connect to session
> >> > >> #0,
> >> > >> that, in certain legacy operative system is sometimes incidentally
> >> > >> shared by the services, or, you may connect to session #x, (with x
> >> > >> != 0).
> >> > >> In any case, the "physical terminal" would be connected to
> >> > >> a session that is NOT the one you are u
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Getting subnet mask with GetAdaptersAddresses
Next: CreateProcessAsUser from CredProv on Vista/Longhorn Server