Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

EDIT

Windows 8 Environment Variables and Command Prompt video

EDIT

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.");
        Console.ReadLine();
    }

    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.

share|improve this question
2  
I think you need to reboot after making the changes for them to take effect. –  Enigma May 10 '13 at 15:02
    
@Enigma Why? I didn't need to reboot in Windows 7, Vista, XP, 2000... –  mawcsco May 10 '13 at 15:08
    
@mawcsco You did in 7 at least. Opening command prompts from the start menu launches with the environment from the Explorer shell, which was loaded when you logged in. You need to either kill/restart explorer, log out or back in, or restart the system. –  Darth Android May 10 '13 at 15:17
1  
@Enigma A reboot should not be necessary. serverfault.com/questions/8855/… –  mawcsco May 10 '13 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. –  Alexey Ivanov May 10 '13 at 17:39

4 Answers 4

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.

share|improve this answer
2  
Absolutely false for Windows 7. See the video I linked in my post above. –  mawcsco May 10 '13 at 15:34
    
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. –  Darth Android May 10 '13 at 15:49
3  
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. –  Alexey Ivanov May 10 '13 at 17:44
    
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 at 22:01

From: http://support.microsoft.com/kb/104011 via http://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:

SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0,
    (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.

share|improve this answer
1  
Windows Explorer in Windows 7 handles this message, and it's enough to restart Command Prompt from Taskbar or Start menu. –  Alexey Ivanov May 10 '13 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 '13 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 '13 at 17:41

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

share|improve this answer
1  
Can you explain why SETX rather than SET works. –  ChrisF May 10 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 at 13:43

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...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.