I needed to add a new entry to my PATH variable. This is a common activity for me in my job, but I've recently started using Windows 8. I assumed the process would be similar to Windows 7, Vista, XP...

Here's my sequence of events:

  1. Open System properties (Start-> [type "Control Panel"] -> Control Panel\System and Security\System -> Advanced system settings -> Environment Variables)
  2. Add the new path to beginning of my USER PATH variable (C:\dev\Java\apache-ant-1.8.4\bin;)
  3. Opened a command prompt (Start -> [type "command prompt" enter] -> [type "path" enter]

My new path entry is not available (see attached image and vide). I Duplicated the exact same process on a Windows 7 machine and it worked.

Screen grab of environment variables


Windows 8 Environment Variables and Command Prompt video


This is definitely not the behavior of Windows 7. Watch this video to see the behavior I expect working in Windows 7. http://youtu.be/95JXY5X0fII

EDIT 5/31/2013

So, after much frustration, I wrote a small C# app to test the WM_SETTINGCHANGE event. This code receives the event in both Windows 7 and Windows 8. However, in Windows 8 on my system, I do not get the correct path; but, I do in Windows 7. This could not be reproduced in other Windows 8 systems.

Here is the C# code.

using System;
using Microsoft.Win32;

public sealed class App
    static void Main()
        SystemEvents.UserPreferenceChanging += new UserPreferenceChangingEventHandler(OnUserPreferenceChanging);

        Console.WriteLine("Waiting for system events.");
        Console.WriteLine("Press <Enter> to exit.");

    static void OnUserPreferenceChanging(object sender, UserPreferenceChangingEventArgs e)
        Console.WriteLine("The user preference is changing. Category={0}", e.Category);
        Console.WriteLine("path={0}", System.Environment.GetEnvironmentVariable("PATH"));

OnUserPreferenceChanging is equivalent to WM_SETTINGCHANGE

C# program running in Windows 7 (you can see the event come through and it picks up the correct path).

C# program running in Windows 8 (you can see the event come through, but the wrong path).

There is something about my environment that is precipitating this problem. However, is this a Windows 8 bug?

EDIT 2014-04-28

Due to this and several other issues, we no longer use Windows 8 on the desktop. We do not have an environment to continue testing and experimenting with this problem. There is still no answer or resolution to this problem for us. The answers below did not resolve our problem.

  • 2
    I think you need to reboot after making the changes for them to take effect.
    – Enigma
    May 10, 2013 at 15:02
  • @Enigma Why? I didn't need to reboot in Windows 7, Vista, XP, 2000...
    – mawcsco
    May 10, 2013 at 15:08
  • 1
    @Enigma A reboot should not be necessary. serverfault.com/questions/8855/…
    – mawcsco
    May 10, 2013 at 15:41
  • 1
    I've just checked this on both Windows 7 and Windows 8: in either case the new environment variable was visible in cmd when a new instance was launched. Of course the already running cmd didn't get the updated environment. May 10, 2013 at 17:39
  • 1
    Try changing something in the system path instead of the user path.
    – jdigital
    Mar 8, 2014 at 0:53

7 Answers 7


If you are launching the Command Prompt from the start menu or a shortcut on your task bar, you must either:

  • Restart explorer. Kill it and relaunch it.
  • Log out and back in (which effectively relaunches explorer).
  • Restart the system (which also effectively relaunches explorer).

The environment doesn't update immediately because environments are inherited from their parent process, with the exception of explorer, which is started by the system upon login. This is how it behaves on my Windows 7 system.

So changing the Environment Variables updates the registry keys, but these keys are not re-read until the system has to build a new login environment for some process being launched. Most of the time, this isn't happening because processes are children of a process which already has an environment, so the environment is inherited.

  • 2
    Absolutely false for Windows 7. See the video I linked in my post above.
    – mawcsco
    May 10, 2013 at 15:34
  • 1
    Huh. You're definitely correct there, though I've definitely had my changes not apply immediately to new console windows on Win 7 before. I can't remember what my exact workflow was, though. I'll play around with my Win 8 system when I get home if nobody has an answer for you by then. May 10, 2013 at 15:49
  • 5
    If you changed environment variables using System properties dialog, the changes are applied immediately to the currently running Explorer instance, and all processes started afterwards get the new environment. Already running processes do not automatically update their environment variables unless they handle WM_SETTINGCHANGE message. May 10, 2013 at 17:44
  • 1
    Dude, this helped me understand the problem I was having anyway. I use AutoHotkey to launch a command prompt, and it wasn't working until I restarted autohotkey!
    – Moss
    Mar 14, 2014 at 22:01
  • 1
    @mawcsco It worked for me, I'm using Windows 7.
    – laike9m
    Sep 12, 2015 at 3:09

From: http://support.microsoft.com/kb/104011 via https://serverfault.com/q/8855/158027


However, note that modifications to the environment variables do not result in immediate change. For example, if you start another Command Prompt after making the changes, the environment variables will reflect the previous (not the current) values. The changes do not take effect until you log off and then log back on.

To effect these changes without having to log off, broadcast a WM_SETTINGCHANGE message to all windows in the system, so that any interested applications (such as Windows Explorer, Program Manager, Task Manager, Control Panel, and so forth) can perform an update. MORE INFORMATION

For example, on Windows NT-based systems, the following code fragment should propagate the changes to the environment variables used in the Command Prompt:

    (LPARAM) "Environment", SMTO_ABORTIFHUNG,
    5000, &dwReturnValue);

