Edit:I am running windows 7, 64 bits.

I have Telnet Client installed, and if I go to c:\windows\system32 i do find the file "telnet.exe"; if I click it, telnet runs perfectly.

However, if I type telnet in cmd prompt, it gives me the "command not recognized" message.

I think it's because c:\windows\system32\cmd.exe is actually running files from windows\sysWOW64 (which also has a cmd.exe), and so I tried copying telnet.exe to this folder; When I type telnet in the cmd line (regardless of which cmd.exe i use) I no longer get an error message, and instead get... well, nothing. It just sits there, like when awaiting input, but if I type something (e.g., "quit") it once again does nothing and awaits input.

Finally, I tried, in windows\sysWOW64, deleting telnet.exe, creating a telnet.lnk shortcut to telnet.exe in system32, and creating a telnet.bat file in windows\sysWOW64, that runs telnet.lnk. Now, if I double click telnet.bat, telnet start perfectly (in a system32\cmd.exe window); if I type telnet in cmd prompt (again, doesn't matter which) it runs telnet.bat whith no problems at all (checked this testing other commands), but returns "Acess denied" when opening Telnet.lnk.


-- telnet is installed and runs when double clicking

-- shortcuts to it work perfectly if double clicked

-- neither telnet nor shortcuts (nor files calling shortcuts) can be run from either cmd prompt.

And that is how far i've gone. So, yeah... Any ideas?

  • 3
    Does your PATH directory contain the System32 folder? If it does, is the path really really long with other stuff too? I personally have had problems where a too long path can cause problems. Jun 8, 2013 at 17:48
  • Variable "Path" contains %SystemRoot%\System32, along with a few other directories, separated by ';'. (Example: %SystemRoot%;%SystemRoot%\System32;C:\Program Files (x86)\Common Files\Ulead Systems\MPEG;etc.) Hope this helps.
    – Sampaio
    Jun 8, 2013 at 19:03
  • which directory occurs in your path first? system32 or syswow64? the first element in PATH that contains an exe with the name you specify should be the instance executed. Jun 8, 2013 at 19:41
  • From those two, the first would be system32, since syswow64 is not there at all. The absolute first is some "Windows Live" directory, with system32 being the second directory listed
    – Sampaio
    Jun 8, 2013 at 19:56
  • 1
    What does where telnet.exe say? I just enabled the Telnet Client under Windows Features. Telnet.exe, a 64-bit program, was duly added to Windows\System32. No 32-bit version was to be found in Windows\SysWOW64. Typing telnet at the cmd prompt worked perfectly as expected. Don't know what the problem is at your end.
    – Karan
    Jun 8, 2013 at 22:59

4 Answers 4


It appears that on Win7 64 bit, telnet.exe is a 64 bit command. You can run it from 64 bit shell (or cmd prompt), but a 32 bit shell will attempt to load it from SysWOW64, and it won't be found there.

I suspect that you are running a 32 bit command prompt (for example, from SysWOW64). If you run 64 bit command prompt, telnet should work.

You can test this by going to Start Menu > Run, type cmd and then run telnet from this command prompt.

How are you starting your command prompt? If it's a link, take a look at the properties. If it's from another program, and that program is 32 bits, then that could be the issue.

  • I have checked it is runnig the command prompt from system32. I have started it whith Run, typing cmd, I have actually started it from the system32 folder, by double-clicking. Like I said in the question, I have tried typing "telnet" in both command prompts: from the system32 and the syswow64 directories. Regardless of which one I choose, it looks for the files in syswow64, for some reason.
    – Sampaio
    Jun 9, 2013 at 18:33
  • 1
    The behavior you're describing is what you'd see if running a 32 bit command prompt. Run cmd.exe, then go to the Task Manager and click on the Processes tab. Sort by Image Name (click on the Image Name column) and look at all cmd.exe processes. Do any of them have *32 next to them?
    – jdigital
    Jun 9, 2013 at 22:13
  • Good idea. I checked, and there is indeed *32 next to the process. However, in the actual command propt window, the path is system32\cmd.exe. Uhm... Edit: Some times the process does not have the *32, in which cases telnet works just fine. So, the question, I believe, is why sometimes 32bits cmd.exe is called, and why 32bits cmd.exe appears as having the path system32\cmd.exe, on the console window
    – Sampaio
    Jun 9, 2013 at 23:50
  • In a 32 bit process, system32 is remapped to SysWOW64, so you can't rely on the path system32\cmd.exe without knowing the type of the process that invoked it. Regarding why 32 bit cmd.exe is being called, this is a result of how it is invoked. Can you provide more details?
    – jdigital
    Jun 10, 2013 at 0:22
  • 2
    from a 32-bit cmd you can run %SystemRoot%\Sysnative\telnet to get the 64-bit telnet
    – phuclv
    May 31, 2018 at 10:45

Realise this post is (very!) late but just had the same issues. Resolved it by also copying C:\windows\system32\en-us\telnet.exe.mui to the corresponding folder in syswow64. Hope this helps someone else out in future.

  • Hey, thanks for the answer. If that works, better late than never! I no longer have the PC I was using, and frankly I don't even remember what I was doing (or trying to do) at the time. Maybe that file was what was missing when I tried copying. I'll give you +1 so that others may find this easily.
    – Sampaio
    Jun 9, 2017 at 2:06

I did a very simple thing and everything did work for me, just copy Telnet.exe from system32 and paste it in SysWOW64 and run the cmd.exe that excites in SysWOW64 Directory and everything did work perfectly.. hope it will work for you....


SYMPTOM On Windows Vista and Windows 7, launching a debug configuration with platform as Cortex-A8 RTSM or FVP may give the following error: Windows cannot find 'c:\windows\system32\telnet.exe CAUSE DS-5 Debugger uses telnet capabilities of your computer for a debug session over serial connection to the RTSM and FVP. This error occurs when you try to connect to the RTSM and FVP from the debugger and the telnet client is disabled. The telnet client is not enabled by default on Windows Vista and Windows 7.

RESOLUTION Enable telnet client on your computer and restart the debug session. To enable telnet client on Windows Vista and Windows 7:

Open Control Panel from the Windows Start menu.

Select Programs.

Under Programs and Features, click Turn Windows features on or off.

From the list that appears, select the Telnet Client checkbox to enable telnet.

Click OK to close the dialog.

  • Please read the question again carefully. Your answer does not answer the original question. OP already has telnet installed.
    – DavidPostill
    Aug 8, 2015 at 11:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .