Bonjour j'ai un problème depuis plusieurs semaines que je n'arrive pas à
régler. Lorsque les usagers se log dans windows xp sp2 desfois le process
explorer.exe ne roule pas et on ne voit pas aucun icône et le taskbar. J'ai
essayé plusieurs trucs trouvé sur des forums à ce sujet sans succès.
J'avais pensé faire un service qui vérifie lorsqu'on se log si le process
explorer.exe fonctionne ou pas. Si il ne fonctionne pas alors on le lance.
J'ai utilisé le language autoit pour cela alors voici mon code
While Not ProcessExists("explorer.exe")
Run("explorer.exe")
Sleep(5000);
WEnd
Exit
-------------------------------------------------------------------------------------------------------
Si je termine le process "explorer.exe" et que je lance se script, tout
fonctionne à merveille. Les icônes reviennent et la taskbar aussi. Mais si
je démarre le service, le process "explorer.exe" démarre mais il ne se passe
rien. Aucun icône et/ou taskbar apparait
Si je termine le process "explorer.exe" et que je lance se script, tout fonctionne à merveille. (...)
Cela me semble normal : TU lances le script qui lance, "en ton nom" explorer.exe
Mais si je démarre le service, le process "explorer.exe" (...)
est lancé par le service qui tourne sous l'autorité de l'utilisateur SYSTEM ( je présume) donc explorer ne tourne pas "pour toi" mais pour "system" qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Donc l'idée risque de devenir une usine à gaz puisque cela doit fonctionner pour un utilisateur à priori inconnu utilisateur dont tu ignore aussi le mot de passe. Le service ne peut donc pas lancer un processus à la place de l'utilisateur...
Il me semble plus judicieux de chercher pourquoi explorer.exe ne se lance pas à l'ouverture de session... C'est plus que très suspect.
HB
Salut,
Si je termine le process "explorer.exe" et que je lance se script,
tout fonctionne à merveille. (...)
Cela me semble normal :
TU lances le script qui lance, "en ton nom" explorer.exe
Mais si je démarre le service, le process "explorer.exe" (...)
est lancé par le service qui tourne sous l'autorité de l'utilisateur
SYSTEM
( je présume)
donc explorer ne tourne pas "pour toi" mais pour "system"
qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Donc l'idée risque de devenir une usine à gaz
puisque cela doit fonctionner pour un utilisateur à priori inconnu
utilisateur dont tu ignore aussi le mot de passe.
Le service ne peut donc pas lancer un processus à la place de
l'utilisateur...
Il me semble plus judicieux de chercher
pourquoi explorer.exe ne se lance pas à l'ouverture de session...
C'est plus que très suspect.
Si je termine le process "explorer.exe" et que je lance se script, tout fonctionne à merveille. (...)
Cela me semble normal : TU lances le script qui lance, "en ton nom" explorer.exe
Mais si je démarre le service, le process "explorer.exe" (...)
est lancé par le service qui tourne sous l'autorité de l'utilisateur SYSTEM ( je présume) donc explorer ne tourne pas "pour toi" mais pour "system" qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Donc l'idée risque de devenir une usine à gaz puisque cela doit fonctionner pour un utilisateur à priori inconnu utilisateur dont tu ignore aussi le mot de passe. Le service ne peut donc pas lancer un processus à la place de l'utilisateur...
Il me semble plus judicieux de chercher pourquoi explorer.exe ne se lance pas à l'ouverture de session... C'est plus que très suspect.
HB
Gilles LAURENT
"moi" a écrit dans le message de news: | Salut,
Bonsoir,
|| Si je termine le process "explorer.exe" et que je lance se script, || tout fonctionne à merveille. (...) | | Cela me semble normal : | TU lances le script qui lance, "en ton nom" explorer.exe
Tout à fait !
|| Mais si je démarre le service, le process "explorer.exe" (...) | | est lancé par le service qui tourne sous l'autorité de l'utilisateur | SYSTEM | donc explorer ne tourne pas "pour toi" mais pour "system" | qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Tout à fait !
| Donc l'idée risque de devenir une usine à gaz | puisque cela doit fonctionner pour un utilisateur à priori inconnu | utilisateur dont tu ignore aussi le mot de passe. | Le service ne peut donc pas lancer un processus à la place de | l'utilisateur...
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
| Il me semble plus judicieux de chercher | pourquoi explorer.exe ne se lance pas à l'ouverture de session... | C'est plus que très suspect.
Tout à fait !
-- Gilles LAURENT http://glsft.free.fr
"moi" <moi@pas.la.ici> a écrit dans le message de
news:eDfdunfrHHA.1168@TK2MSFTNGP03.phx.gbl
| Salut,
Bonsoir,
|| Si je termine le process "explorer.exe" et que je lance se script,
|| tout fonctionne à merveille. (...)
|
| Cela me semble normal :
| TU lances le script qui lance, "en ton nom" explorer.exe
Tout à fait !
|| Mais si je démarre le service, le process "explorer.exe" (...)
|
| est lancé par le service qui tourne sous l'autorité de l'utilisateur
| SYSTEM
| donc explorer ne tourne pas "pour toi" mais pour "system"
| qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Tout à fait !
| Donc l'idée risque de devenir une usine à gaz
| puisque cela doit fonctionner pour un utilisateur à priori inconnu
| utilisateur dont tu ignore aussi le mot de passe.
| Le service ne peut donc pas lancer un processus à la place de
| l'utilisateur...
En utilisant les API Win32 de permutation d'autorité / d'identité
(OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un
service démarré sous l'autorité LocalSystem ou privilégié est en mesure
de lancer un processus sous l'autorité de l'utilisateur connecté
localement.
| Il me semble plus judicieux de chercher
| pourquoi explorer.exe ne se lance pas à l'ouverture de session...
| C'est plus que très suspect.
|| Si je termine le process "explorer.exe" et que je lance se script, || tout fonctionne à merveille. (...) | | Cela me semble normal : | TU lances le script qui lance, "en ton nom" explorer.exe
Tout à fait !
|| Mais si je démarre le service, le process "explorer.exe" (...) | | est lancé par le service qui tourne sous l'autorité de l'utilisateur | SYSTEM | donc explorer ne tourne pas "pour toi" mais pour "system" | qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Tout à fait !
| Donc l'idée risque de devenir une usine à gaz | puisque cela doit fonctionner pour un utilisateur à priori inconnu | utilisateur dont tu ignore aussi le mot de passe. | Le service ne peut donc pas lancer un processus à la place de | l'utilisateur...
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
| Il me semble plus judicieux de chercher | pourquoi explorer.exe ne se lance pas à l'ouverture de session... | C'est plus que très suspect.
Tout à fait !
-- Gilles LAURENT http://glsft.free.fr
Gilles LAURENT
"Jac" a écrit dans le message de news: | Bonjour,
Bonsoir,
| j'ai un problème depuis plusieurs semaines que je n'arrive | pas à régler. Lorsque les usagers se log dans windows xp sp2 desfois | le process explorer.exe ne roule pas et on ne voit pas aucun icône et | le taskbar. J'ai essayé plusieurs trucs trouvé sur des forums à ce | sujet sans succès. J'avais pensé faire un service qui vérifie | lorsqu'on se log si le process explorer.exe fonctionne ou pas. Si il | ne fonctionne pas alors on le lance.
Essayez de créer la clé de registre suivante : HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogon AutoRestartShell REG_DWORD (1)
Cela devrait forcer le redémarrage automatique du shell (explorer.exe par défaut) après incident. Il est cependant indispensable de chercher la cause du problème ... Je pense que cette clé est toujours valide sous XP SP2 (à vérifier tout de même)
-- Gilles LAURENT http://glsft.free.fr
"Jac" <support@ville.blainville.qc.ca> a écrit dans le message de
news:edTa4dfrHHA.4180@TK2MSFTNGP04.phx.gbl
| Bonjour,
Bonsoir,
| j'ai un problème depuis plusieurs semaines que je n'arrive
| pas à régler. Lorsque les usagers se log dans windows xp sp2 desfois
| le process explorer.exe ne roule pas et on ne voit pas aucun icône et
| le taskbar. J'ai essayé plusieurs trucs trouvé sur des forums à ce
| sujet sans succès. J'avais pensé faire un service qui vérifie
| lorsqu'on se log si le process explorer.exe fonctionne ou pas. Si il
| ne fonctionne pas alors on le lance.
Essayez de créer la clé de registre suivante :
HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogon
AutoRestartShell REG_DWORD (1)
Cela devrait forcer le redémarrage automatique du shell (explorer.exe
par défaut) après incident. Il est cependant indispensable de chercher
la cause du problème ... Je pense que cette clé est toujours valide sous
XP SP2 (à vérifier tout de même)
| j'ai un problème depuis plusieurs semaines que je n'arrive | pas à régler. Lorsque les usagers se log dans windows xp sp2 desfois | le process explorer.exe ne roule pas et on ne voit pas aucun icône et | le taskbar. J'ai essayé plusieurs trucs trouvé sur des forums à ce | sujet sans succès. J'avais pensé faire un service qui vérifie | lorsqu'on se log si le process explorer.exe fonctionne ou pas. Si il | ne fonctionne pas alors on le lance.
Essayez de créer la clé de registre suivante : HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogon AutoRestartShell REG_DWORD (1)
Cela devrait forcer le redémarrage automatique du shell (explorer.exe par défaut) après incident. Il est cependant indispensable de chercher la cause du problème ... Je pense que cette clé est toujours valide sous XP SP2 (à vérifier tout de même)
-- Gilles LAURENT http://glsft.free.fr
M.Claveau
Bonsoir !
En complément de ce qui est été très justement dit, je rappelle, en complément de l'instruction RUN d'AutoIt, l'instruction RUNASSET, qui permet de choisir le compte utilisé pour lancer une application.
Pour plus de détails, voir l'aide en ligne.
-- @-salutations
Michel Claveau
Bonsoir !
En complément de ce qui est été très justement dit, je rappelle, en
complément de l'instruction RUN d'AutoIt, l'instruction RUNASSET, qui
permet de choisir le compte utilisé pour lancer une application.
En complément de ce qui est été très justement dit, je rappelle, en complément de l'instruction RUN d'AutoIt, l'instruction RUNASSET, qui permet de choisir le compte utilisé pour lancer une application.
Pour plus de détails, voir l'aide en ligne.
-- @-salutations
Michel Claveau
moi
Notre ami Gilles LAURENT tapota :
(...)
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
(...)
Bon [soir | jour],
Je n'ai jamais utilisé ça ... mais ça peut servir ... pas uniquement pour un service, d'ailleurs ...
( j'ai qq idées de cas qui rendraient cette technique pratique...)
C'est sans doute un peu "technique" , non ?
HB
Notre ami Gilles LAURENT tapota :
(...)
En utilisant les API Win32 de permutation d'autorité / d'identité
(OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...),
un
service démarré sous l'autorité LocalSystem ou privilégié est en
mesure de lancer un processus sous l'autorité de l'utilisateur
connecté localement.
(...)
Bon [soir | jour],
Je n'ai jamais utilisé ça ...
mais ça peut servir ...
pas uniquement pour un service, d'ailleurs ...
( j'ai qq idées de cas qui rendraient cette technique pratique...)
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
(...)
Bon [soir | jour],
Je n'ai jamais utilisé ça ... mais ça peut servir ... pas uniquement pour un service, d'ailleurs ...
( j'ai qq idées de cas qui rendraient cette technique pratique...)
C'est sans doute un peu "technique" , non ?
HB
Jac
Bonjour Gilles
pouvez-vous me dire comment faire pour utilisé cela
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
Je sais qu'il faut que je trouve le problème mais j'aimerais avoir une solution temporaire pour que les usagers arrête de m'achaler avec ce problème
Merci à tous de votre aide
JF
"Gilles LAURENT" wrote in message news:enxN$
"moi" a écrit dans le message de news: | Salut,
Bonsoir,
|| Si je termine le process "explorer.exe" et que je lance se script, || tout fonctionne à merveille. (...) | | Cela me semble normal : | TU lances le script qui lance, "en ton nom" explorer.exe
Tout à fait !
|| Mais si je démarre le service, le process "explorer.exe" (...) | | est lancé par le service qui tourne sous l'autorité de l'utilisateur | SYSTEM | donc explorer ne tourne pas "pour toi" mais pour "system" | qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Tout à fait !
| Donc l'idée risque de devenir une usine à gaz | puisque cela doit fonctionner pour un utilisateur à priori inconnu | utilisateur dont tu ignore aussi le mot de passe. | Le service ne peut donc pas lancer un processus à la place de | l'utilisateur...
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
| Il me semble plus judicieux de chercher | pourquoi explorer.exe ne se lance pas à l'ouverture de session... | C'est plus que très suspect.
Tout à fait !
-- Gilles LAURENT http://glsft.free.fr
Bonjour Gilles
pouvez-vous me dire comment faire pour utilisé cela
En utilisant les API Win32 de permutation d'autorité / d'identité
(OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un
service démarré sous l'autorité LocalSystem ou privilégié est en mesure
de lancer un processus sous l'autorité de l'utilisateur connecté
localement.
Je sais qu'il faut que je trouve le problème mais j'aimerais avoir une
solution temporaire pour que les usagers arrête de m'achaler avec ce
problème
Merci à tous de votre aide
JF
"Gilles LAURENT" <glsft@free.fr> wrote in message
news:enxN$AgrHHA.2240@TK2MSFTNGP03.phx.gbl...
"moi" <moi@pas.la.ici> a écrit dans le message de
news:eDfdunfrHHA.1168@TK2MSFTNGP03.phx.gbl
| Salut,
Bonsoir,
|| Si je termine le process "explorer.exe" et que je lance se script,
|| tout fonctionne à merveille. (...)
|
| Cela me semble normal :
| TU lances le script qui lance, "en ton nom" explorer.exe
Tout à fait !
|| Mais si je démarre le service, le process "explorer.exe" (...)
|
| est lancé par le service qui tourne sous l'autorité de l'utilisateur
| SYSTEM
| donc explorer ne tourne pas "pour toi" mais pour "system"
| qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Tout à fait !
| Donc l'idée risque de devenir une usine à gaz
| puisque cela doit fonctionner pour un utilisateur à priori inconnu
| utilisateur dont tu ignore aussi le mot de passe.
| Le service ne peut donc pas lancer un processus à la place de
| l'utilisateur...
En utilisant les API Win32 de permutation d'autorité / d'identité
(OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un
service démarré sous l'autorité LocalSystem ou privilégié est en mesure
de lancer un processus sous l'autorité de l'utilisateur connecté
localement.
| Il me semble plus judicieux de chercher
| pourquoi explorer.exe ne se lance pas à l'ouverture de session...
| C'est plus que très suspect.
pouvez-vous me dire comment faire pour utilisé cela
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
Je sais qu'il faut que je trouve le problème mais j'aimerais avoir une solution temporaire pour que les usagers arrête de m'achaler avec ce problème
Merci à tous de votre aide
JF
"Gilles LAURENT" wrote in message news:enxN$
"moi" a écrit dans le message de news: | Salut,
Bonsoir,
|| Si je termine le process "explorer.exe" et que je lance se script, || tout fonctionne à merveille. (...) | | Cela me semble normal : | TU lances le script qui lance, "en ton nom" explorer.exe
Tout à fait !
|| Mais si je démarre le service, le process "explorer.exe" (...) | | est lancé par le service qui tourne sous l'autorité de l'utilisateur | SYSTEM | donc explorer ne tourne pas "pour toi" mais pour "system" | qui n'en a par ailleurs pas besoin et sans doute rien à faire ...
Tout à fait !
| Donc l'idée risque de devenir une usine à gaz | puisque cela doit fonctionner pour un utilisateur à priori inconnu | utilisateur dont tu ignore aussi le mot de passe. | Le service ne peut donc pas lancer un processus à la place de | l'utilisateur...
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
| Il me semble plus judicieux de chercher | pourquoi explorer.exe ne se lance pas à l'ouverture de session... | C'est plus que très suspect.
Tout à fait !
-- Gilles LAURENT http://glsft.free.fr
Jacques Barathon [MS]
"Jac" wrote in message news:
Bonjour Gilles
pouvez-vous me dire comment faire pour utilisé cela
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
Est-ce qu'un simple script d'ouverture de session ne permettrait pas d'effectuer le test - et le cas échéant de lancer le process Explorer - dans le contexte de l'utilisateur qui ouvre la session?
Jacques
"Jac" <support@ville.blainville.qc.ca> wrote in message
news:ehvWTdorHHA.4104@TK2MSFTNGP06.phx.gbl...
Bonjour Gilles
pouvez-vous me dire comment faire pour utilisé cela
En utilisant les API Win32 de permutation d'autorité / d'identité
(OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un
service démarré sous l'autorité LocalSystem ou privilégié est en mesure
de lancer un processus sous l'autorité de l'utilisateur connecté
localement.
Est-ce qu'un simple script d'ouverture de session ne permettrait pas
d'effectuer le test - et le cas échéant de lancer le process Explorer - dans
le contexte de l'utilisateur qui ouvre la session?
pouvez-vous me dire comment faire pour utilisé cela
En utilisant les API Win32 de permutation d'autorité / d'identité (OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser ...), un service démarré sous l'autorité LocalSystem ou privilégié est en mesure de lancer un processus sous l'autorité de l'utilisateur connecté localement.
Est-ce qu'un simple script d'ouverture de session ne permettrait pas d'effectuer le test - et le cas échéant de lancer le process Explorer - dans le contexte de l'utilisateur qui ouvre la session?
Jacques
Gilles LAURENT
"Jacques Barathon [MS]" a écrit dans le message de news:% | Est-ce qu'un simple script d'ouverture de session ne permettrait pas | d'effectuer le test - et le cas échéant de lancer le process Explorer | - dans le contexte de l'utilisateur qui ouvre la session?
Solution pouvant être couplée à un watchdog WMI. Le script d'exemple ci-dessous s'entête à redémarrer la calculatrice (calc.exe) lorsqu'une instance de celle-ci est fermée. Le script doit être lancé sous l'autorité de l'utilisateur connecté via par exemple un script d'ouverture de session (logonscript ou gpo)
+++ Usage > WScript WatchDog.vbs
--- Coupez ici : WatchDog.vbs --- Sub Event_OnObjectReady (o, oAsyncContext) If o.TargetInstance.Name = "calc.exe" Then CreateObject ("WScript.Shell").Run (o.TargetInstance.CommandLine) End If End Sub
Set oWmi = GetObject("winmgmts:") Set oEvent = WScript.CreateObject ("WbemScripting.SWbemSink", "Event_") oWmi.ExecNotificationQueryAsync oEvent, _ "SELECT * FROM __InstanceDeletionEvent WITHIN 1" & _ "WHERE TargetInstance ISA 'Win32_Process'"
' boucle infinie ' tout repose maintenant sur les évènements WMI While True: WScript.Sleep (1000*60): Wend --- Coupez ici : WatchDog.vbs ---
-- Gilles LAURENT http://glsft.free.fr
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de
news:%23B4EogprHHA.1168@TK2MSFTNGP03.phx.gbl
| Est-ce qu'un simple script d'ouverture de session ne permettrait pas
| d'effectuer le test - et le cas échéant de lancer le process Explorer
| - dans le contexte de l'utilisateur qui ouvre la session?
Solution pouvant être couplée à un watchdog WMI. Le script d'exemple
ci-dessous s'entête à redémarrer la calculatrice (calc.exe) lorsqu'une
instance de celle-ci est fermée. Le script doit être lancé sous
l'autorité de l'utilisateur connecté via par exemple un script
d'ouverture de session (logonscript ou gpo)
+++ Usage
> WScript WatchDog.vbs
--- Coupez ici : WatchDog.vbs ---
Sub Event_OnObjectReady (o, oAsyncContext)
If o.TargetInstance.Name = "calc.exe" Then
CreateObject ("WScript.Shell").Run (o.TargetInstance.CommandLine)
End If
End Sub
Set oWmi = GetObject("winmgmts:")
Set oEvent = WScript.CreateObject ("WbemScripting.SWbemSink", "Event_")
oWmi.ExecNotificationQueryAsync oEvent, _
"SELECT * FROM __InstanceDeletionEvent WITHIN 1" & _
"WHERE TargetInstance ISA 'Win32_Process'"
' boucle infinie
' tout repose maintenant sur les évènements WMI
While True: WScript.Sleep (1000*60): Wend
--- Coupez ici : WatchDog.vbs ---
"Jacques Barathon [MS]" a écrit dans le message de news:% | Est-ce qu'un simple script d'ouverture de session ne permettrait pas | d'effectuer le test - et le cas échéant de lancer le process Explorer | - dans le contexte de l'utilisateur qui ouvre la session?
Solution pouvant être couplée à un watchdog WMI. Le script d'exemple ci-dessous s'entête à redémarrer la calculatrice (calc.exe) lorsqu'une instance de celle-ci est fermée. Le script doit être lancé sous l'autorité de l'utilisateur connecté via par exemple un script d'ouverture de session (logonscript ou gpo)
+++ Usage > WScript WatchDog.vbs
--- Coupez ici : WatchDog.vbs --- Sub Event_OnObjectReady (o, oAsyncContext) If o.TargetInstance.Name = "calc.exe" Then CreateObject ("WScript.Shell").Run (o.TargetInstance.CommandLine) End If End Sub
Set oWmi = GetObject("winmgmts:") Set oEvent = WScript.CreateObject ("WbemScripting.SWbemSink", "Event_") oWmi.ExecNotificationQueryAsync oEvent, _ "SELECT * FROM __InstanceDeletionEvent WITHIN 1" & _ "WHERE TargetInstance ISA 'Win32_Process'"
' boucle infinie ' tout repose maintenant sur les évènements WMI While True: WScript.Sleep (1000*60): Wend --- Coupez ici : WatchDog.vbs ---
-- Gilles LAURENT http://glsft.free.fr
Jac
Bonjour Gilles, j'ai mis le code que vous m'avez donné dans un fichier .vbs et rien ne se passe
Merci de m'aider
"Gilles LAURENT" wrote in message news:%
"Jacques Barathon [MS]" a écrit dans le message de news:% | Est-ce qu'un simple script d'ouverture de session ne permettrait pas | d'effectuer le test - et le cas échéant de lancer le process Explorer | - dans le contexte de l'utilisateur qui ouvre la session?
Solution pouvant être couplée à un watchdog WMI. Le script d'exemple ci-dessous s'entête à redémarrer la calculatrice (calc.exe) lorsqu'une instance de celle-ci est fermée. Le script doit être lancé sous l'autorité de l'utilisateur connecté via par exemple un script d'ouverture de session (logonscript ou gpo)
+++ Usage > WScript WatchDog.vbs
--- Coupez ici : WatchDog.vbs --- Sub Event_OnObjectReady (o, oAsyncContext) If o.TargetInstance.Name = "calc.exe" Then CreateObject ("WScript.Shell").Run (o.TargetInstance.CommandLine) End If End Sub
Set oWmi = GetObject("winmgmts:") Set oEvent = WScript.CreateObject ("WbemScripting.SWbemSink", "Event_") oWmi.ExecNotificationQueryAsync oEvent, _ "SELECT * FROM __InstanceDeletionEvent WITHIN 1" & _ "WHERE TargetInstance ISA 'Win32_Process'"
' boucle infinie ' tout repose maintenant sur les évènements WMI While True: WScript.Sleep (1000*60): Wend --- Coupez ici : WatchDog.vbs ---
-- Gilles LAURENT http://glsft.free.fr
Bonjour Gilles, j'ai mis le code que vous m'avez donné dans un fichier .vbs
et rien ne se passe
Merci de m'aider
"Gilles LAURENT" <glsft@free.fr> wrote in message
news:%23mz6R1prHHA.4932@TK2MSFTNGP02.phx.gbl...
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de
news:%23B4EogprHHA.1168@TK2MSFTNGP03.phx.gbl
| Est-ce qu'un simple script d'ouverture de session ne permettrait pas
| d'effectuer le test - et le cas échéant de lancer le process Explorer
| - dans le contexte de l'utilisateur qui ouvre la session?
Solution pouvant être couplée à un watchdog WMI. Le script d'exemple
ci-dessous s'entête à redémarrer la calculatrice (calc.exe) lorsqu'une
instance de celle-ci est fermée. Le script doit être lancé sous
l'autorité de l'utilisateur connecté via par exemple un script
d'ouverture de session (logonscript ou gpo)
+++ Usage
> WScript WatchDog.vbs
--- Coupez ici : WatchDog.vbs ---
Sub Event_OnObjectReady (o, oAsyncContext)
If o.TargetInstance.Name = "calc.exe" Then
CreateObject ("WScript.Shell").Run (o.TargetInstance.CommandLine)
End If
End Sub
Set oWmi = GetObject("winmgmts:")
Set oEvent = WScript.CreateObject ("WbemScripting.SWbemSink", "Event_")
oWmi.ExecNotificationQueryAsync oEvent, _
"SELECT * FROM __InstanceDeletionEvent WITHIN 1" & _
"WHERE TargetInstance ISA 'Win32_Process'"
' boucle infinie
' tout repose maintenant sur les évènements WMI
While True: WScript.Sleep (1000*60): Wend
--- Coupez ici : WatchDog.vbs ---
Bonjour Gilles, j'ai mis le code que vous m'avez donné dans un fichier .vbs et rien ne se passe
Merci de m'aider
"Gilles LAURENT" wrote in message news:%
"Jacques Barathon [MS]" a écrit dans le message de news:% | Est-ce qu'un simple script d'ouverture de session ne permettrait pas | d'effectuer le test - et le cas échéant de lancer le process Explorer | - dans le contexte de l'utilisateur qui ouvre la session?
Solution pouvant être couplée à un watchdog WMI. Le script d'exemple ci-dessous s'entête à redémarrer la calculatrice (calc.exe) lorsqu'une instance de celle-ci est fermée. Le script doit être lancé sous l'autorité de l'utilisateur connecté via par exemple un script d'ouverture de session (logonscript ou gpo)
+++ Usage > WScript WatchDog.vbs
--- Coupez ici : WatchDog.vbs --- Sub Event_OnObjectReady (o, oAsyncContext) If o.TargetInstance.Name = "calc.exe" Then CreateObject ("WScript.Shell").Run (o.TargetInstance.CommandLine) End If End Sub
Set oWmi = GetObject("winmgmts:") Set oEvent = WScript.CreateObject ("WbemScripting.SWbemSink", "Event_") oWmi.ExecNotificationQueryAsync oEvent, _ "SELECT * FROM __InstanceDeletionEvent WITHIN 1" & _ "WHERE TargetInstance ISA 'Win32_Process'"
' boucle infinie ' tout repose maintenant sur les évènements WMI While True: WScript.Sleep (1000*60): Wend --- Coupez ici : WatchDog.vbs ---
-- Gilles LAURENT http://glsft.free.fr
Jacques Barathon [MS]
"Jac" wrote in message news:%
Bonjour Gilles, j'ai mis le code que vous m'avez donné dans un fichier .vbs et rien ne se passe
Le script d'ouverture de session pourrait contenir le code suivant (pas du VBScript, du simple batch comme les aime Michel):
--- test-explorer.cmd --- tasklist /fi "imagename eq explorer.exe" | find "explorer" if errorlevel 1 explorer --- test-explorer.cmd ---
A tester. Il peut y avoir un problème de temporisation, et peut-être devras-tu ajouter une boucle qui ne se termine qu'une fois le process Explorer effectivement lancé.
Jacques
"Jac" <support@ville.blainville.qc.ca> wrote in message
news:%23brX6FsrHHA.500@TK2MSFTNGP02.phx.gbl...
Bonjour Gilles, j'ai mis le code que vous m'avez donné dans un fichier
.vbs et rien ne se passe
Le script d'ouverture de session pourrait contenir le code suivant (pas du
VBScript, du simple batch comme les aime Michel):
--- test-explorer.cmd ---
tasklist /fi "imagename eq explorer.exe" | find "explorer"
if errorlevel 1 explorer
--- test-explorer.cmd ---
A tester. Il peut y avoir un problème de temporisation, et peut-être
devras-tu ajouter une boucle qui ne se termine qu'une fois le process
Explorer effectivement lancé.
Bonjour Gilles, j'ai mis le code que vous m'avez donné dans un fichier .vbs et rien ne se passe
Le script d'ouverture de session pourrait contenir le code suivant (pas du VBScript, du simple batch comme les aime Michel):
--- test-explorer.cmd --- tasklist /fi "imagename eq explorer.exe" | find "explorer" if errorlevel 1 explorer --- test-explorer.cmd ---
A tester. Il peut y avoir un problème de temporisation, et peut-être devras-tu ajouter une boucle qui ne se termine qu'une fois le process Explorer effectivement lancé.
