I have a Windows 7 machine which, when Command Prompt is run by a normal user, fails to expand environment variables in the %PATH%. If command prompt is instead run as administrator (right click, Run as administrator) then %PATH% is appropriately expanded.

Specifically, %PATH% for cmd.exe run as the user (displayed via set path) is as follows:

Path=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\Wbem;%SYSTEMROOT\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft Windows Performance Toolkit\

...whereas %PATH% for cmd.exe run as Administrator is as follows:

Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\Wbem;%SYSTEMROOT\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft Windows Performance Toolkit\

I tried logging in as a new user to create a new profile, and the issue persists on that profile as well. HKEY_CURRENT_USER\Environment\PATH does not exist, and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path matches the defined system-wide path in Computer Properties -> Environment Variables.

Does anyone have any ideas of what this might be, or where I can look?

4 Answers 4


Two things I might try.

  1. Run an sfc /scannow to see if that fixes any larger issues at play.
  2. Check the registry for the Path key in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. What's the type. It should say REG_EXPAND_SZ
  • That was it. If I take a normal machine and set it to REG_SZ the problem occurs, if I set it back to REG_EXPAND_SZ it gets fixed. Commented Aug 15, 2011 at 18:27
  • @Steve - Sweet! I even learned something about that :)
    – Nixphoe
    Commented Aug 15, 2011 at 18:31
  • 1
    But I wonder. Why it creates those env vars with the wrong value type in the registry? I don't remember having this problem before, I'm using Windows 8.1 Update 1 and it seems this issue might have happen even in XP! support.microsoft.com/kb/329308 Commented Aug 20, 2014 at 15:59

I had a very similar problem - the simple solution was to add a semi-colon after the alias in the path definition.

Long story:

I'm using node.js so have a NODE_HOME alias defined via a user environment variable. I then append this alias to my PATH environment variable.

What I find is that after a re-boot, the shell has lost the path to NODE_HOME so npm etc. won't work. What's going on?

On inspection, I see that NODE_HOME is set, but that it has magically acquired a semi-colon.

C:\Users\ob>echo %NODE_HOME%

PATH now ends in the literal string %NODE_HOME% instead of the expanded path to the node folder:

C:\Users\ob>echo %PATH%

To fix it:

First, delete the errant semi-colon from the end of the definition of NODE_HOME.

Second, add a semi-colon after the NODE_HOME symbol in the definition of PATH:


Now when I start a new shell and expand PATH, it finds NODE_HOME:

C:\Users\ob>echo %PATH%

And npm works again!


I ran into the same issue while trying to configure Maven...

I found this post on Superuser that shed some light on the issue, but it didn't work for me. The issue seemed to be about rights elevation, since an admin shell would work, but a user shell wouldn't. I finally decided to just recreate the user variables as system variables instead, and add those to the global path.

This worked for a couple of variables, but I had one pair that still wouldn't expand. I recreated them with new names a couple of times, to no avail. However, the variables finally expanded correctly in the user shell after I disabled UAC, rebooted, re-enabled UAC, and rebooted again.


PROBLEM: My issue was only sinilar, as I understand you correctly. My "Path" contained ...;%ANT_HOME%\bin;... I had teh variable ANT_HOME correctly set under System (not user) Variables, and CMD --> SET same as "echo %ANT_HOME%" printed it correctly.

SOLUTION: I solved the problem by moving the folder from c:\dev\3rd\ant... to c:**Programm Files (x86)**\dev\3rd\ant...

You must log in to answer this question.

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