TEMP environment variable occasionally set incorrectly

Occasionally, I find my TEMP and TMP environment variables set to C:\Windows\TEMP. They should be set to %USERPROFILE%\AppData\Local\Temp, and are configured correctly in System Properties.

This manifests itself as error messages like the following:

---> System.InvalidOperationException: Unable to generate a temporary class
     (result=1).
error CS2001: Source file 'C:\Windows\TEMP\gb_pz65v.0.cs' could not be found
error CS2008: No inputs specified

...which occurs in various .NET applications (in particular Visual Studio 2010 or SQL Server Management Studio). Alternatively, SQL Server Management Studio will report:

Value cannot be null.
Parameter name: viewInfo (Microsoft.SqlServer.Management.SqlStudio.Explorer)

If I run PowerShell elevated, then $env:TEMP is set correctly. If I run PowerShell non-elevated, then it's not. I believe that it should be set correctly in both cases. If not, it's the wrong way round.

The same is true for CMD.EXE.

Rebooting fixes it, temporarily, until something breaks it again. Presumably something loaded into Explorer.exe is messing with its environment variables, but what?

The values in the registry are correct, even while this is happening:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment has TEMP = %SYSTEMROOT%\Temp
HKCU\Environment has TEMP = %USERPROFILE%\AppData\Local\Temp

By setting a breakpoint on shell32!RegenerateUserEnvironment with WinDbg, I'm able to trap it when it happens, but I still don't know why explorer.exe is reading the wrong environment variables.

I can reproduce it consistently by broadcasting a WM_SETTINGCHANGE message (I wrote a one-line C++ program to do this). Watching the activity in Process Monitor shows that explorer.exe doesn't even look at HKCU\Environment.

What is going on?

Roger Lipscombe

Posted 2012-04-19T14:45:29.730

Reputation: 1 933

what did you use to set a breakpoint on shell32!RegenerateUserEnvironment? whatever it is, it sounds like it might be an even more powerful tool than sysinternals process monitor. – barlop – 2016-02-05T08:58:36.433

@barlop, I used WinDbg. – Roger Lipscombe – 2016-02-05T10:30:15.307

You're right, that IS backwards - running code as "SYSTEM" or elevated without impersonation, should cause the C:\windows\temp thing. If you look at the Environment variables in 'advanced' computer properties, you should be able to see the SYSTEM variables using c:\windows\temp and the USER variables using %appdata%\local\temp, etc. I wish I knew what to tell you, maybe create a new user on the machine that is NOT an admin (and thus can't elevate) and play around with that. – Mark Allen – 2012-04-19T19:06:42.107

If explorer.exe is having its environment variables messed with, that'd explain it. Elevation bounces via a different process (WinInit, I think), so it will get different environment variables. I think. This would explain why the non-elevated processes are broken and the elevated ones are OK. Maybe. – Roger Lipscombe – 2012-04-20T10:08:10.540

Answers

I encountered this exact same problem a few weeks ago and it's been driving me batty. I think what's causing it is an excessively long path variable. I found several other reports of "disappearing" environment variables around the web and some suggestion that it was related to a long path.

I had a look at mine, and it turned out that some buggy installers had duplicated all the entries (some more than once). There must be a buffer overrun bug buried in explorer.exe somewhere. Anyway, when I removed the duplicates and hit OK, my TEMP variable suddenly re-appeared (with the correct value) in all apps I launched from explorer.

Peter Ruderman

Posted 2012-04-19T14:45:29.730

Reputation: 111

I don't know if this was the problem (that machine is long-since toast), but it's certainly worth a +1. – Roger Lipscombe – 2017-02-11T16:47:10.203

Your user profile may be corrupted. Try renaming your profile in C:\Users on Windows 7 and C:\Documents and Settings on Windows XP, then restarting and logging in with the same credentials so that a new profile is generated. If that works you can cherry-pick your files from your old profile and copy them to your new profile.

Weird you said that sending a WM_SETTINGCHANGE message didn't work; see this Windows Support page for a C#/VB example that should work. Also, see if merely opening and clicking OK in the Environment Variables dialog box by right clicking the My Computer icon on your desktop, selecting Properties from the options menu, then the Advanced tab and clicking the Environment Variables button. This loads the HKCU\Environment variables for me and several other posters.

Check if your HKCU\Volatile Environment variables are being generated when you log on. These should include HOMEPATH, HOMEDRIVE, USERNAME etc. Is that key completely missing?

If nothing works, a workaround for me has been to use SETX in a batch file placed in the All Users Programs Startup folder in Start Menu. For Windows XP, download SETX as part of Windows XP Service Pack 2 Support Tools.

SET HOME=
SET HOME=%USERPROFILE%
SETX HOME "%HOME%"

This will trigger your HKCU\Environment variables to be read at start-up. Then merge the keys below with your registry. They will be static for all users until you fix your profile, although one could concoct a more sophisticated batch file if they were so inclined. Replace username, logon-server and domain. This example is for Windows XP. Save it as a .reg file, right click and select merge. You can also add these using SETX. You could also use REG ADD or REGEDIT followed by WM_SETTINGCHANGE since these commands don't update your current environment. See SS64 for command usage of SETX, REG and REGEDIT.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Volatile Environment]
"APPDATA"="C:\\Documents and Settings\\<username>\\Application Data"
"HOMEPATH"="\\Documents and Settings\\<username>"
"HOMEDRIVE"="C:"
"LOGONSERVER"="\\\\<logon-server>"
"USERDOMAIN"="<domain>"
"USERNAME"="<username>"
"USERPROFILE"="C:\\Documents and Settings\\<username>"
"USERDNSDOMAIN"="<domain.com>"
"LOCALAPPDATA"="C:\\Documents and Settings\\<username>\\Local Settings\\Application Data"

[HKEY_CURRENT_USER\Volatile Environment\2]
"CLIENTNAME"="Console"
"SESSIONNAME"=""

Mark Mikofski

Posted 2012-04-19T14:45:29.730

Reputation: 558