Jailed 32-Bit Processes on Windows x64 (Update)
|
by Nicholas Dille on 03/13/2008 | 8 Comments | 13,806 Views
|
The Windows-On-Windows (WoW) subsystem has been included in Windows operating systems to allow for backwards compatibility. It has enabled the execution of 16-bit applications on modern 32-bit based Windows. This abstraction layer is located in user space translating API calls to 64-bit data structures and entry points. This is called API call thunking. Windows x64 Editions include a new variant of the WoW, called WoW64, subsystem thunking API calls for 32-bit applications on the 64-bit kernel.
WoW64 includes several mechanisms to separate file system and registry information for 32-bit applications from 64-bit applications in order to run unchanged on Windows x64. One of the tasks of WoW64 is file system redirection which makes 32-bit tools and libraries available in the expected location: On Windows x64, the 32-bit version of %SystemRoot%\System32 (as found on 32-bit Windows) is relocated to %SystemRoot%\SysWoW64. For 32-bit applications to work properly, WoW64 redirects every access to the new location.
As a very nasty consequence of this design, 32-bit applications are not able to call 64-bit tools located in the original %SystemRoot%\System32 because of the redirection. Fortunately, Microsoft has included most tools in both versions (32- and 64-bit). However, some useful tools are only available in 64-bit versions including shutdown.exe, logoff.exe, msg.exe, tsdiscon.exe and tsshutdn.exe.
In effect, WoW64 limits the flexibility of system management from a 32-bit context because only 64-bit processes have an unaltered view of the system. To my knowledge, there are two solutions to this pitfall which I will indulge on.
A third solution has come to my knowledge: Windows Server 2008 incorporates a modified WoW64 layer making the original %SystemRoot%\System32 directory available as %SystemRoot%\Sysnative. By installing Microsoft hotfix 942589, Windows Server 2003 receives the same changes in WoW64. I regard this approach to be superior to the two solutions below. Those of you unable to install this hotfix may still be interested in the solutions presented in this article.
Hard Links
A very interesting solution is described here. By creating a hard link in the file system, every access is redirected to the destination of the link which is resolved by the file system abstraction layer. The Resource Kit contains a tool to create hard links called linkd.exe included since the release for Windows 2000.
The following command line demonstrates the creation of such a hard link to make the original folder %SystemRoot%\System32 available under %SystemRoot%\System64 while the second line removes the link:
linkd.exe %SystemRoot%\System64 %SystemRoot%\System32
linkd.exe %SystemRoot%\System64 /d
As this tool is a 32-bit application, the creation of such a hard link can also be implemented running under WoW64.
Disable FS Redirection
WoW64 allows for the File System Redirection to be disabled for every thread individually. Thus, I have written a tool, Start64, which uses the appropriate API call to provide direct access to the original %SystemRoot%\System32 and launch 64-bit tools. After launching a process supplied on the command line, Start64 waits for the child to terminate and reverts the file system redirection to its previous state.
Using Start64, a 32-bit application is able to launch the 64-bit version of cmd.exe which executes a custom script with full access to the file system and the registry. Bear in mind that this script needs to be aware of the peculiarities of Windows x64. Obviously, this is just one use case for Start64.
Example 1. The following command executes msg.exe to message the console session: Start64.exe "%SystemRoot%\System32\msg.exe" "0 hello admin"
Example 2: If caught in a 32-bit command prompt, Start64 breaks free and launches a new instance of the 64-bit cmd.exe: Start64.exe "%SystemRoot%\System32\cmd.exe" "/c start %SystemRoot%\System32\cmd.exe"
The second example uses an advanced construct to ensure that Start64 returns immediately because it does not have to wait for the interactive 64-bit command prompt to terminate.
You can download Start64 here. A help message is displayed when calling the tool without any parameters.
References
Freik's Weblog: First Post - All Things x64
Microsoft: File System Redirector, Registry Redirector, Registry Reflection, API Call Thunking
Articles on Windows x64 in Helges Blog
- ‹ previous
- 14 of 106
- next ›
+++ Your opportunity +++ Use Profile Migrator 2, the new sepago product that makes migrating user personalities between different platforms a breeze.! Download your free version now!
Tags
8 responses for "Jailed 32-Bit Processes on Windows x64 (Update)" |
Add Comment
Recent Articles
About the author
![]() |
Nicholas Dille Head of Technology and Innovation Blogs about Centralized computing, virtualization and performance monitoring |
Most viewed
| 18,531 Views |
Who Needs Aero Glass Remoting? Although It's Cool! |
| 15,792 Views |
Emulating a Redirecting Load Balancer for WI and PNA |
| 14,303 Views |
Building Custom EdgeSight Reports Part 4 - The Wedding |







I found out that you can also
I found out that you can also use %SystemRoot%\sysnative
this folder is only available to x32 programs and redirects to the real system32 folder.
Using the folder
Using the folder %SystemRoot%\SysNative is only available in Windows Server 2008 x64. I have not been able to confirm this folder to be working under Windows Server 2003 x64.
Regards,
Nicholas.
I need to correct my earlier
I need to correct my earlier comment about the folder %SystemRoot%\Sysnative. It was pointed out to me that Microsoft provides a hotfix adding this folder to the Wow64 layer of Windows Server 2003 x64. The hotfix is available here: http://support.microsoft.com/?scid=kb;en-us;942589.
BTW, I was suspecting that someone intended to comment on this article shortly after I had disabled comments ;-)
Regards,
Nicholas.
[...] a detailed description
[...] a detailed description and the download, please refer to my post here. Print This Post « [...]
[...] a script initiated from
[...] a script initiated from a 32 bit process without some tweaking. There is some info on that here http://blogs.sepago.de/nicholas/2008...n-windows-x64/ Just wanted to share this in acse anyone runs into the same situation. Thanks. [...]
Hey pals! What about to
Hey pals! What about to launch 64-bit application from 32-bit console? Scenario:
1) i am running 32-bit console under 64-bit windows
2) i\'ve created hard link to real (64-bit) system32 directory as it was mentioned above using linkd tool. For example my link is abc = %SystemRoot%\\system32.
3) i am trying to launch the next command:
abc\\shutdown /?
After that command i have the next message: \"the system cannot execute the specified program\". But if i launch shutdown /? from the 64-bit console i have full help of the command.
So the question (and the goal) is: it\'s good that i could access 64-bit system32 folder from 32-bit command line, but could i launch any application there?
In my opinion the above error message says that i cant run 64-bit applications from 32-bit command line, because i am in 32-bit compatibility mode.
Any opinions and experience appreciated.
How can I redirect console
How can I redirect console output from started application to Start64 output?
Maybe new switch for start64? =)
DeathBloom, Kibab, I
DeathBloom, Kibab,
I recommend you check whether the %SystemRoot%\Sysnative is available on your systems as this provides the easiest way of accessing 32-bit executables from a 64-bit command prompt. Note that Sysnative is not a folder but an internal redirection of the Wow64 layer. Please see my ealier comments as well.
@Kibab: Using the Sysnative redirection you can directly access 64-bit executables from a 32-bit process without using Start64. This also works around the issue of redirecting the console output of Start64.
@DeathBloom: I have been able to confirm that the commands using linkd.exe work as documented above. As the Sysnative redirection is the official way of launching 64-bit executables from a 32-bit process I recommend using this method.
Best regards,
Nicholas