Lancement d'un service lors du boot et non de l'ouverture de la session

Le
JKB
Bonjour a tous,

Je suis en train de reinstaller chez un client un serveur que j'ai
downgrade de W7 a XP pro. Ce serveur est un serveur de base de
donnees d'imagerie medicale qui tourne entre autre avec Solid.

La base de donnees est sur un disque reseau (un partage samba issue
d'une Sun qui fait du raid) qui est monte en X:
Les profils itinerants fonctionnent et lorsqu'un utilisateur ouvre
sa session, tous les partages sont bien la. Le probleme est que
le serveur solid doit se lancer lors du boot. J'ai donc commis un
script qui ne casse pas trois pattes a un canard :

NET USE X: \cabinetvisiodent ..
C:SolidSolfe.exe -cX:Solid

Et bien, ce truc ne fonctionne pas ! Si je le lance avec une session
ouverte, ca fonctionne parfaitement.

J'ai essaye de mofifier la valeur de la clef start en 0 (boot), mais
ca ne donne rien. Je vais essayer 1 (system), mais je n'ai pas
beaucoup d'espoir.

Une idee ? Parce que je suis sur ce probleme depuis ce matin et je
disjoncte !

Merci pour vos lumieres (et desole pour les accents, putty ne les
aime pas).

Cordialement,

JKB


--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal
Le #21361761
Le 11/03/2010 18:24, JKB a écrit :
Bonjour a tous,

Je suis en train de reinstaller chez un client un serveur que j'ai
downgrade de W7 a XP pro. Ce serveur est un serveur de base de
donnees d'imagerie medicale qui tourne entre autre avec Solid.

La base de donnees est sur un disque reseau (un partage samba issue
d'une Sun qui fait du raid) qui est monte en X:
Les profils itinerants fonctionnent et lorsqu'un utilisateur ouvre
sa session, tous les partages sont bien la. Le probleme est que
le serveur solid doit se lancer lors du boot. J'ai donc commis un
script qui ne casse pas trois pattes a un canard :

NET USE X: \cabinetvisiodent .....
C:SolidSolfe.exe -cX:Solid

Et bien, ce truc ne fonctionne pas ! Si je le lance avec une session
ouverte, ca fonctionne parfaitement.

J'ai essaye de mofifier la valeur de la clef start en 0 (boot), mais
ca ne donne rien. Je vais essayer 1 (system), mais je n'ai pas
beaucoup d'espoir.

Une idee ? Parce que je suis sur ce probleme depuis ce matin et je
disjoncte !...

Merci pour vos lumieres (et desole pour les accents, putty ne les
aime pas...).

Cordialement,

JKB




pas sur de ce que j'avance mais ça ne peux pas se faire avec le service
autoexnt ?
http://support.microsoft.com/kb/243486/fr
DuboisP
Le #21362241
Le Thu, 11 Mar 2010 18:24:53 +0100, JKB
Bonjour a tous,

Je suis en train de reinstaller chez un client un serveur que j'ai
downgrade de W7 a XP pro. Ce serveur est un serveur de base de
donnees d'imagerie medicale qui tourne entre autre avec Solid.

La base de donnees est sur un disque reseau (un partage samba issue
d'une Sun qui fait du raid) qui est monte en X:
Les profils itinerants fonctionnent et lorsqu'un utilisateur ouvre
sa session, tous les partages sont bien la. Le probleme est que
le serveur solid doit se lancer lors du boot. J'ai donc commis un
script qui ne casse pas trois pattes a un canard :

NET USE X: \cabinetvisiodent .....
C:SolidSolfe.exe -cX:Solid

Et bien, ce truc ne fonctionne pas ! Si je le lance avec une session
ouverte, ca fonctionne parfaitement.

J'ai essaye de mofifier la valeur de la clef start en 0 (boot), mais
ca ne donne rien. Je vais essayer 1 (system), mais je n'ai pas
beaucoup d'espoir.

Une idee ? Parce que je suis sur ce probleme depuis ce matin et je
disjoncte !...

Merci pour vos lumieres (et desole pour les accents, putty ne les
aime pas...).

Cordialement,

JKB





c'est un peu normal
au boot, tu n'as pas d'authentification d'utilisateur
il faut donc, au minimum, faire un net use password x:\cabinetvisiodent
/user:xxxxxxxxxxxx
ou faire tourner non en compte system , mais en compte network

appeler serveur un 7 ou un XP Pro, c'est abuser

Visiodent, j'ai aussi, entre autres, pour faire du X-Ray numérique en
vétérinaire, et je m'amuse en ce moment
avec un serveur w2003/iis/sql et du PACS/DICOM
côté logiciel serveur d'imagerie, j'ai installé ClearCanvas
(http://www.clearcanvas.ca/)

--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/
JKB
Le #21363131
Le 11-03-2010, ? propos de
Re: Lancement d'un service lors du boot et non de l'ouverture de la session,
DuboisP ?crivait dans fr.comp.os.ms-windows :
Le Thu, 11 Mar 2010 18:24:53 +0100, JKB
Bonjour a tous,

Je suis en train de reinstaller chez un client un serveur que j'ai
downgrade de W7 a XP pro. Ce serveur est un serveur de base de
donnees d'imagerie medicale qui tourne entre autre avec Solid.

La base de donnees est sur un disque reseau (un partage samba issue
d'une Sun qui fait du raid) qui est monte en X:
Les profils itinerants fonctionnent et lorsqu'un utilisateur ouvre
sa session, tous les partages sont bien la. Le probleme est que
le serveur solid doit se lancer lors du boot. J'ai donc commis un
script qui ne casse pas trois pattes a un canard :

NET USE X: \cabinetvisiodent .....
C:SolidSolfe.exe -cX:Solid

Et bien, ce truc ne fonctionne pas ! Si je le lance avec une session
ouverte, ca fonctionne parfaitement.

J'ai essaye de mofifier la valeur de la clef start en 0 (boot), mais
ca ne donne rien. Je vais essayer 1 (system), mais je n'ai pas
beaucoup d'espoir.

Une idee ? Parce que je suis sur ce probleme depuis ce matin et je
disjoncte !...

Merci pour vos lumieres (et desole pour les accents, putty ne les
aime pas...).

Cordialement,

JKB





c'est un peu normal
au boot, tu n'as pas d'authentification d'utilisateur
il faut donc, au minimum, faire un net use password x:\cabinetvisiodent
/user:xxxxxxxxxxxx
ou faire tourner non en compte system , mais en compte network



C'est ce que je fais. Ça ne fonctionne pas. Solid balance une erreur
qui n'est même pas récupérée dans les journaux système. Résultat, je
ne sais même pas ce qui merdoie. Le plus amusant, c'est qu'en
essayant de monter le disque réseau dans le service par net use et
l'authentification, ça me casse la connexion aux profils itinérants
avec la très jolie : "windows vous connecte sur un profil local".

Déjà, j'aimerais savoir quand est démarré un service qui apparaît
dans services.msc. J'ai l'impression que c'est lors d'une ouverture
de session. Comment faire pour que ça se lance lors du boot ?

appeler serveur un 7 ou un XP Pro, c'est abuser



On est bien d'accord, mais tant que cette @~#"{@ tournera sous
Solid, je n'ai pas le choix. Le serveur de fichier est un truc
largement plus sérieux.

Visiodent, j'ai aussi, entre autres, pour faire du X-Ray numérique en
vétérinaire, et je m'amuse en ce moment
avec un serveur w2003/iis/sql et du PACS/DICOM
côté logiciel serveur d'imagerie, j'ai installé ClearCanvas
(http://www.clearcanvas.ca/)



Je n'ai pas le choix. C'est Visiodent + Dimaxis.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
DuboisP
Le #21363281
Le Thu, 11 Mar 2010 22:47:11 +0100, JKB
Le 11-03-2010, ? propos de
Re: Lancement d'un service lors du boot et non de l'ouverture de la
session,
DuboisP ?crivait dans fr.comp.os.ms-windows :
Le Thu, 11 Mar 2010 18:24:53 +0100, JKB écrit:

Bonjour a tous,

Je suis en train de reinstaller chez un client un serveur que j'ai
downgrade de W7 a XP pro. Ce serveur est un serveur de base de
donnees d'imagerie medicale qui tourne entre autre avec Solid.

La base de donnees est sur un disque reseau (un partage samba issue
d'une Sun qui fait du raid) qui est monte en X:
Les profils itinerants fonctionnent et lorsqu'un utilisateur ouvre
sa session, tous les partages sont bien la. Le probleme est que
le serveur solid doit se lancer lors du boot. J'ai donc commis un
script qui ne casse pas trois pattes a un canard :

NET USE X: \cabinetvisiodent .....
C:SolidSolfe.exe -cX:Solid

Et bien, ce truc ne fonctionne pas ! Si je le lance avec une session
ouverte, ca fonctionne parfaitement.

J'ai essaye de mofifier la valeur de la clef start en 0 (boot), mais
ca ne donne rien. Je vais essayer 1 (system), mais je n'ai pas
beaucoup d'espoir.

Une idee ? Parce que je suis sur ce probleme depuis ce matin et je
disjoncte !...

Merci pour vos lumieres (et desole pour les accents, putty ne les
aime pas...).

Cordialement,

JKB





c'est un peu normal
au boot, tu n'as pas d'authentification d'utilisateur
il faut donc, au minimum, faire un net use password
x:\cabinetvisiodent
/user:xxxxxxxxxxxx
ou faire tourner non en compte system , mais en compte network



C'est ce que je fais. Ça ne fonctionne pas. Solid balance une erreur
qui n'est même pas récupérée dans les journaux système. Résultat, je
ne sais même pas ce qui merdoie. Le plus amusant, c'est qu'en
essayant de monter le disque réseau dans le service par net use et
l'authentification, ça me casse la connexion aux profils itinérants
avec la très jolie : "windows vous connecte sur un profil local".

Déjà, j'aimerais savoir quand est démarré un service qui apparaît
dans services.msc. J'ai l'impression que c'est lors d'une ouverture
de session. Comment faire pour que ça se lance lors du boot ?

appeler serveur un 7 ou un XP Pro, c'est abuser



On est bien d'accord, mais tant que cette @~#"{@ tournera sous
Solid, je n'ai pas le choix. Le serveur de fichier est un truc
largement plus sérieux.

Visiodent, j'ai aussi, entre autres, pour faire du X-Ray numérique en
vétérinaire, et je m'amuse en ce moment
avec un serveur w2003/iis/sql et du PACS/DICOM
côté logiciel serveur d'imagerie, j'ai installé ClearCanvas
(http://www.clearcanvas.ca/)



Je n'ai pas le choix. C'est Visiodent + Dimaxis.

JKB




on dévie, on dévie...

merci de m'avoir fait connaitre ces produits
si je comprends bien

Visiodent prend les X-Ray
Dimaxis permet d'en faire un rendu
Solid les stocke

mes véto utilisent VisioDent + DICOM, et un Philips Eleva en X-Ray
corporel.
Les X-Ray sont poussées en Dicom sur le ClearCanvas ImageServer qui gére
les métadonnées
Les images Dicom sont stockées dans une arborescence de fichiers et sont
consultables
soit par un client ClearCanvas, soit par un viewer Dicom.
On s'est même amuser à mettre des régles de routage pour leur faire
traverser l'Atlantique vers un autre serveur ClearCanvas

pour ceux qui ne connaissent pas , DICOM est un protocole de gestion et de
communication en imagerie médicale.
c'est très normalisé, et intéressant à connaître (surtout quand on n'en
avait jamais entendu parler).
heureusement qu'on a parfois des projets intéressants, dans ce métier
d'informaticien.



je regarde quelques vieux scripts demain, je ne les ai pas sous le coude

--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/
Pascal
Le #21363931
Sinon je pense que autoexnt permet de faire ce que tu souhaites
De plus il faut plutot utiliser net use avec les informations d'authentification
NET USE X: \cabinetvisiodent password /user:DomaineUtilisateur

Bon courage
Jean-Claude BELLAMY
Le #21364341
"JKB" discussion :
[...]
Déjà, j'aimerais savoir quand est démarré un service qui apparaît
dans services.msc.


Tu ne peux pas le savoir avec cette MMC.

Il faut aller examiner la BDR, et plus exactement l'arborescence
HKLMSYSTEMCurrentControlSetservices

Chaque sous-clef correspond à un service.

Le mode de démarrage du service est défini dans l'entrée "Start"
0x00
Boot
= Chargé par le loader (NTLDR)
0x01
System
= Chargé lors de l'initialisation du noyau
0x02
Auto (valeur la plus courante)
= Chargé et démarré automatiquement lors
du démarrage du système
0x03
Manuel
= Démarré par l'utilisateur ou par un autre processus
0x04
Désactivé
= Jamais démarré.
Une exception : les drivers de système de fichiers sont
chargés même avec start=4


Cela est complété par l'entrée "Type" qui indique le type du service :
0x01
Pilote de périphérique en mode noyau
0x02
Pilote de périphérique en mode noyau
mettant en oeuvre des services du système de fichiers
0x04
Arguments utilisés par une carte réseau
0x10
Service Win32
à lancer comme un processus autonome
0x20
Service Win32
autorisé à partager l'espace d'adressage avec
d'autres services du même type


Par exemple :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesApache2.2
Start = 0x02
Type = 0x10
-> service Win32 automatique et autonome

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesatapi
Start = 0x03
Type = 0x01
-> service pilote de périphérique en mode noyau
démarré manuellement (ou par un autre processus)

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesNetBIOS
Start = 0x01
Type = 0x02
-> service Pilote de périphérique en mode noyau
mettant en oeuvre des services du système de fichiers
démarré avec le système.



J'ai l'impression que c'est lors d'une ouverture
de session. Comment faire pour que ça se lance lors du boot ?





--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dominique Ottello
Le #21364831
"Jean-Claude BELLAMY"
Tu ne peux pas le savoir avec cette MMC.

Il faut aller examiner la BDR, et plus exactement l'arborescence
HKLMSYSTEMCurrentControlSetservices



J'ajouterais quelques détails supplémentaires (JCB, tu corriges si
j'écris des concetés)

Séquence de démarrage de Windows XP

Pour « lancer » un logiciel au démarrage de Windows et en fonction de la
version, il existe plusieurs méthodes :
- placer un raccourci dans le dossier "Démarrage" du menu démarrer de
Windows
- placer des instructions dans des fichiers INI
- placer des instructions dans des fichiers spéciaux de configuration
hérité du DOS et ouverts/exécutés par le système
- placer des clés dans des emplacements prévus à cet effet dans la base
de registres de Windows
- utiliser des services « masqués »
- utiliser des services « masqués » visibles

La première méthode, c'est-à-dire celle consistant à placer un raccourci
dans le dossier "Démarrage" du menu démarrer de Windows, n'est pas très
élégante et si elle était largement utilisée par le passé, elle n'est
que rarement utilisée aujourd'hui.
Elle est « délicate », car si, en voulant faire le ménage ou à la suite
d'un clic souris mal approprié, l'utilisateur enlève le raccourci... le
programme censé démarrer au démarrage de Windows ne démarrera plus.
Si le raccourci était censé lancer l'antivirus ou le parefeu... Et oui
... plus d'antivirus ou de parefeu ...

Cette méthode a l'avantage d'être simple à mettre en oeuvre par tout le
monde ; par exemple, l'utilisateur veut qu'un programme démarre en même
temps que Windows et cela n'a pas été prévu par les concepteurs dudit
programme ; il suffit de créer un raccourci vers le programme exécutable
qui doit être lancé et de placer ce raccourci dans le dossier
"Démarrage" du menu démarrer de Windows.

Pendant la phase de démarrage de la machine, tous les logiciels dont le
démarrage est programmé en divers emplacements sont lancés.

Pour cette raison, quand Windows démarre, plusieurs processus se mettent
en route pour « lancer » tous ces programmes et l'utilisateur voit alors
des icônes apparaître (ou pas) les unes à la suite des autres dans la
zone de notification (à côté de l'heure).

Important : L'ordre d'apparition des icônes ne présage en rien de
l'ordre de lancement des logiciels.
En effet, l'icône d'un gros programme démarré en premier peut très bien
s'afficher après l'icône d'un tout petit programme lancé en dernier.
Ce n'est donc pas en observant l'ordre d'apparition des icônes dans la
zone de notification que l'on peut détecter ou définir l'ordre de
lancement des programmes.

Le chargement des logiciels pendant la phase de démarrage d'une machine
repose sur un principe rigide mais simple.
À quelques petits détails près, les services démarrent en premier
puisqu'ils sont à l'origine de tout ce qui « tourne » sur la machine (ou
presque tout).
Pendant cette séquence de démarrage des services, si un service "x"
démarre après un service "y", c'est parce qu'il doit en être ainsi, à
moins bien sur que le service "x" n'ait été développé et mis au point
avec les pieds par quelqu'un qui n'a pas pensé de faire en sorte que son
service "x" démarre avant le service "y".

Les services ne démarrent pas au hasard : l'ordre de démarrage des
services est stocké dans une clé de la Base de Registres de Windows, à
savoir :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlServiceGroupOrder

Les données de cette valeur peuvent être du genre suivant:
System Reserved
Boot Bus Extender
System Bus Extender
SCSI miniport
Port
Primary Disk
SCSI Class
SCSI CDROM Class
FSFilter Infrastructure
FSFilter System
FSFilter Bottom
FSFilter Copy Protection
FSFilter Security Enhancer
FSFilter Open File
FSFilter Physical Quota Management
FSFilter Encryption
FSFilter Compression
FSFilter HSM
FSFilter Cluster File System
FSFilter System Recovery
FSFilter Quota Management
FSFilter Content Screener
FSFilter Continuous Backup
FSFilter Replication
FSFilter Anti-Virus
FSFilter Undelete
FSFilter Activity Monitor
FSFilter Top
Filter
Boot File System
Base
Pointer Port
Keyboard Port
Pointer Class
Keyboard Class
Video Init
Video
Video Save
File System
Event Log
Streams Drivers
NDIS Wrapper
COM Infrastructure
UIGroup
LocalValidation
PlugPlay
PNP_TDI
NDIS
TDI
NetBIOSGroup
ShellSvcGroup
SchedulerGroup
SpoolerGroup
AudioGroup
SmartCardGroup
NetworkProvider
RemoteValidation
NetDDEGroup
Parallel arbitrator
Extended Base
PCI Configuration
MS Transactions

Remarque : L'entrée "FSFilter Anti-Virus" dont dépend un antivirus est
placée avant les entrées qui concernent le réseau (COM Infrastructure,
NetworkProvider, NetDDEGroup). Donc, sur une machine reliée à Internet
via une connexion permanente qui s'initialise au boot de la machine,
l'antivirus est démarré avant le processus de connexion au réseau et il
sera donc actif lorsque la connexion au réseau s'initialise.

Les informations relatives aux services sont stockées dans la Base de
Registres de Windows dans la clé suivante :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices

Chaque service est associé à une sous-clé, par exemple
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesAVP pour le service
AVP qui engendre le démarrage de Kaspersky ou
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceswampapache pour le
service qui démarrage mon serveur Apache.
Dans ces sous-clés, on trouve des entrées qui peuvent varier suivant le
service concerné:
- DependOnGroup Liste des groupes de services dont dépend le service
concerné
- DependOnService Liste des services dont dépend le service concerné
- Description Description du service
- DisplayName Nom abrégé du service
- ErrorControl Définit la conduite à tenir en cas d'erreur
- Group Nom du groupe auquel appartient le service
- ImagePath Chemin de l'exécutable associé
- ObjectName Compte sous lequel le service est exécuté
- Parameters Paramètres éventuels privés
- Start Défini le mode de démarrage du service
- Tag Spécifie l'ordre dans lequel les services d'un même groupe sont
lancés, par ordre croissant de la valeur de tag
- Type Type du service

L'entrée "Start" défini le mode de démarrage du service et sa valeur, en
hexadécimal, peut être:
a) 0x00 -> Boot -> Chargé par le loader (NTLDR)
b) 0x01 -> System -> Chargé lors de l'initialisation du noyau
c) 0x02 -> Auto (valeur la plus courante) Chargé et démarré
automatiquement lors du démarrage du système
d) 0x03 -> Manuel Démarré par l'utilisateur ou par un autre processus
e) 0x04 -> Désactivé Jamais démarré

Une exception toutefois: les drivers de système de fichiers sont chargés
même avec start = "0x04"
--
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net)
Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
JKB
Le #21369391
Le 12-03-2010, ? propos de
Re: Lancement d'un service lors du boot et non de l'ouverture de la session,
Dominique Ottello ?crivait dans fr.comp.os.ms-windows :
"Jean-Claude BELLAMY"
Tu ne peux pas le savoir avec cette MMC.

Il faut aller examiner la BDR, et plus exactement l'arborescence
HKLMSYSTEMCurrentControlSetservices



J'ajouterais quelques détails supplémentaires (JCB, tu corriges si
j'écris des concetés)

Séquence de démarrage de Windows XP

Pour « lancer » un logiciel au démarrage de Windows et en fonction de la
version, il existe plusieurs méthodes :
- placer un raccourci dans le dossier "Démarrage" du menu démarrer de
Windows
- placer des instructions dans des fichiers INI
- placer des instructions dans des fichiers spéciaux de configuration
hérité du DOS et ouverts/exécutés par le système
- placer des clés dans des emplacements prévus à cet effet dans la base
de registres de Windows
- utiliser des services « masqués »
- utiliser des services « masqués » visibles

La première méthode, c'est-à-dire celle consistant à placer un raccourci
dans le dossier "Démarrage" du menu démarrer de Windows, n'est pas très
élégante et si elle était largement utilisée par le passé, elle n'est
que rarement utilisée aujourd'hui.
Elle est « délicate », car si, en voulant faire le ménage ou à la suite
d'un clic souris mal approprié, l'utilisateur enlève le raccourci... le
programme censé démarrer au démarrage de Windows ne démarrera plus.
Si le raccourci était censé lancer l'antivirus ou le parefeu... Et oui
... plus d'antivirus ou de parefeu ...

Cette méthode a l'avantage d'être simple à mettre en oeuvre par tout le
monde ; par exemple, l'utilisateur veut qu'un programme démarre en même
temps que Windows et cela n'a pas été prévu par les concepteurs dudit
programme ; il suffit de créer un raccourci vers le programme exécutable
qui doit être lancé et de placer ce raccourci dans le dossier
"Démarrage" du menu démarrer de Windows.

Pendant la phase de démarrage de la machine, tous les logiciels dont le
démarrage est programmé en divers emplacements sont lancés.

Pour cette raison, quand Windows démarre, plusieurs processus se mettent
en route pour « lancer » tous ces programmes et l'utilisateur voit alors
des icônes apparaître (ou pas) les unes à la suite des autres dans la
zone de notification (à côté de l'heure).

Important : L'ordre d'apparition des icônes ne présage en rien de
l'ordre de lancement des logiciels.
En effet, l'icône d'un gros programme démarré en premier peut très bien
s'afficher après l'icône d'un tout petit programme lancé en dernier.
Ce n'est donc pas en observant l'ordre d'apparition des icônes dans la
zone de notification que l'on peut détecter ou définir l'ordre de
lancement des programmes.

Le chargement des logiciels pendant la phase de démarrage d'une machine
repose sur un principe rigide mais simple.
À quelques petits détails près, les services démarrent en premier
puisqu'ils sont à l'origine de tout ce qui « tourne » sur la machine (ou
presque tout).
Pendant cette séquence de démarrage des services, si un service "x"
démarre après un service "y", c'est parce qu'il doit en être ainsi, à
moins bien sur que le service "x" n'ait été développé et mis au point
avec les pieds par quelqu'un qui n'a pas pensé de faire en sorte que son
service "x" démarre avant le service "y".

Les services ne démarrent pas au hasard : l'ordre de démarrage des
services est stocké dans une clé de la Base de Registres de Windows, à
savoir :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlServiceGroupOrder

Les données de cette valeur peuvent être du genre suivant:
System Reserved
Boot Bus Extender
System Bus Extender
SCSI miniport
Port
Primary Disk
SCSI Class
SCSI CDROM Class
FSFilter Infrastructure
FSFilter System
FSFilter Bottom
FSFilter Copy Protection
FSFilter Security Enhancer
FSFilter Open File
FSFilter Physical Quota Management
FSFilter Encryption
FSFilter Compression
FSFilter HSM
FSFilter Cluster File System
FSFilter System Recovery
FSFilter Quota Management
FSFilter Content Screener
FSFilter Continuous Backup
FSFilter Replication
FSFilter Anti-Virus
FSFilter Undelete
FSFilter Activity Monitor
FSFilter Top
Filter
Boot File System
Base
Pointer Port
Keyboard Port
Pointer Class
Keyboard Class
Video Init
Video
Video Save
File System
Event Log
Streams Drivers
NDIS Wrapper
COM Infrastructure
UIGroup
LocalValidation
PlugPlay
PNP_TDI
NDIS
TDI
NetBIOSGroup
ShellSvcGroup
SchedulerGroup
SpoolerGroup
AudioGroup
SmartCardGroup
NetworkProvider
RemoteValidation
NetDDEGroup
Parallel arbitrator
Extended Base
PCI Configuration
MS Transactions

Remarque : L'entrée "FSFilter Anti-Virus" dont dépend un antivirus est
placée avant les entrées qui concernent le réseau (COM Infrastructure,
NetworkProvider, NetDDEGroup). Donc, sur une machine reliée à Internet
via une connexion permanente qui s'initialise au boot de la machine,
l'antivirus est démarré avant le processus de connexion au réseau et il
sera donc actif lorsque la connexion au réseau s'initialise.

Les informations relatives aux services sont stockées dans la Base de
Registres de Windows dans la clé suivante :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices

Chaque service est associé à une sous-clé, par exemple
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesAVP pour le service
AVP qui engendre le démarrage de Kaspersky ou
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceswampapache pour le
service qui démarrage mon serveur Apache.
Dans ces sous-clés, on trouve des entrées qui peuvent varier suivant le
service concerné:
- DependOnGroup Liste des groupes de services dont dépend le service
concerné
- DependOnService Liste des services dont dépend le service concerné
- Description Description du service
- DisplayName Nom abrégé du service
- ErrorControl Définit la conduite à tenir en cas d'erreur
- Group Nom du groupe auquel appartient le service
- ImagePath Chemin de l'exécutable associé
- ObjectName Compte sous lequel le service est exécuté
- Parameters Paramètres éventuels privés
- Start Défini le mode de démarrage du service
- Tag Spécifie l'ordre dans lequel les services d'un même groupe sont
lancés, par ordre croissant de la valeur de tag
- Type Type du service

L'entrée "Start" défini le mode de démarrage du service et sa valeur, en
hexadécimal, peut être:
a) 0x00 -> Boot -> Chargé par le loader (NTLDR)
b) 0x01 -> System -> Chargé lors de l'initialisation du noyau
c) 0x02 -> Auto (valeur la plus courante) Chargé et démarré
automatiquement lors du démarrage du système
d) 0x03 -> Manuel Démarré par l'utilisateur ou par un autre processus
e) 0x04 -> Désactivé Jamais démarré

