win service and HKCU and SHGetFolderPath with CSIDL_APPDATA

  • Thread starter Thread starter Viviana Vc
  • Start date Start date
V

Viviana Vc

Hi all,

A Windows service (which obviously starts before any user logs in) is
failing to:
- read something from registry from a key under the HKCU
- try to find out the user path by doing the following call:
SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, path)
if any of these is tried before a user logs in.

My question is: are these 2:
- read something from registry from a key under the HKCU
- try to find out the user path by doing the following call:
SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, path)
supposed to fail also after the user logs in? (XP and 2000)

Thanks in advance,
Viv
 
Hi,

I think this is because the user profile of the service account is not
loaded.
You should use LoadUserProfile and then access HKCU. SHGetFolderPath is
using HKCU as well.

Sincerely,
Kornél
 
Thx for your answer.

Actually I have a LSP (layered service provider) dll that is loaded by
all services and I noticed that for services, in my dll trying to read
the HKCU fails, and wasn't sure if this is a general rule for all
services or the behaviour depends on how the service is written ...
Seems that it can be different depends if the service is doing a
LoadUserProfile() call before my dll is used right?

Thanks,
Viv
 
Viviana Vc said:
Thx for your answer.

Actually I have a LSP (layered service provider) dll that is loaded by
all services and I noticed that for services, in my dll trying to read
the HKCU fails, and wasn't sure if this is a general rule for all
services or the behaviour depends on how the service is written ...
Seems that it can be different depends if the service is doing a
LoadUserProfile() call before my dll is used right?
Click to expand...

Sure "environment" depends on what is done before your code is run. :)

The default account used for Services ("LocalSystem") simply doens't
have a user profile so no HKCU link is created to a new place in
HKU. (I'm not fully sure but the HKCU may be linked to HKU\.DEFAULT
by default).

So either you load an suitable profile for LocalSystem (making sure the
local account can access the file), define a normal account as the service
account or, most properly, use keys somewhere under HKLM or most
properly HKLM\SYSTEM\CurrentControlSet\Services\MyService\Parameters

- Sten
 
"Viviana Vc":
After the answer of Arnaud Debaene I have done some test using the following
environment:
Windows XP SP2, Microsoft .NET Framework 1.1 SP1, a test service written in
C#

I have tried the service with Local System, Local Service, Network Service
and a custom, non-administrative user.
In all of these cases I was able to access HKCU for read and write as well.
And I'm sure that the Framework isn't using LoadUserProfile at all.

"Sten Westerback":
Sure "environment" depends on what is done before your code is run. :)

The default account used for Services ("LocalSystem") simply doens't
have a user profile so no HKCU link is created to a new place in
HKU. (I'm not fully sure but the HKCU may be linked to HKU\.DEFAULT
by default).

So either you load an suitable profile for LocalSystem (making sure the
local account can access the file), define a normal account as the service
account or, most properly, use keys somewhere under HKLM or most
properly HKLM\SYSTEM\CurrentControlSet\Services\MyService\Parameters
Click to expand...

The Local System account has a HKCU key and it is the same as
HKEY_USERS\.DEFAULT.

For more information please read my reply to Arnaud Debaene's message.

According to Platform SDK Documentation LoadUserProfile can be called only
by administrators or system. It is intendet to be used by a service if you
are using a high privileged account (eg. Local System) and want to
impersonate to a low privileged account. In this case the profile of the
impersonated account is not loaded and you have to load it using
LoadUserProfile to access HKCU for example. But you have to load it as Local
System.

I'm sure if a service is executed it has a HKCU. You problem may be caused
because the underlaying service is doing impersonation without loading the
user profile. But I cannot tell you anything else wthout the analisis of the
wole soultion...

I advise you the same as Sten to use a registry key in HKLM, the mentioned
Parametes subkey is a common solution.

Sincerely,
Kornél
 
Back
Top