I see all of the above issues and raise you a few. Console 2 simply cannot see certain files in Win7. I haven't yet worked out which ones or why just yet but for instance when using cmd.exe or powershell.exe as the interpreter I can't see telnet in the c:\windows\system32 folder. It's there if I use CMD.exe regular, but invisible in console2.
Also I can't seem to load any of my powershell plugins in console2 (Exchange 2007, Quest AD add-ins etc).
I've tried all of the obvious (run as admin, compat modes, file permissions, etc). UAC is disabled. Any ideas?
I cannot see telnet in WIn7 x64, when using Console, CMD ot Explorer. It only finds my PuTTY.exe when I use the Start Menu search box.
I'm pretty worried if you say that Console cannot see certain files, but I cannot see any reason why this could even happen. Could you provide more details please. What is the telnet file's full name and location?
Is this on 32-bit or 64-bit Win7? There are funny things going on with 32-bit vs 64-bit programs which might affect this (Console2 is a 32-bit app).
Can you give a precise set of steps to reproduce the issue? If so, I can give it a try on 32-bit Win7.
One thing you *could* try is recompiling as a 64-bit application, if you have the ability to do that.
I'm running 64-bit Win7, C2 using CMD as the shell.
I found telnet.exe under the Windows Side-By-Side directory:
Can see it in both C2 and CMD.
But I did see weirdness with the file termsrv.dll. It shows up under plain CMD (elevated or not elevated, both Admin), but not under C2 (also elevated and Admin).
I found it under
My guess is that CMD somehow knows to combine files under the winsxs with the system32 list. But I'm not up on the side-by-side stuff and how that might be happening.
Doing some searching, it might be related to folder virtualization.
I've been playing with Console in a Window 7 64bit machine and I also see directory discrepancies. If I do a dir of \Windows\system32 with cmd.exe I get 2454 files/54 directories. With Console, I get 2046 files/46 directories.
Going down the entire Windows hierarchy, the total difference is about 2,001 missing files with Console. I've briefly checked some non-OS trees and don't see a similar discrepancy.
Hope that helps a little bit anyway.
might be related to this http://www.ghisler.ch/board/viewtopic.php?t=22382
Ah, yes, jmwap - that would seem to be the culprit. This MSDN page mentioned is good:
talking about 64-bit programming and the Windows file redirector for 64-bit systems.
File System Redirector
The %windir%\System32 directory is reserved for 64-bit applications. Most DLL file names were not changed when porting to 64-bit, so 32-bit applications must use a different directory as their System32 directory. WOW64 hides this difference using a file system redirector.
Whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to a new directory, %windir%\SysWOW64. Access to %windir%\lastgood\system32 is redirected to %windir%\lastgood\SysWOW64. Access to %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe.
To retrieve the name of the 32-bit system directory, 64-bit applications should use the GetSystemWow64Directory function.
32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.
Windows Server 2003 and Windows XP: The Sysnative alias was added starting with Windows Vista.
So "System32" is for *64-bit* apps, and 32-bit apps have to live in "SysWOW64" - odd. But I'm sure it was done for backwards compatibility and least amount of code change.
And "SysNative" is an alias/virtual directory. Interesting - I can CD to that directory in CMD and the 32- bit version of Console2, but not the 64-bit version of Console2.
It also mentions specific new functions for 64-bit apps to use to handle some of this weirdness, so it'll probably take some code changes to get the 64-bit Console2 version working.
For now, I'll just need to find a good program for searching for files - one that I can trust will actually find files…