Discussion :

[WebPac]

Bonjour, voici le code qui me permet de lire certaines informations dans la base de registre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
var
  aRegistre : TRegistry;
  i : Integer;
begin
  aRegistre := TRegistry.Create;
  aRegistre.RootKey := HKEY_CURRENT_USER;
  aRegistre.OpenKey( GetKeyConnexion, True );
  try
    if aRegistre.ValueExists( GetValue ) then
      Result := aRegistre.ReadString( GetCleCheminMySystemList )
    else
      Result := '';
  finally
    aRegistre.CloseKey;
    aRegistre.Free;
  end;
end;

Rien de bien sorcier et en général ça marche très bien.
Sauf que quand j'utilise ce même code avec un nouveau projet qui est de type Service Windows, il ne va pas lire les données dans HKEY_CURRENT_USER mais dans HKEY_USERS/.DEFAULT et les données ne sont pas les mêmes.
Je fais les tests alors que je suis bien logué avec un compte windows.
J'avais déjà remarqué ces problèmes auparavant sans faire trop de recherche dessus, mais maintenant, ça me pose de vrai soucis.

Savez-vous d'où ça vient et si on peut faire qqch ?
Merci.

[Jipété]

type Service Windows

n'est pas un user normal avec les droits limités, les dossiers perso et tout ça.
Il me semble que CURRENT_USER n'est valide qu'une fois un user loggué, non ?, alors qu'un service tourne depuis le démarrage de l'OS : il n'y a aucune raison pour qu'il aille trifouiller dans ce (dynamic) CURRENT_USER.

Quant à trouver une soluce, j'ai pas d'idée.
--
jp

[WebPac]

n'est pas un user normal avec les droits limités, les dossiers perso et tout ça.
Il me semble que CURRENT_USER n'est valide qu'une fois un user loggué, non ?, alors qu'un service tourne depuis le démarrage de l'OS : il n'y a aucune raison pour qu'il aille trifouiller dans ce (dynamic) CURRENT_USER.

Quant à trouver une soluce, j'ai pas d'idée.
--
jp

C'est vrai, mais un service tourne aussi quand un user est loggué, et dans ce cas là, CURRENT_USER existe, donc il devrait pouvoir aller y trifouiller dedans.
S'il faut limiter le trifouillage que quand un user est loggué, il n'y a aucun soucis pour moi car justement ce code ne doit s'exécuter qu'une fois un user loggué.

Je comprends bien qu'un service peut s'exécuter même sans user loggué mais il faut bien pouvoir exécuter ce code quand un user est loggué. Ce n'est pas bon de tout bloquer parce qu'il est possible qu'aucun user ne soit loggué.

[Jipété]

D'accord...
C'est p'têt un pb de droits, alors ? À voir avec Regedt32 ?
Je te dis pas comment ça va être la pagaille, alors, avec la virtualisation dans Vista...
--
jp

[WebPac]

Le soucis est que j'utilise exactement le même code. Je ne sais pas du tout ce qu'est regedt32.

[Jipété]

Regedt32.exe, un utilitaire Windows pour gérer les droits dans la base de registre.
Ceci étant, y a rien qui dit que ça va t'être utile.
--
jp

[WebPac]

Je doute aussi que ça me soit utile.

[WebPac]

En fait, il considère que le user est NetworkService et non pas le CURRENT_USER.
J'ai trouvé ça car quand je souhaite utiliser la fonction SelectDirectory, il me fait ce message d'erreur :

C:\Documents and Settings\NetworkService\Bureau fait référence à un emplacement non disponible.

Faut que je trouve comment changer le user, ou bien faire une console d'administration du service qui serrait un programme. Ca résoudrait les 2 problèmes en même temps.

[Eric 90]

J'ai eu ce genre de problème en exécutant une tâche planifiée au nom du compte SYSTEM. Je voulais savoir si au moment de son éxécution un utilisateur "humain" était loggé. Mais, même si c'était le cas la ruche HKCU était celle du SYSTEM... (normal d'ailleurs si on y réfléchit). Je n'ai pas trouvé le moyen (il doit pourtant y en avoir un) de savoir à l'aide du registre si il y avait ou non un utilisateur loggué lors de l'éxécution de la tâche.
J'ai résolu mon problème à l'aide d'un fichier log que je crée et détruis à chaque connexion et déconnexion "humaine", avec la stratégie du domaine (faisable aussi localement). Il suffit de tester sa présence pour savoir s'il y a quelqu'un...

[WebPac]

Merci mais je vais faire autrement, ta solution fait trop rapiéçage, et il faut gérer les connexions déconnexions d'users, avec des potentiels sources de bugs un peu partout.

Je vais changer la stratégie et ne plus attaquer la base de registre depuis un service, ni non changer de dossier (qui bugue aussi à cause du user). Ce serra plus propre.