I'd imagine if C:\Windows\System32 were missing from the path statement, ipconfig not running would be the least of your worries.
C:\Windows\System32 contains a large number of the executables and dynamic link libraries (DLLs) that allow Windows to function.
An entry in the system Path settings tells the computer to look in that specified location for executables and files that programs are referencing.
While it would seem that a good program would not rely on Path variables but should directly reference the location of any and every file it is dependent on, the Path statement allows multiple similar OSes to coexist on the same drive (Windows XP in the C:\WinXP\ folder, Windows 7 in C:\Win7\, etc, which would result in different and incompatible .\System32\ directories), and allows for more easy and flexible upgrading of framework files (look for the newest version of the .Net libraries in a versioned directory where they are installed rather than a central directory where they may overwrite each other in an undersireable way).
So a program looking to use the functions of Windows XP's built in zip handling would call zipfldr.dll and the OS will return the functions of that executable stored in C:\Windows\System32\zipfldr.dll. If you look through that directory, you should see many files that you'll probably recognize as common scripting commands or functions critical to the OSes operation.
I've never removed the C:\Windows\System32 entry from my path statement and I don't think I ever will (though I suppose testing this in a VM with rollback functionality shouldn't be too hard) and so I cannot say for certain what would happen if it were completely missing.
Suffice it to say, pretty much any batch script would completely not function, and the abilities of your OS would be severely curtailed.
Others have already noted how to add C:\Windows\System32 to the Path statement if it is missing, and so I'll not repeat that here. But I would not be surprised, since this is the only function you've found to be not working, if there were something else wrong here.
It's possible that you have an 'AutoRun' command set in the registry. There's two registry keys, one per-user and one per-computer, that can define commands that are run every time the command processor (cmd.exe
) is started. They're actually listed in cmd /?
.
Anyway, try running cmd /d
and see if that produces the same message. The /d
flag means "don't run AutoRun commands", which makes it perfect for testing this.
The registry values are:
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
Check both. By default, neither should exist. You may wish to fix the command strings in yours, or even delete them entirely.
Related: http://blogs.msdn.com/b/oldnewthing/archive/2007/11/21/6447771.aspx
Alternatively, you could have a batch script or similar set up with the name cmd
, which is being executed instead of the native cmd
. Try the command where cmd
to print out a list of cmd
s in your path, in order of execution. If there are any other than/before the one in C:\Windows\System32\cmd.exe
, you may wish to delete them, or remove their path from your PATH environment variable.
Best Answer
You say that when you type
set path
in a command prompt the path also containsPATH=%systemroot%\system32
. If this is the case your%systemroot%
does not get expanded toC:\Windows
(or other real Windows-directory) when startingcmd.exe
.You can check your registry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
. All the names containing values with%
characters (e.g.windir
,temp
,path
andcomspec
) should be of typeREG_EXPAND_SZ
(and notREG_SZ
) or the variable won't be expanded.You should also check
HKEY_CURRENT_USER\Environment
ifpath
is of typeREG_EXPAND_SZ
.