Help: Custom Environment Variables Stop working

[kelaniz]

This is not my week.

Ok, I have a few variables I've been using on my main box and have imported to the registry during setup on my custom build DVD. The system variables below are all basically abbreviations of a few windows locations I use:

AUSM   = %AllUsersProfile%\Start Menu
  AUSMP = %AllUsersProfile%\Start Menu\Programs
  AUDT   = %AllUsersProfile%\Desktop
  CUSM   = %UserProfile%\Start Menu
  CUSMP  = %UserProfile%Start Menu\Programs
  CUDT	= %UserProfile%\Desktop
  QL		= %AppData%\Microsoft\Internet Explorer\Quick Launch
  FAVS	= %UserProfile%\Favorites

These are all system variables, with REG_EXP_SZ strings sitting happily in the correct registry location. Typing 'set' from a command line shows them as you see them here.

I originally set these variables for a post-first-login Link Management CMD (moves all misplaced .lnk and .url files where I want them.) They vars ended up being so useful for command-line work and installs, I set them as system vars, and added them to the registry import on my test box VM. I've been using them without incident for several months, and they appeared to work flawlessly...Until an hour ago.

The most annoying problem I'm having, is the %QL% variable, while defined, simply will not work anymore. Any time I try to copy/move anything, or cd there, I'm getting "the system cannot find the path specified" But if I cd to the actual path that's copied from the variable's 'set' response, it works just fine. Watch, I'll show you.

C:\>cd /d %QL%
   The system cannot find the path specified.

   C:\>cd /d "%QL%"
   The system cannot find the path specified.

   C:\>cd /d %AppData%\Microsoft\Internet Explorer\Quick Launch

   C:\Documents and Settings\xxxxxx\Application Data\Microsoft\Internet Explorer\Quick Launch>dammit
  'dammit' is not recognized as an internal or external command, operable program or batch file.

See? Thing is, this worked before! I've checked the registry for any obvious problems or extraneous characters, but there's nothing out of line. Next, I tried it on the VM, and same thing. Then, as I was trying to figure that one out on the VM, I noticed that all the above CU* variables weren't mapping to the correct location.

CUDT should go to %userprofile%\Desktop That's what the registry value has for that var. The actual path for %userprofile%\Desktop is C:\Profiles\Kelani\Desktop however, all the CU* variables I created now take me to the corresponding folder of the system profile.

CUDT=C:\WINDOWS\system32\config\systemprofile\Desktop
  CUSM=C:\WINDOWS\system32\config\systemprofile\Start Menu
  CUSMP=C:\WINDOWS\system32\config\systemprofile\Start Menu\Programs

Windows built-in variables work fine. cd /d %userprofile% takes me to the correct user profile directory.

Next, I deleted the above system variables from currentcontrolset AND all the backup keys, rebooted and added them as user variables (which completely ruins their usefulness since user vars automatically expand to the actual path. Not ideal. ). Making them user vars stopped the mapping to systemprofile, but the %QL% variable still doesn't work.

I also created a system and a user var QLtest=C:\Profiles\xxxxxx\Application Data\Microsoft\Internet Explorer\Quick Launch and neither of those work either.

So, now I'm wondering, what changed? Did Microsoft add something evil in those security updates released last night? That's *all* that's changed on those two boxes in the past two weeks. It's odd that they'd both stop working simultaneously, and in the exact same way.

So, obvious question, *can* you create a variable with a target like %UserProfile%\Desktop and use it as a system variable so %UserProfile% won't automatically expand, or do you have to create user variables for every user? I thought the former was allowed, but after today, I'm not so sure anymore

Leave it to Windows to wait until 3AM to show me another quirk I've never seen it do before.

Any ideas?

Kel

Edited May 9, 2007 by kelaniz

[Kelsenellenelvian]

You triple posted!!! Shame on you!!!

Please be more carefull not to do that in the future you know better.

[kelaniz]

Oh Dammit.

Sorry Kel #1. please don't take my addons away.

Blame the IETab Firefox extension. I entered MSFN through the front gate, and IETab gavve IE control. Then IE pulled its " I AM IE. I have made your Space key=ENTER and your Arrow keys now go Back 3 pages. YOU'LL LIKE IT!" crap.

