I've run into an issue that was originally exposed by Microsoft.CSharp.CSharpCodeGenerator throwing an UnauthorizedAccessException: Access to c:\Users\[wrong-user]\AppData\Local\Temp receiving an "access denied" error attempting to write into a different IIS AppPool user's temp directory.
I have another application which actually runs as the [wrong-user] AppPool, and that application does work. However, this makes sense, since it has write access to it's own user directory.
I've narrowed the error down to the fact that %USERPROFILE% is returning the path of a different IIS APPPOOL user, even though Environment.GetFolderPath(SpecialFolder.UserProfile) returns the correct path.
If I enumerate Environment.GetEnvironmentVariables(User), I get:
Additionally, manually accessing the user's environment variables via HKEY_USERS/[SID]/Environment confirms that it is simply down to %USERPROFILE% being incorrect:
The issue ended up being that setProfileEnvironment, which isolates the environment variables for each application pool's worker processes, was set to false on system.applicationHost/applicationPools/applicationPoolDefaults despite it having a default value of true according to the documentation. Since none of the application pools were overriding it, they all received the same value and thus shared common environment variables.
I have no idea how it got set to false, nor how the shared USERPROFILE environment variable got set to one application pool but never another, but setting the default value back to true resolved the issue.
It was this question/answer which helped me find the cause, despite the problem being different.