Take the 2-minute tour ×

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


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.

Anyone know a way around this?

share|improve this question
any update on what happened? –  Knox Jun 17 '09 at 22:38
Not yet, although it seems that the 32-bit process does start, but this then launches the 64-bit version and the 32-bit shuts down (all in a fraction of a second) –  John Sibly Jun 18 '09 at 8:03

7 Answers 7

up vote 3 down vote accepted

I've found a simple way to get by this.


Solution: Rename the 64-bit mstsc.exe from System32 to prevent it from replacing the 32-bit process.

This is simple if you have rights to rename that file. If you’re on NTFS you may get a “You require permission from TrustedInstaller to make changes to this file” error.

To get by this error, you can take Ownership of the file and give yourself full permissions:

  1. Browse to %SystemRoot%\System32
  2. Right click mstsc.exe and choose Properties
  3. Go to the Security tab
  4. Click Advanced
  5. Go to the Owner tab
  6. Click Edit
  7. From the “Change owner to:” list, choose your user name
  8. Click OK
  9. Go to the Permissions tab
  10. Click Change Permissions…
  11. Click Add
  12. Enter your user name and click OK
  13. Tick the box in the Allow column for Full control
  14. Click OK
  15. Click OK
  16. A Windows Security warning will come up; click Yes to proceed
  17. Click OK

Now, you can rename the file mstsc.exe to something like mstsc.exe.bak

Then, you can launch mstsc.exe from %SystemRoot%\SysWOW64 and you will have 32-bit Remote Desktop Connection running.

share|improve this answer
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 Sibly Dec 3 '09 at 17:06

Use the below script as a .bat file, to force the start of mstsc.exe x32.

@echo off
set WinDir=
start C:\Windows\SysWow64\mstsc.exe 
share|improve this answer

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

share|improve this answer
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 Sibly Sep 11 '09 at 14:42

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.

share|improve this answer
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 Sibly Jul 31 '09 at 8:35

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.

share|improve this answer

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.

share|improve this answer
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 Sibly Jun 15 '09 at 16:03

Have you tried copying the 32-bit executable from an existing 32-bit installation and running that?

share|improve this answer
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 Sibly Jun 15 '09 at 16:09

Your Answer