Please delete my grievous zombie post before Kel#1 really goes nuts.

Kel#2

Edited May 9, 2007 by kelaniz

[[deXter]]

System Variables are created after windows boots and before the logon. Therefore, as no profile is loaded, all profile related variables used will default to the SYSTEM profile, which is %SYSTEMROOT%\system32\config\systemprofile.

So %USERPROFILE% will resolve to %SYSTEMROOT%\system32\config\systemprofile before logon, and after logon it'll resolve to the current user's profile.

Therefore, if you want to use a variable which contains a variable related to the current user profile, you should create it as a User variable. (Eg: The TMP User Variable)

Thus you should set the variable for every user. However, if you want it to be created automatically for a new user account, head over to HKEY_USERS\.DEFAULT\Environment

---

In this Microsoft page, it says "Variable substitution is not recursive. Cmd.exe checks variables once." Which means, %QL% will NOT expand to C:\Documents and settings\.... but will instead stay as %APPDATA%\Microsoft\... - literally. %APPDATA% will not be expanded and therefore you'll get an error.

--

I just created a QL user variable set to the direct path, and all commands work fine. I think why you're getting an error here is because you need to use double quotes - either while referencing the variable, or while setting it in the first place. Another alternative would be to set it to its short path (C:\DOCUME~1\..\APPLIC~1\MICROS~1\INTERN~1\QUICKL~1).

[Yzöwl]

In this Microsoft page, it says "Variable substitution is not recursive. Cmd.exe checks variables once." Which means, %QL% will NOT expand to C:\Documents and settings\.... but will instead stay as %APPDATA%\Microsoft\... - literally. %APPDATA% will not be expanded and therefore you'll get an error.

That is my understanding too!

This means that when you create the environment variables, you need to use a method which expands that particular systems variables during the creation:

Works

REG ADD bla bla bla /t REG_EXPAND_SZ /d "%USERPROFILE%\bla"

(shown in registry as C:\Documents and Settings\bla\bla).

Doesn't work

REG ADD bla bla bla /t REG_EXPAND_SZ /d "%%USERPROFILE%%\bla"

(shown in registry as %USERPROFILE%\bla).

[nmX.Memnoch]

Thus you should set the variable for every user. However, if you want it to be created automatically for a new user account, head over to HKEY_USERS\.DEFAULT\Environment

*sigh*

How many times does it have to be said that HKEY_USERS\.DEFAULT is NOT the Default User profile? That's where the settings are stored for the logon screen. In other words, it contains the settings for when the system is sitting at the 'Press Ctrl-Alt-Del to Logon' (or Welcome) screen.

To change the Default User profile you have to load the NTUSER.DAT located at Documents and Settings\Default User\ and make your changes. Then unload it. Now any new user that logs on will inherit those settings.

[kelaniz]

Still confused. Big surprise.

Let me clarify: the %QL% variable DID work when set in a batch file, and I'm pretty sure it worked as a system variable until yesterday. Does it being set in a batch file make any difference? My previously-mentioned post-setup batch file deletes and copies ~20 shortcuts to and from Quick Launch. Every command uses %QL%. This worked perfectly for the past 6 months I've been testing that XP build. Before I add any command I'm unsure about to that file, I test it at a command line to verify it works. If it doesn't, I don't add it until I find a way where it works.

Example from monster Kel LinkManager.cmd:

SET QL=%appdata%\Microsoft\Internet Explorer\Quick Launch
ECHO Copying Firefox Shortcut to QuickLaunch
COPY "%AUDT%\Mozilla Firefox.lnk" "%QL%\"

Next, my new twin cat-owning avatar bro deXter said:

System Variables are created after windows boots and before the logon. Therefore, as no profile is loaded, all profile related variables used will default to the SYSTEM profile, which is %SYSTEMROOT%\system32\config\systemprofile. So %USERPROFILE% will resolve to %SYSTEMROOT%\system32\config\systemprofile before logon, and after logon it'll resolve to the current user's profile.

That makes perfect sense. Say I set the following system variable via control panel or registry:

Key=HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Value=MEOW

Type=REG_EXPAND_SZ

Data=%userprofile%\desktop

If I understood you correctly, Before login, MEOW will point to some variant of %SYSTEMROOT%\system32\config\systemprofile\desktop

