SysWow64 Redirection for cmd.exe

[Kristofer G. Skaug [SSBV]]

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]

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-to-suppress-and-bypass-system32-file-system-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

Post by Kristofer G. Skaug [SSBV]
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
"{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

[Stefan Pendl]

Post by Carlos
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."
http://www.tipandtrick.net/2008/how-to-suppress-and-bypass-system32-file-system-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

See http://msdn.microsoft.com/en-us/library/bb427430%28VS.85%29.aspx for a starting point.

Pay special attention to the redirecting described in http://msdn.microsoft.com/en-us/library/aa384249%28VS.85%29.aspx
There are the API functions listed to temporarily disable redirection, you must always revert the redirection back afterwards.

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.

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

---
Stefan Pendl

Windows Vista SP 1
AMD Turion X2 RM-70 2 GHz
4 GB RAM

[Kristofer G. Skaug [SSBV]]

Post by Stefan Pendl
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.

Post by Stefan Pendl
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]]

"Carlos" wrote...

Post by Carlos
Hi,
http://www.tipandtrick.net/2008/how-to-suppress-and-bypass-system32-file-system-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]

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

Post by Kristofer G. Skaug [SSBV]
"Carlos" wrote...

Post by Carlos
Hi,
http://www.tipandtrick.net/2008/how-to-suppress-and-bypass-system32-file-system-redirect-to-syswow64-folder-with-sysnative/
Would that help.

Yes it does, very much! It's EXACTLY what I need in this situation.
-> 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]]

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

Happy birthday!

Kristofer

[JC]

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

Post by Kristofer G. Skaug [SSBV]
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
"{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