none
Problem in Path settings - Windows7 RRS feed

  • 質問

  • In Windows7 the Path command does not work unless the actual location is shown: 

    For computer1 "Mary" with Windows7 (32-bit) the 'Run...' option can use either 'cmd.exe' or 'command.com' for a prompt. Entering the command 'attrib' gave "attrib is not recognised..." etc. The existing path included "Path=%SystemRoot%\system32; ..." etc which is where attrib.exe was located. A new path 'path=C:\Windows\system32\' was then entered and confirmed and then 'attrib' worked corrrectly.

    For computer2 "Zlazz" with Windows7 (64-bit) 'attrib' worked properly straight off. Its path was "PATH=C:\Windows\system32; ..." etc

    Obviously the difference in "Path=..." format is causing the problem so any batch files using DOS-type commands that won't operate should start with PATH=C:\Windows\system32\. Checking the System Properties/ Advanced/ Environment Variables on the 32-bit computer found that the two user profiles there each showed Path as "C:\Windows\System32\; C;\Windows;..." so the string "Path=%SystemRoot%\system32;..." evidently comes from somewhere else.  

    What needs to be done so that the path parameter receives the actual location address instead of this "%SystemRoot%" setting?

    2010年1月12日 11:47

回答

  • I suspect something, such as a software install, has changed the Path setting in the Registry for either the user or the system.

    The default Path is in fact %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\Wbem.  But it needs to be Registry Type REG_EXPAND_SZ.

    Non-standard software installs sometimes use the wrong method to change the Path, resulting in this problem.

    Sometimes they wrongly put themselves first on the Path.  I just checked mine and found "C:\Program Files\Common Files\Microsoft Shared\Windows Live" first, which was actually "%CommonProgramFiles%\Microsoft Shared\Windows Live", set as first in both curent user (HKEY_CURRENT_USER\Environment) and system (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment).

    Go figure, non-conformance from a Microsoft product.  Or, to put it another way, do as I say, not as I do.
    • 回答としてマーク Zlazz 2010年1月16日 10:10
    • 回答としてマーク Zlazz 2010年1月16日 10:10
    2010年1月13日 3:23
  • Solution:
    Following the advice from Brian Borg I went to the two references in the Registry for Windows7 (64-bit) where the Path was shown and both had variables in their address as follows: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0; There were other references however they were shown as actual addresses (eg 'C:\Program Files\...' etc).

    The Registry Type was REG_SZ but Internet information was too confusing on how to change this to Brian's advised REG_EXPAND_SZ (which allows for these %...% variables) so I replaced each '%SystemRoot%' on the Path settings with 'C:\Windows' and rebooted. Using cmd.exe in the 'Run...' option got to a prompt. Previously entering cmd.exe again would get "cmd.exe is not recognised as an internal or external command, operable program or batch file". Following the Registry change however the various command options in C:\Windows\system32 now run from the prompt as required and the full amended path is also present.

    Sorting this out now allows batch files containing commands located in the C:\Windows\system32 folder to run properly so thanks for the valuable information.

    • 回答としてマーク Zlazz 2010年1月16日 10:13
    2010年1月16日 10:12

すべての返信

  • Hi Zlazz,
    Thanks for using Microsoft Answers!

    I'm moving your thread to the Windows 7 Misc forums in the TechNet community. They'll be able to better assist you there.

    Cody C
    Microsoft Answers Support Engineer
    Visit our Microsoft Answers Feedback Forum and let us know what you think.
    2010年1月13日 2:34
  • I suspect something, such as a software install, has changed the Path setting in the Registry for either the user or the system.

    The default Path is in fact %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\Wbem.  But it needs to be Registry Type REG_EXPAND_SZ.

    Non-standard software installs sometimes use the wrong method to change the Path, resulting in this problem.

    Sometimes they wrongly put themselves first on the Path.  I just checked mine and found "C:\Program Files\Common Files\Microsoft Shared\Windows Live" first, which was actually "%CommonProgramFiles%\Microsoft Shared\Windows Live", set as first in both curent user (HKEY_CURRENT_USER\Environment) and system (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment).

    Go figure, non-conformance from a Microsoft product.  Or, to put it another way, do as I say, not as I do.
    • 回答としてマーク Zlazz 2010年1月16日 10:10
    • 回答としてマーク Zlazz 2010年1月16日 10:10
    2010年1月13日 3:23
  • Solution:
    Following the advice from Brian Borg I went to the two references in the Registry for Windows7 (64-bit) where the Path was shown and both had variables in their address as follows: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0; There were other references however they were shown as actual addresses (eg 'C:\Program Files\...' etc).

    The Registry Type was REG_SZ but Internet information was too confusing on how to change this to Brian's advised REG_EXPAND_SZ (which allows for these %...% variables) so I replaced each '%SystemRoot%' on the Path settings with 'C:\Windows' and rebooted. Using cmd.exe in the 'Run...' option got to a prompt. Previously entering cmd.exe again would get "cmd.exe is not recognised as an internal or external command, operable program or batch file". Following the Registry change however the various command options in C:\Windows\system32 now run from the prompt as required and the full amended path is also present.

    Sorting this out now allows batch files containing commands located in the C:\Windows\system32 folder to run properly so thanks for the valuable information.

    • 回答としてマーク Zlazz 2010年1月16日 10:13
    2010年1月16日 10:12
  • Zlazz, changing the registry type to REG_EXPAND_SZ is easy with RegEdit. This is what I did:

    First, make a copy of the content of the registry key. Second, delete the registry key. Third, recreate the registry key as a REG_EXPAND_SZ key. Fourth, copy the former content back into the registry key.

    Thanks to Brian Borg for explaining this incredibly annoying problem, and shame on the developer that took a shortcut rather than read up on how to do things properly.


    Bent Tranberg

    • 回答の候補に設定 Brian Borg 2012年12月4日 23:54
    2012年12月4日 11:16