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
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
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
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
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
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 Thu, 11 Mar 2010 18:24:53 +0100, 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
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/)
Le Thu, 11 Mar 2010 18:24:53 +0100, JKB <knatschke@koenigsberg.fr> 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
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/)
Le Thu, 11 Mar 2010 18:24:53 +0100, 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
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/)
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 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
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 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 <knatschke@koenigsberg.fr> 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
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 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 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
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
[...]
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 ?
[...]
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 ?
[...]
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 ?
Tu ne peux pas le savoir avec cette MMC.
Il faut aller examiner la BDR, et plus exactement l'arborescence
HKLMSYSTEMCurrentControlSetservices
Tu ne peux pas le savoir avec cette MMC.
Il faut aller examiner la BDR, et plus exactement l'arborescence
HKLMSYSTEMCurrentControlSetservices
Tu ne peux pas le savoir avec cette MMC.
Il faut aller examiner la BDR, et plus exactement l'arborescence
HKLMSYSTEMCurrentControlSetservices
"Jean-Claude BELLAMY" écrivait :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"
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> écrivait :
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"
"Jean-Claude BELLAMY" écrivait :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
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
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 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" écrivait :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 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"<Jean-Claude.Bellamy@wanadoo.fr> écrivait :
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 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" écrivait :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