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.

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, 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?

share|improve this question
    
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 Apr 19 '12 at 19:06
    
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 Apr 20 '12 at 10:08
add comment

1 Answer

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"=""
share|improve this answer
add comment

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.