I installed the Windows telnet client (telnet.exe) on Windows 8 Enterprise Edition (RTM - fresh install) via Turn Windows features on or off. However I can't seem to launch it from an Administrator command prompt.

I did a full search of the C: drive and can see the executable residing in C:\Windows\System32:

telnet search result

I can also see the executable in explorer:

telnet in explorer

In both of the above cases I can launch the client by double clicking but for some reason it's not visible in my Administrator cmd.exe command prompt (or PowerShell for that matter):

run telnet in cmd result

Also, as you can see in the above screenshot, C:\Windows\system32 is present and correct in my PATH environment variable. Other system executables launch just fine (tasklist.exe for example).

For reasons that are too long winded to explain I can't use a third party telnet client such as PuTTY.

Can anyone shed any light on why this is happening?

I also tried a reboot but that's not helped either.

  • 1
    Can't reproduce on Windows 8 Pro. Everything works. Aug 18 '12 at 23:04

This is because of the file system redirector. A 32-bit process won't see the real Windows\System32 folder but get the content of the substituted Windows\SysWOW64 instead

To get it work on 32-bit cmd.exe or any 32-bit shells you can run

cd %windir%\Sysnative\

to change the working directory to that real System32 folder and then run telnet normally. Or just run %windir%\Sysnative\telnet directly to open 64-bit telnet.exe

Another way is to force open 64-bit cmd.exe from a 32-bit process (like ViStart) by modifying the invoking command or shortcut to %windir%\Sysnative\cmd.exe

Alternatively just copy (or create a hardlink) the telnet.exe file from System32 to SysWOW64

You can also add %windir%\Sysnative to the %PATH% environment variable after %windir%\System32 so that after checking that the file doesn't exist in System32 it'll continue looking in Sysnative


This is most likely a side effect of PendingRenames, Windows Explorer is so new that it makes sure it shows you the latest state taking pending renames int account whereas Command Prompt is so old that it natively reads the drive and thus does not see the renamed files yet. Usually they are first installed to a temporary unpacked location and then later renamed to be at the actual location.

My guess is that you have done Turn Windows features on or off. without rebooting your computer, thus it still has to finish off the installation of the features by doing the actual renames such that you can actually use telnet from the command prompt.

Thus, the simple "have you tried to turn it on and off again?" approach should solve this.

  • No joy after a reboot. Also I've never needed to reboot Windows (desktop and server) after adding features (or roles in Windows server) unless Windows has specifically requested this.
    – Kev
    Aug 18 '12 at 22:30
  • @Kev: Oh, this is really odd, perhaps a Windows 8 bug? Have you tried copying both files you have found to another location. Like putting them in C:\Telnet\Sys32\ and in C:\Telnet\SxS\, then see if you can run them from those directories? You could then attempt to copy or move them back (remove and then replace them, perhaps). Could be that it's a stuck PendingRename as well... Aug 18 '12 at 22:44

I finally got to the bottom of this. I had installed ViStart after becoming increasingly frustrated with the new Windows 8 Modern UI and which is particularly tricky to use over a Remote Desktop Connection.

I was using ViStart to do my usual muscle memory Start->Run->cmd.exe as I would on Windows 7. However, it turns out that ViStart is a 32-bit application and launches a 32-bit command prompt. Of course, this command prompt being 32-bit can't see telnet.exe because it's a 64-bit exe etc.

I have since given up on ViStart as a bad idea and have resigned myself to learn to navigate Modern UI instead.

  • 1
    I start telnet in Windows 8 the same way I did in Windows 7: Hit the windows key, type telnet, hit enter.
    – Mr Alpha
    Aug 21 '12 at 23:26
  • @MrAlpha - indeed, try doing that over an RDP session (even with the Apply Windows key combinations set to On the remote computer.
    – Kev
    Aug 21 '12 at 23:33
  • This is because filesystem redirector. To overcome this situation, on 32-bit cmd.exe, just use %windir%\Sysnative\telnet to open it or create a shortcut to open 64-bit cmd.exe here %windir%\Sysnative\cmd.exe. The sysnative will be pointed to the real system32 folder.
    – phuclv
    Oct 2 '13 at 8:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.