Are environment variables affected after impersonating and loading a user profile in a service?

Question

I have a Windows service running under a LocalSystem account and I am trying to access some user-specific environment variables. When I call ExpandEnvironmentStrings("%AppData%"), I get "C:\windows\system32\config\systemprofile\AppData\Roaming".

I figured impersonation and loading the user profile should solve this, so I called:

• LogonUser()
• LoadUserProfile()
• CreateEnvironmentBlock()
• ImpersonateLoggedOnUser()

And still, ExpandEnvironmentStrings("%AppData%") returns the the system folder instead of something like "C:\Users\Username\AppData\Roaming".

So then I searched around some more and came across SHGetFolderPath(CSIDL_LOCAL_APPDATA), which worked like a charm post-impersonation.

My question is not what I should do (ie. SHGetFolderPath), but more about how environment variables work in services. I'm thinking my issue is either:

1. My LoadUserProfile() code is still missing something, even though everything returns success. My ignorant side wants to convince me that in theory, loading a user profile should make ExpandEnvironmentStrings() return the loaded user's values.

2. Based on some readings, it seems environment variables in services are read only once (http://support.microsoft.com/kb/887693) at system startup, so my service is ONLY aware of system environment variables.

I'm leaning towards 2. but I just need someone to confirm this, so I don't assume something that's potentially wrong.

Answer 1

The docs for Environment variables indicate that #2 is correct. Quoting, emphasis added:

Every process has an environment block that contains a set of environment variables and their values.

MSDN points to ExpandEnvironmentStringForUser() to approach your original problem.