Une exception toutefois: les drivers de système de fichiers sont chargés
même avec start = "0x04"



Merci pour ces informations. J'ai utilisé toutes ces informations
pour essayer de trouver une solution en vain. J'ai donc créé un
service dépendant des services réseau et authentification (je n'ai
plus les noms en tête) qui monte le disque distant pour lancer solid
dessus. Ça merdoie allègrement. Solid plante sur des erreurs d'accès
à la ressource distante (en l'occurrence X:). Ce qui est marrant,
c'est que si je lance le service en tant qu'utilisateur local, ça
fonctionne parfaitement, ce qui prouve que ce n'est pas un problème
de droit ni de script.

Pour l'instant, le truc a donc pris place dans le menu démarrage.
Comme il faut toujours une session ouverte pour utiliser l'outil, ça
ira bien comme ça même si ce n'est pas propre.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
DuboisP
Le #21369471
Le Sat, 13 Mar 2010 09:34:06 +0100, JKB

Merci pour ces informations. J'ai utilisé toutes ces informations
pour essayer de trouver une solution en vain. J'ai donc créé un
service dépendant des services réseau et authentification (je n'ai
plus les noms en tête) qui monte le disque distant pour lancer solid
dessus. Ça merdoie allègrement. Solid plante sur des erreurs d'accès
à la ressource distante (en l'occurrence X:). Ce qui est marrant,
c'est que si je lance le service en tant qu'utilisateur local, ça
fonctionne parfaitement, ce qui prouve que ce n'est pas un problème
de droit ni de script.

Pour l'instant, le truc a donc pris place dans le menu démarrage.
Comme il faut toujours une session ouverte pour utiliser l'outil, ça
ira bien comme ça même si ce n'est pas propre.

JKB




j'ai retrouvé mes scripts, qui faisaient du backup/xcopy session fermée.
le scheduling AT lançait un script qui faisait un mappage disque avec
user/password, les copies et refermait ensuite les connexions.

en fait, je pense que ce que tu veux faire est (quasiment) impossible.
ton service fait des connexions, mais l'utilisateur connecté n'hérite pas
du contexte, et donc ça merde
--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/
Pascal
Le #21370411
Le 13/03/2010 09:34, JKB a écrit :
Le 12-03-2010, ? propos de
Re: Lancement d'un service lors du boot et non de l'ouverture de la session,
Dominique Ottello ?crivait dans fr.comp.os.ms-windows :
"Jean-Claude BELLAMY"
Tu ne peux pas le savoir avec cette MMC.

Il faut aller examiner la BDR, et plus exactement l'arborescence
HKLMSYSTEMCurrentControlSetservices



J'ajouterais quelques détails supplémentaires (JCB, tu corriges si
j'écris des concetés)

Séquence de démarrage de Windows XP

Pour « lancer » un logiciel au démarrage de Windows et en fonction de la
version, il existe plusieurs méthodes :
- placer un raccourci dans le dossier "Démarrage" du menu démarrer de
Windows
- placer des instructions dans des fichiers INI
- placer des instructions dans des fichiers spéciaux de configuration
hérité du DOS et ouverts/exécutés par le système
- placer des clés dans des emplacements prévus à cet effet dans la base
de registres de Windows
- utiliser des services « masqués »
- utiliser des services « masqués » visibles

La première méthode, c'est-à-dire celle consistant à placer un raccourci
dans le dossier "Démarrage" du menu démarrer de Windows, n'est pas très
élégante et si elle était largement utilisée par le passé, elle n'est
que rarement utilisée aujourd'hui.
Elle est « délicate », car si, en voulant faire le ménage ou à la suite
d'un clic souris mal approprié, l'utilisateur enlève le raccourci... le
programme censé démarrer au démarrage de Windows ne démarrera plus.
Si le raccourci était censé lancer l'antivirus ou le parefeu... Et oui
... plus d'antivirus ou de parefeu ...

Cette méthode a l'avantage d'être simple à mettre en oeuvre par tout le
monde ; par exemple, l'utilisateur veut qu'un programme démarre en même
temps que Windows et cela n'a pas été prévu par les concepteurs dudit
programme ; il suffit de créer un raccourci vers le programme exécutable
qui doit être lancé et de placer ce raccourci dans le dossier
"Démarrage" du menu démarrer de Windows.

Pendant la phase de démarrage de la machine, tous les logiciels dont le
démarrage est programmé en divers emplacements sont lancés.

Pour cette raison, quand Windows démarre, plusieurs processus se mettent
en route pour « lancer » tous ces programmes et l'utilisateur voit alors
des icônes apparaître (ou pas) les unes à la suite des autres dans la
zone de notification (à côté de l'heure).

Important : L'ordre d'apparition des icônes ne présage en rien de
l'ordre de lancement des logiciels.
En effet, l'icône d'un gros programme démarré en premier peut très bien
s'afficher après l'icône d'un tout petit programme lancé en dernier.
Ce n'est donc pas en observant l'ordre d'apparition des icônes dans la
zone de notification que l'on peut détecter ou définir l'ordre de
lancement des programmes.

Le chargement des logiciels pendant la phase de démarrage d'une machine
repose sur un principe rigide mais simple.
À quelques petits détails près, les services démarrent en premier
puisqu'ils sont à l'origine de tout ce qui « tourne » sur la machine (ou
presque tout).
Pendant cette séquence de démarrage des services, si un service "x"
démarre après un service "y", c'est parce qu'il doit en être ainsi, à
moins bien sur que le service "x" n'ait été développé et mis au point
avec les pieds par quelqu'un qui n'a pas pensé de faire en sorte que son
service "x" démarre avant le service "y".

Les services ne démarrent pas au hasard : l'ordre de démarrage des
services est stocké dans une clé de la Base de Registres de Windows, à
savoir :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlServiceGroupOrder

Les données de cette valeur peuvent être du genre suivant:
System Reserved
Boot Bus Extender
System Bus Extender
SCSI miniport
Port
Primary Disk
SCSI Class
SCSI CDROM Class
FSFilter Infrastructure
FSFilter System
FSFilter Bottom
FSFilter Copy Protection
FSFilter Security Enhancer
FSFilter Open File
FSFilter Physical Quota Management
FSFilter Encryption
FSFilter Compression
FSFilter HSM
FSFilter Cluster File System
FSFilter System Recovery
FSFilter Quota Management
FSFilter Content Screener
FSFilter Continuous Backup
FSFilter Replication
FSFilter Anti-Virus
FSFilter Undelete
FSFilter Activity Monitor
FSFilter Top
Filter
Boot File System
Base
Pointer Port
Keyboard Port
Pointer Class
Keyboard Class
Video Init
Video
Video Save
File System
Event Log
Streams Drivers
NDIS Wrapper
COM Infrastructure
UIGroup
LocalValidation
PlugPlay
PNP_TDI
NDIS
TDI
NetBIOSGroup
ShellSvcGroup
SchedulerGroup
SpoolerGroup
AudioGroup
SmartCardGroup
NetworkProvider
RemoteValidation
NetDDEGroup
Parallel arbitrator
Extended Base
PCI Configuration
MS Transactions

Remarque : L'entrée "FSFilter Anti-Virus" dont dépend un antivirus est
placée avant les entrées qui concernent le réseau (COM Infrastructure,
NetworkProvider, NetDDEGroup). Donc, sur une machine reliée à Internet
via une connexion permanente qui s'initialise au boot de la machine,
l'antivirus est démarré avant le processus de connexion au réseau et il
sera donc actif lorsque la connexion au réseau s'initialise.

Les informations relatives aux services sont stockées dans la Base de
Registres de Windows dans la clé suivante :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices

Chaque service est associé à une sous-clé, par exemple
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesAVP pour le service
AVP qui engendre le démarrage de Kaspersky ou
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceswampapache pour le
service qui démarrage mon serveur Apache.
Dans ces sous-clés, on trouve des entrées qui peuvent varier suivant le
service concerné:
- DependOnGroup Liste des groupes de services dont dépend le service
concerné
- DependOnService Liste des services dont dépend le service concerné
- Description Description du service
- DisplayName Nom abrégé du service
- ErrorControl Définit la conduite à tenir en cas d'erreur
- Group Nom du groupe auquel appartient le service
- ImagePath Chemin de l'exécutable associé
- ObjectName Compte sous lequel le service est exécuté
- Parameters Paramètres éventuels privés
- Start Défini le mode de démarrage du service
- Tag Spécifie l'ordre dans lequel les services d'un même groupe sont
lancés, par ordre croissant de la valeur de tag
- Type Type du service

L'entrée "Start" défini le mode de démarrage du service et sa valeur, en
hexadécimal, peut être:
a) 0x00 -> Boot -> Chargé par le loader (NTLDR)
b) 0x01 -> System -> Chargé lors de l'initialisation du noyau
c) 0x02 -> Auto (valeur la plus courante) Chargé et démarré
automatiquement lors du démarrage du système
d) 0x03 -> Manuel Démarré par l'utilisateur ou par un autre processus
e) 0x04 -> Désactivé Jamais démarré

Une exception toutefois: les drivers de système de fichiers sont chargés
même avec start = "0x04"



Merci pour ces informations. J'ai utilisé toutes ces informations
pour essayer de trouver une solution en vain. J'ai donc créé un
service dépendant des services réseau et authentification (je n'ai
plus les noms en tête) qui monte le disque distant pour lancer solid
dessus. Ça merdoie allègrement. Solid plante sur des erreurs d'accès
à la ressource distante (en l'occurrence X:). Ce qui est marrant,
c'est que si je lance le service en tant qu'utilisateur local, ça
fonctionne parfaitement, ce qui prouve que ce n'est pas un problème
de droit ni de script.

Pour l'instant, le truc a donc pris place dans le menu démarrage.
Comme il faut toujours une session ouverte pour utiliser l'outil, ça
ira bien comme ça même si ce n'est pas propre.

JKB



Par curiosité avez vous essayé autoexnt ?
Publicité
Poster une réponse
Anonyme