SysWow64 Redirection for cmd.exe

Discussion in 'Windows 64bit' started by Kristofer G. Skaug [SSBV], May 31, 2009.

  1. Hi all,

    I'm calling the 'qwinsta.exe' utility via the commandline from a 32-bit
    application as part of a function to detect Remote Desktop connections.
    On my Vista Ultimate x64 system, due to the infamous 32-bit folder
    redirection, invoking 'cmd.exe /s qwinsta /server' actually launches
    c:\Windows\SysWOW64\cmd.exe - which in its turn is unable to find
    'qwinsta.exe', as this is installed in c:\Windows\System32.

    Now, I thought I'd be 'smart' and copied qwinsta.exe from
    c:\Windows\System32 to c:\Windows\SysWOW64, as a result I get something that
    "almost" works: It now generates output to the console, even though I'm
    running the 32-bit cmd.exe, but qwinsta complains as follows:

    "{Message(): LoadString Failed, Error 15105, (0x0003B01)}"
    .... followed by a semi normal listing of the active sessions.... which I
    could use.

    By also copying the manifest qwinsta.exe.mui from the \en-US subfolder of
    \System32 to the same subfolder of \SysWOW64\, I was able to eliminate also
    this last error.

    But... uneasiness remains: Is this the way? If I want to safeguard the
    functionality of my 32-bit applications under x64 Windows systems, do I need
    to keep copying these system files? Also the \en-US location would seem to
    be a system specific/locale-dependent thing... very error prone...

    1) Do you have any suggestions for a better approach?
    Including: How to detect a Remote Desktop session without resorting to
    the qwinsta.exe commandline?

    2) What is the appropriate API to detect that you're running on a 64-bit
    flavor of Windows?

    Thanks in advance,

    Kristofer
     
    Kristofer G. Skaug [SSBV], May 31, 2009
    #1
    1. Advertising

  2. Kristofer G. Skaug [SSBV]

    Carlos Guest

    Hi,
    I have found this text
    "32-bit applications can access the native system directory by substituting
    %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a
    special alias used to indicate that the file system should not redirect the
    access. The Sysnative is just a virtual directory, alias or pseudo-directory
    that is not visible in Windows Explorer, directory listing, and does not
    support native 64-bit processes that already been accessing the
    %windir%\System32 folder. As such, Sysnative can only be used in file system
    calls, and not in application’s user interface such as dialog box to open or
    select folder."

    here:
    http://www.tipandtrick.net/2008/how...m-redirect-to-syswow64-folder-with-sysnative/

    Would that help.
    I know there's an API call which I can't remember. It is one used by the
    programmer of 32-bit ZTreeWin that has full access to both syswow64 and
    system32 from the 32-bit shell.
    Carlos


    "Kristofer G. Skaug [SSBV]" wrote:

    > Hi all,
    >
    > I'm calling the 'qwinsta.exe' utility via the commandline from a 32-bit
    > application as part of a function to detect Remote Desktop connections.
    > On my Vista Ultimate x64 system, due to the infamous 32-bit folder
    > redirection, invoking 'cmd.exe /s qwinsta /server' actually launches
    > c:\Windows\SysWOW64\cmd.exe - which in its turn is unable to find
    > 'qwinsta.exe', as this is installed in c:\Windows\System32.
    >
    > Now, I thought I'd be 'smart' and copied qwinsta.exe from
    > c:\Windows\System32 to c:\Windows\SysWOW64, as a result I get something that
    > "almost" works: It now generates output to the console, even though I'm
    > running the 32-bit cmd.exe, but qwinsta complains as follows:
    >
    > "{Message(): LoadString Failed, Error 15105, (0x0003B01)}"
    > .... followed by a semi normal listing of the active sessions.... which I
    > could use.
    >
    > By also copying the manifest qwinsta.exe.mui from the \en-US subfolder of
    > \System32 to the same subfolder of \SysWOW64\, I was able to eliminate also
    > this last error.
    >
    > But... uneasiness remains: Is this the way? If I want to safeguard the
    > functionality of my 32-bit applications under x64 Windows systems, do I need
    > to keep copying these system files? Also the \en-US location would seem to
    > be a system specific/locale-dependent thing... very error prone...
    >
    > 1) Do you have any suggestions for a better approach?
    > Including: How to detect a Remote Desktop session without resorting to
    > the qwinsta.exe commandline?
    >
    > 2) What is the appropriate API to detect that you're running on a 64-bit
    > flavor of Windows?
    >
    > Thanks in advance,
    >
    > Kristofer
    >
    >
    >
    >
    >
    >
    >
    >
     
    Carlos, May 31, 2009
    #2
    1. Advertising

  3. Stefan Pendl wrote
    > The following should be save to use:
    > 1) disable redirection
    > 2) call the utility
    > 3) revert redirection back
    > Redirection should be enabled for the other parts of your program.


    Hi - thanks for the tip, I did try this, unfortunately it didn't seem to
    work. It may be that I made the calls incorrectly, but I think it's actually
    because of the special circumstance that I'm spawning a cmd.exe process
    which in turn calls qwinsta.exe. So File system Redirection may be disabled
    for the calling thread in my program, but for the 32-bit cmd.exe I'm
    spawning, it is still in full effect. That's my current theory, anyway.

    > For the future, never copy files from one system folder into the other,
    > SysWOW64 is not meant to contain 64-bit executables.


    Understood - absolutely (exactly the reason for my misgivings in the
    original post).
    But actually I'm not sure whether the qwinsta.exe _is_ a 64-bit executable.
    It has been installed as part of the Terminal Services support. and by
    default everything seems to go to the \System32 directory.
    How can I tell (from the file properties) whether it's a 64-bit executable
    or not? The manifest dump from qwinsta.exe reports the following:

    <assemblyIdentity
    version="5.1.0.0"
    processorArchitecture="amd64"
    name="Microsoft.Windows.TerminalServices.QWinsta"
    type="win32"
    />

    Is "processorArchitecture" the core clue here? or should I look at
    "type=Win32"?

    TIA, Kristofer
     
    Kristofer G. Skaug [SSBV], May 31, 2009
    #3
  4. "Carlos" wrote...
    > Hi,

    <snip> here:
    > http://www.tipandtrick.net/2008/how...m-redirect-to-syswow64-folder-with-sysnative/
    >
    > Would that help.


    Yes it does, very much! It's EXACTLY what I need in this situation.
    It works, invoking CreateProcess() as follows:

    -> lpApplicationName = nil
    -> lpCommandLine = 'cmd.exe /c c:\Windows\Sysnative\qwinsta.exe /server'
    -> lpCurrentDir = 'c:\Windows\Sysnative\' (was necessary too)

    Whereas in fact, the Wow64DisableWow64FsRedirection API does _not_ work for
    this specific case (due to reasons mentioned in my reply to Stefan Pendl
    below).

    thanks a lot!

    Kristofer
     
    Kristofer G. Skaug [SSBV], May 31, 2009
    #4
  5. Kristofer G. Skaug [SSBV]

    Carlos Guest

    Kristofer,
    You are welcome.
    :)
    A gift to you in the day of my birthday.
    Carlos

    "Kristofer G. Skaug [SSBV]" wrote:

    > "Carlos" wrote...
    > > Hi,

    > <snip> here:
    > > http://www.tipandtrick.net/2008/how...m-redirect-to-syswow64-folder-with-sysnative/
    > >
    > > Would that help.

    >
    > Yes it does, very much! It's EXACTLY what I need in this situation.
    > It works, invoking CreateProcess() as follows:
    >
    > -> lpApplicationName = nil
    > -> lpCommandLine = 'cmd.exe /c c:\Windows\Sysnative\qwinsta.exe /server'
    > -> lpCurrentDir = 'c:\Windows\Sysnative\' (was necessary too)
    >
    > Whereas in fact, the Wow64DisableWow64FsRedirection API does _not_ work for
    > this specific case (due to reasons mentioned in my reply to Stefan Pendl
    > below).
    >
    > thanks a lot!
    >
    > Kristofer
    >
    >
     
    Carlos, May 31, 2009
    #5
  6. "Carlos" wrote
    > Kristofer,
    > You are welcome.
    > :)
    > A gift to you in the day of my birthday.
    > Carlos


    Happy birthday!

    Kristofer
     
    Kristofer G. Skaug [SSBV], May 31, 2009
    #6
  7. Kristofer G. Skaug [SSBV]

    JC Guest

    1) Do you have any suggestions for a better approach?
    Including: How to detect a Remote Desktop session without resorting to
    the qwinsta.exe commandline?
    What about WTSEnumerateSessions


    2) What is the appropriate API to detect that you're running on a 64-bit
    flavor of Windows?
    IsWow64Process




    "Kristofer G. Skaug [SSBV]" <> wrote in message
    news:...
    > Hi all,
    >
    > I'm calling the 'qwinsta.exe' utility via the commandline from a 32-bit
    > application as part of a function to detect Remote Desktop connections.
    > On my Vista Ultimate x64 system, due to the infamous 32-bit folder
    > redirection, invoking 'cmd.exe /s qwinsta /server' actually launches
    > c:\Windows\SysWOW64\cmd.exe - which in its turn is unable to find
    > 'qwinsta.exe', as this is installed in c:\Windows\System32.
    >
    > Now, I thought I'd be 'smart' and copied qwinsta.exe from
    > c:\Windows\System32 to c:\Windows\SysWOW64, as a result I get something
    > that "almost" works: It now generates output to the console, even though
    > I'm running the 32-bit cmd.exe, but qwinsta complains as follows:
    >
    > "{Message(): LoadString Failed, Error 15105, (0x0003B01)}"
    > ... followed by a semi normal listing of the active sessions.... which I
    > could use.
    >
    > By also copying the manifest qwinsta.exe.mui from the \en-US subfolder of
    > \System32 to the same subfolder of \SysWOW64\, I was able to eliminate
    > also this last error.
    >
    > But... uneasiness remains: Is this the way? If I want to safeguard the
    > functionality of my 32-bit applications under x64 Windows systems, do I
    > need to keep copying these system files? Also the \en-US location would
    > seem to be a system specific/locale-dependent thing... very error prone...
    >
    > 1) Do you have any suggestions for a better approach?
    > Including: How to detect a Remote Desktop session without resorting to
    > the qwinsta.exe commandline?
    >
    > 2) What is the appropriate API to detect that you're running on a 64-bit
    > flavor of Windows?
    >
    > Thanks in advance,
    >
    > Kristofer
    >
    >
    >
    >
    >
    >
    >
     
    JC, Jun 17, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?Y2FmZWJpcmQ=?=

    connecting to 64 bit cmd.exe or regedit.exe from remote scripts

    =?Utf-8?B?Y2FmZWJpcmQ=?=, May 21, 2005, in forum: Windows 64bit
    Replies:
    2
    Views:
    8,145
    PRIYANSMURARKA
    Nov 2, 2010
  2. Ted

    SysWow64 File List

    Ted, Nov 30, 2005, in forum: Windows 64bit
    Replies:
    10
    Views:
    5,266
  3. =?Utf-8?B?UmF6b3JE?=

    IIS Accessing system32 forced to SysWow64

    =?Utf-8?B?UmF6b3JE?=, Mar 10, 2007, in forum: Windows 64bit
    Replies:
    1
    Views:
    462
    =?Utf-8?B?UmF6b3JE?=
    Mar 10, 2007
  4. =?Utf-8?B?U2V6aW4gRXJlbiAocy5lcmVuQHRldGFzLmNvbS50

    To give LISTof Wirelss Networks,which Win32 cmd in cmd prompt is u

    =?Utf-8?B?U2V6aW4gRXJlbiAocy5lcmVuQHRldGFzLmNvbS50, Jul 5, 2007, in forum: Wireless Networking
    Replies:
    1
    Views:
    1,369
    Jack \(MVP-Networking\).
    Jul 5, 2007
  5. Giuen
    Replies:
    0
    Views:
    1,154
    Giuen
    Sep 12, 2008
Loading...

Share This Page