Normally it is quite easy to run the 32 bit version of a windows application from the command line, e.g. run window:

C:\Windows\SysWOW64\Notepad.exe

You can tell that the process is 32-bit by checking in task monitor\processes as it will have a *32 next to the filename.

However, the remote desktop client (mstsc.exe) does not want to play ball. It always runs the 64-bit version from C:\Windows\System32\mstsc.exe regardless of how I start it (run window, 32-bit cmd windows etc). I've even tried writing a 32-bit C++ program to create it (normally child processes are also 32-bit) but this did not work.

We need to run the 32-bit version because we have some custom dlls that are integrated with remote desktop and it is not possible to load a 32-bit dll in a 64-bit process.

Thanks for your answer. In the end we wrote a lightweight 64-bit plug in, which then loads a 32-bit wrapper class out of process (it's a COM object), and this wrapper class loads our original code. However, your suggestion would be useful as a workaround for earlier versions of our product.
–
John SiblyDec 3 '09 at 17:06

This is confusing about the 64bit versions of windows, but things located in SysWOW64 directory are the 32bit executables that run in 'WOW' (Windows on Windows). Things located in the System32 directory are 64bit binaries and don't have 32bit equivalents. The naming here is for compatibility reasons and is lame, but I'm sure some software works because of it that would otherwise not work.

You could try copying the mstsc.exe from a 32bit installation onto your 64bit machine and running it, but as far as I know 64bit windows only has a 64bit exe for mstsc and as such can not be forced to run in 32bit mode.

We copied the exe file from C:\Windows\SysWOW64 to another machine, and used the visual studio command line tool: dumpbin /headers mstsc.exe and according to the header information in the exe it is 32-bit x86, we just can't seem to run it!
–
John SiblyJun 15 '09 at 16:03

I have found that the only way to force the mstsc to run at 32 bit is to run the depends (from sysinternals) and than open mstsc.exe from syswow64. After run it using the start profiling leaving the option as default. This will result in a mstsc*32 bit running. At now i haven't found any other way to to the same.
Hoe this help
Flavio

Wow-I've tested this and it does work (although it's not really an acceptable workaround for our users!) I wonder if depends is able to start mstsc in some special way, or if the API hooking it uses somehow breaks how it launches the 64-bit version? I notice in the depends profile it is calling the API to work out if it is a WOW64 process.
–
John SiblySep 11 '09 at 14:42

I just tried and copied the 32-bit version from a Windows XP machine into C:\test3 and ran it from there, but the process is still using the 64-bit exe from C:\Windows\System32 (I'm also checking in process explorer)
–
John SiblyJun 15 '09 at 16:09

Have you tried compatibility mode, trying an older operating system? I think the system looks at the manifest for the executable and if it was developed for Vista, then it won't show that tab. But I think you could edit the manifest.

My answer is:Is there a 32-bit version of mstsc.exe? i assume mstsc that ships with 64-bit Windows is the 64-bit version of mstsc.

The real answer is: If you want to write a dll extension for a 64-bit application you must recompile your dll's as 64-bit. Microsoft is not, nor should be be, obligated to ship a 32-bit version of every operating system component.

Another example: If you want to write a shell extension for 64-bit Windows Explorer it must be a 64-bit dll. There is no 32-bit version of Windows Explorer. You either support 64-bit Windows, or you do not.

There is a 32-bit version in the C:\Windows\SysWOW64 directory. When you execute it you can see that it is a 32-bit process momentarily in task monitor (*32 next to the process name). What seems to happen is that it then spawns the 64 bit version from C:\Windows\System32 and the 32-bit version ends. I guess I was really after an explanation for why it behaves this way. I think you are correct in that the only option is to write a 64-bit plug in. Unfortunately we have to load third party 32-bit dlls so the only option there may be to host them in another 32-bit process.
–
John SiblyJul 31 '09 at 8:35