After login, it should become MEOW=%SYSTEMROOT%\Documents and Settings\Kelani\Desktop

Is that right?

That may be the root of the problem. I don't think this change in mapping is happening anymore, if it ever did to begin with. When I started noticing the CU* system vars pointing to systemprofile I *was* logged in. Not sure if it's relevant, but I don't use the welcome/login screen. Since both boxes are single-user, they both auto-login. I'm never logged out of the box. Now mentally, that's a whole different story.

Anyway, here's an abbreviated list of my original system variables when I noticed the problem. I've since removed the CU*, QL and FAVS vars from my registry, since they don't work anymore (and to prevent even more confusion). I left the AU* ones, because they DO work and still point to the correct path. Those are OK.

AUDT=C:\Documents and Settings\All Users.WINDOWS\Desktop (EXP_SZ %AllUsersProfile%\Desktop)
AUSM=C:\Documents and Settings\All Users.WINDOWS\Start Menu (EXP_SZ %AllUsersProfile%\Start Menu)
AUSMP=C:\Documents and Settings\All Users.WINDOWS\Start Menu\Programs (EXP_SZ %AllUsersProfile%\Start Menu\Programs)
CUDT=C:\WINDOWS\system32\config\systemprofile\Desktop (EXP_SZ %UserProfile%\Desktop)
CUSM=C:\WINDOWS\system32\config\systemprofile\Start Menu (EXP_SZ %UserProfile%\Start Menu)
CUSMP=C:\WINDOWS\system32\config\systemprofile\Start Menu\Programs (EXP_SZ %UserProfile%\Start Menu\Programs)
DEVMGR_SHOW_DETAILS=☺(Shows a Smiley now?! dword says 1. That's new.)
FAVS=C:\WINDOWS\system32\config\systemprofile\Favorites (EXP_SZ %userprofile%\Favorites)
COMPUTERNAME=CRASH (appropriate, ain't it?)
CLIENTNAME=Console
SESSIONNAME=Console
USERNAME=Kelani
HOMEDRIVE=C:
SystemDrive=C:
SystemRoot=C:\WINDOWS
ProgramFiles=C:\Program Files
HOMEPATH=\Documents and Settings\Kelani
USERPROFILE=C:\Documents and Settings\Kelani
ALLUSERSPROFILE=C:\Documents and Settings\All Users.WINDOWS
APPDATA=C:\Documents and Settings\Kelani\Application Data

Example of what I see: CUDT points to systemprofile, AUDT points to correct location.

C:\>cd /d %userprofile%\desktop   <--- Testing where %userprofile%\desktop sends me, 

C:\Documents and Settings\Kelani\Desktop>cd /d %CUDT%  <--Same command as the above, just as a variable

C:\WINDOWS\system32\config\systemprofile\Desktop>  <--Sends me to the **** System Profile

C:\>cd /d %AUDT% <--Same command as %CUDT% but replace AllUsersProfile instead of UserProfile

C:\Documents and Settings\All Users.WINDOWS\Desktop>   <--Sends me to the correct path.

From deXter's post, I could see why the AU* variables will work, but the CU* vars don't. Maybe they would work again if they weren't still pointing to the **** systemprofile after I login. I dunno. Why they doing that now is what I don't get. I'm pretty sure that's why %QL% fails, as there's no Quick Launch dir in systemprofile\Application Data\Microsoft\Internet Explorer. But if I understood deXter right, it shouldn't be looking for it there anyway. As I said, for months, they worked fine. I don't know it that was due to being set in a batch file vs the registry, but one way or another, they worked.

So any ideas on why they're pointing to system profile, or how to fix it?

I did have the CU* vars in my RunOnce registry import, but the only entity referencing those variables is me via cmd files and a command line, I don't see how they're staying mapped to the systemprofile, and making it be' the user's profile, if that's what's actually happening.

It just seems like having to set all these CU* variables as user vars negates most of the purpose of using variables in the first place. It doesn't help that the Userprofile and ProgramFiles dirs on OldBox and NewBox are different (Documents and Settings \ Profiles | Program Files \ Programs). That's actually why I created these vars to begin with: to simplify copying files & settings between the box and the new build. Using already-expanded variables would be a massive pain in the...text editor.

nmX.Memnoch: How do you go about loading the Default User NTUSER.dat, anyway? Never heard of doing that before.

Kel

[[deXter]]

Does it being set in a batch file make any difference?

Yes! When it's set in a batch file, the variable is temporary and local for that shell. %USERPROFILE% expands to the proper path which is why your file would have worked flawlessly. But when you set it as a system variable, you know what happens.

nmX.Memnoch: How do you go about loading the Default User NTUSER.dat, anyway? Never heard of doing that before.

That's the correct way to go about setting default values for new users. Sorry for my mistake earlier

Fire up regedit, select any hive (HKLM or HKU) and choose "File -> Load Hive". Load Documents and Settings\Default User\NTUSER.DAT. Give it some name like default_user, and browse under it. Now edit the "Environment" key under it, make your changes, and get back to the default_user key you just created. Click on "File -> Unload Hive". Remember, this won't affect existing users.

---

Note: The easiest way to add custom variables to all existing and new users, in your case, would be to edit AUTOEXEC.BAT! Yes, the good ol' remnant from DOS still works wonders in NT! Infact, this works just as if you've created a System variable, only, this will expand all variables to their correct path!

Just edit C:\AUTOEXEC.BAT, and add these lines:

SET CUDT=%USERPROFILE%\Desktop
SET CUSM=%USERPROFILE%\Start Menu
SET CUSMP=%USERPROFILE%\Start Menu\Programs
SET CUDT=%USERPROFILE%\Favorites

Reboot. Now go to any user account and you'll see the variables are available and working perfectly! No more messing around with the registry. B)

[nmX.Memnoch]

nmX.Memnoch: How do you go about loading the Default User NTUSER.dat, anyway? Never heard of doing that before.

That's the correct way to go about setting default values for new users. Sorry for my mistake earlier

Fire up regedit, select any hive (HKLM or HKU) and choose "File -> Load Hive". Load Documents and Settings\Default User\NTUSER.DAT. Give it some name like default_user, and browse under it. Now edit the "Environment" key under it, make your changes, and get back to the default_user key you just created. Click on "File -> Unload Hive". Remember, this won't affect existing users.

Also, if you're doing an Unattended Install any HKCU registry settings modified during setup go into the default user profile. So if you run those from CMDLINES.TXT during install all new users will get those settings. This precludes having to manually load it later to modify settings.

[kelaniz]

Oh duh. Load hive. I knew that. I'll play with the Default.dat and see what fun develops.

Interesting thing, 8 hours after my last post, I checked the VM and the sysvars worked again! Yes, the same ones that supposedly couldn't work. No idea why. Still, to be on the safe side, I took all the CU*, FAVS, QL sysvars and made them user vars.

One oddity I noticed... Before adding the user vars, I removed all vars in HKCU\Environment and rebooted. Then I added the variables via the control panel - System applet and used the same built-in variables (%appdata% - %userprofile%) like before. Interestingly, half the variables appeared in the registry as type REG_EXPAND_SZ, and preserved the unexpanded variable. The other half, using the same variable didn't.

I entered:

Name:CUSM Value:%UserProfile%\Start Menu

Name:CUSMP Value:%UserProfile%\Start Menu\Programs

And they appeared in the registry as:

CUSM REG_EXPAND_SZ %UserProfile%\Start Menu

CUSMP REG_SZ C:\Profiles\Kelani\Start Menu\Programs

It's no problem, as both work fine. So, I manually imported the REG_SZ ones as REG_EXPAND_SZ with the appropriate data. Those also work fine. So, apparently you can preserve unexpanded strings in permanent user variables. Of course, if my recent history is any indication, that might also stop working any day now If so, I'll fall back on the autoexec.bat method, which has always been my last resort.

Man, this incident was incredibly weird. That's from a guy who's been explaining Windows behavior to people for 14 years. If I wasn't absolutely sure both boxes were virii/malware free, I'd swear they were infected with something.

Thanks again to Yzow, Memnoch and (once again) deXter for this week's help. I'll probably return next week with yet another obscure question like... "What causes Windows Picture resizer powertoy to fail with "Unable to resize Foo.jpg", or something.

Thanks guys,

Kel