Environment variables are not refreshed

[kanenas]

Hello.
This is with 1.3.4.686 x64 autostarting with Win 7. It used to happen on earlier versions but it had skipped my mind.

When Everything starts up, it caches the environment variables.
If I open a Command Prompt through it, the variables are there. So far so good.

If I now change some variable (rename, add or delete) and open up a new Command Prompt through Everything, it still shows the old variables.
Opening instead a Command Prompt through Windows, everything is up-to-date as it should.

I'm talking about User environment variables that are supposed to refresh dynamically. Not System ones that are loaded once during boot.

Any existing or planned fix for it?

Thanks.

[void]

Thanks for the bug report.

Currently the environment variables are copied when Everything is started.

I will consider support for up to date environment variables.

[rkohanyi]

I'm seconding that using up-to-date environment variables when starting apps would be a good idea.

Just for reference, I'm using Everything 1.4.1.1002 (x86) and I'm experiencing the same behavior as described by OP.

[NotNull]

That is because that is the way that this works. For comparison:

- Start CMD.exe
- define variable: set ABC=1
- Change the user variables in Explorer (shell) : ABC=0

The setting in CMD.exe will not be impacted.

Same goes for Everything.
A child process is independent once started.

[void]

Thanks for your post, I still have this on my TODO list.

I would like Everything to have the same behavior as Windows Explorer, that is, a new processes will start with up-to-date environment strings.

I'll look into reading the environment directly from the registry and maintaining this list from WM_SETTINGCHANGE.

[NotNull]

AFAIK that will only work for system environment variables.
User environment variables, where @kanenas is talking about, are not updated.

EDIT: Just tesed this and it *does* work in Win10 somehow:
(define user variable zz=c:\tools; enter %zz% in Explorer's address bar and you go to c:\tools)
Have to figure out how this works ..

[void]

Looks like users environment variables are stored in HKEY_CURRENT_USER\Environment and system environment variables in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment

It would be useful in Everything to search for %zz% and have live results.
Searching for %path% in Everything might also be useful, I'll look into treating the ; in a list of absolute paths as an OR operator.

For example:
PATH=c:\folder1;c:\another folder2

Searching for %path% in Everything could then be treated as:
"c:\folder1"|"c:\another folder2"

[NotNull]

Looks like users environment variables are stored in HKEY_CURRENT_USER\Environment and system environment variables in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment

Yes, those are the locations where this is stored. However, in procmon I don't see Explorer accessing these keys (but it's getting late here, so I might miss things; will check again tomorrow)


I don't know how Everything gets the environment loaded right now, but I guess the environment variables will be inherited from the parent - which will be most likely Explorer (the shell) - upon first start of Everything (the GUI/database manager; not the service).
Does Everything currently keep this "snapshot" until exited?


Note:
If you decide to support %PATH%, be aware that paths can also be specified per program, also independent of the user/system environment.
Not a problem if you start Everything normal through explorer.exe, but might give unexpected results if started from - for example - a 3rd party file manager, an alternative shell or even Notepad.exe.
(personally I don't see much added value in supporting %PATH%, btw)

[void]

The calling process specifies the environment.
When Everything is launched, the environment is inherited from the calling process or is given an up-to-date environment block.

Does Everything currently keep this "snapshot" until exited?

Currently, yes.

[NotNull]

OK, so Everything behaves as a normal application in this regard.

I did some diggingand found that I forgot to mention another regkey that contain environment variables (and I use this key very often [1], so that was a little embarrassing .. )

Code: Select all

HKCU\Volatile Environment

Anyway, this is what I found so far:
Environment:
- Win10
- There are 2 Explorer's: one is shell and one is the file manager. I run both as a separate process (since forever) as that made narrowing things down a lot easier.
- adding a USER environment variable using command rundll32.exe sysdm.cpl,EditEnvironmentVariables:

• Explorer (file manager) does update the env variables on change. Following this process:
  • Read regkeys under HKLM\System\CurrentControlSet\Control\Session Manager\Environment
  • Read regkeys under HKLM\System\CurrentControlSet\Control\Session Manager\Environment
  • Read regkeys under HKCU\Environment
  • Read regkeys under HKCU\Environment
  • Read regkeys under HKCU\Volatile Environment
  I was a bit puzzled by this reading the keys twice, until I realized that this has probably to do with nested variables (like PATH=%windir%;...)
  Those have to be expanded (those variables are recognizable as being of the REG_EXPAND_SZ type instead of the usual REG_SZ type)
  The keys under HKCU\Volatile Environment don't need expanding and are (therefor?) only read once.
  
  BTW: Explorer (shell) follows these exact same steps.
• I can see a function regenerateuserenvironment (Shell32) being called beforehand. Possibly this function is responsible for rereading the environment regkeys.
• Adding the keys directly under HKCU\Environment using REG.exe triggered the 'update' mechanism too.
• Same goes for regedit.exe

[1] When looking under HK_USERS to find out which profile belongs to which user, check for the USERNAME key under "\Volatile Environment".

[void]

Thank you for the useful information.

I am trialling shell32.dll:RegenerateUserEnvironment.

It is a little bit of a hack though as it is a undocumented API call.

Building the environment block is fairly involved and is mostly undocumented.
Windows builds the environment block from so many registry values and some variables are set while others are appended (eg: %PATH%).

As you have found, there is two registry passes to expand nested variables.

Other things I played with:

• Call Userenv.dll:CreateEnvironmentBlock and update changed values via SetEnvironmentVariable.
• Launch exe files with CreateProcess with a fresh environment block from Userenv.dll:CreateEnvironmentBlock
• Only updating system and user variables from HKLM\System\CurrentControlSet\Control\Session Manager\Environment and HKCU\Environment (the ones you can modify from Control Panel -> System -> Advanced system settings -> Environment Variables... )

[NotNull]

(the ones you can modify from Control Panel -> System -> Advanced system settings -> Environment Variables... )

And for those that are not an admin:
Control Panel -> User Accounts -> Change my environment variables

[void]

Control Panel -> User Accounts -> Change my environment variables

Was just looking for this, thanks!

shell32.dll:RegenerateUserEnvironment works on XP x64, Windows 7 X64 and Windows 10 1909

[NotNull]

shell32.dll:RegenerateUserEnvironment works on XP x64, Windows 7 X64 and Windows 10 1909

Oh, wow. REspect!
(How do you even get an undocumented function working a all ?!? )


I was just checking the regkeys. There must be another place where those keys are defined as for example %ProgramData% is not in aforementioned regkeys.
Will dig a little deeper (even if the shell32.dll:RegenerateUserEnvironment works )

[void]

RegenerateUserEnvironment is exported by name which makes it easy to get the address of the function.

I only need to figure out the function's prototype, which is fairly well known.

[NotNull]

I saw 2 addresses (if those are the same thing)

Code: Select all

"Frame","Module","Location","Address","Path"
"7","SHELL32.dll","RegenerateUserEnvironment + 0x9f9","0x7ff9ec3b8339","C:\WINDOWS\System32\SHELL32.dll"
"8","SHELL32.dll","RegenerateUserEnvironment + 0x2ae","0x7ff9ec3b7bee","C:\WINDOWS\System32\SHELL32.dll"

[bracco23]

Hey, has there been any progress on this? is this fixed in any version?

[void]

It will be fixed in Everything 1.5.

If you would like to try this now, please check out the Everything 1.5 alpha

Please make sure regenerate_user_environment is enabled (it's enabled by default):

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  regen
• Select regenerate_user_environment.
• Set the value to: true
• Click OK.