None of the applications that ship with Windows 95 and Windows 98, including Windows Explorer and Program Manager, respond to this message. Thus, while this article can technically be implemented on Windows 95 and Windows 98, there is no effect except to notify third-party applications. The only method of changing global environment variables on Windows 95 is to modify the autoexec.bat file and reboot.

  • 2
    Windows Explorer in Windows 7 handles this message, and it's enough to restart Command Prompt from Taskbar or Start menu. May 10, 2013 at 17:31
  • "Changes to environment variables should take effect immediately, if you make the change via the main Properties dialog for the computer in question (go to My Computer | Properties | Advanced | Environment Variables). After the changes are saved, Explorer broadcasts a WM_SETTINGCHANGE message to all windows to inform them of the change." serverfault.com/questions/8855/…
    – mawcsco
    May 10, 2013 at 17:39
  • 2
    "System Tip This article applies to a different version of Windows than the one you are using. Content in this article may not be relevant to you. Visit the Windows 8 Solution Center"
    – mawcsco
    May 10, 2013 at 17:41
  • It wouldn't surprise me that this is an implementation detail and that Microsoft had no intentions of supporting this behavior in Windows 8 or above.
    – surfasb
    Jan 26, 2016 at 18:59

The problem is with your user setting. In Window 8, each user has it own environment variables.

Open System properties (Start-> [type "Control Panel"] -> Control Panel\System and Security\System -> Advanced system settings -> Environment Variables)

Above approach will edit environment variables for the root user, maybe not your current user.

You should go to user-account -> select your current account -> change environment variables

After changing, restart power shell. Then

echo $env:JAVA_HOME


Get-ChildItem env

Hope this will help you.

  • I think you might have missed the detail in my screenshots and video that shows the dialog with "User variables for mwillia3". That's my username. I know for certain that I was editing the correct environment variables. The C# app fires the event, with the old value, not the updated value. I gave up. I'm fairly certain this is a Win 8 bug and I no longer have access to Windows 8 to test this.
    – mawcsco
    Oct 1, 2014 at 14:48
  • Some people don't always read the details. I see this on some systems and not on others, I've even seen it on Windows 7/2008. There is no rhyme or reason for when it happens that I've found. Jun 18, 2015 at 22:47
  • Same problem with Windows Server 2012 r2 even after propagating WM_SETTINGSCHANGED. I believe it's a windows bug.
    – vezenkov
    Mar 28, 2016 at 13:47

Try SETX instead SET. E.g SETX PATH "%PATH%;MyPath"

  • 1
    Can you explain why SETX rather than SET works.
    – ChrisF
    May 10, 2014 at 13:51
  • First, I wasn't using the command line, I was using the system dialog. Second, my pattern of behavior works fine in Windows 7, but sometimes not in Windows 8. Can you point to documentation that shows how SET and SETX changed between Windows 7 and Windows 8?
    – mawcsco
    May 12, 2014 at 13:43

If you are using Windows 8.1, open the command prompt as Administrator, then call the PATH command and you should see it appear there. When you go back to normal cmd, it will also show up. And as matter of fact, you should be able to start the added application from command prompt.


Late to his. However. You may be a victim of this issue: User variables are not resolved correctly in Windows.


Does it work if you use Win+R from the Desktop to start cmd.exe? My guess is that starting it from the Start Screen causes the started cmd.exe's parent to be different from explorer.exe (WSAHost.exe, IIRC or whatever it's named), and that parent process doesn't update it's environment during WM_SETTINGCHANGE messages. I don't have a Windows 8 machine on hand to test...

  • Even in Windows 8 the Start Screen UI seems to all be part of explorer.exe because it disappears when explorer.exe is killed.
    – binki
    Jan 28, 2016 at 22:43

You must log in to answer this question.

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