Question [Resolu]surveiller un exe si il crash

Dis, peut-être que je trouverais la réponse dans le livre que j'ai commandé \"Windows PowerShell - Fonctionnalités avancées\", tu sais si les auteurs en parle ?

C'est possible en effet... Lol !

Pour info, le chapitre 5 est consacré aux \"Travaux en arrière-plan\"...

Arnaud

Arnaud écrit:

Moi instinctivement j'essaierai de créer un job

La fenêtre de reporting d'erreur reste un pb, on isole juste l'exécution, mais en cas de crash le job reste 'running' tant que la fenêtre de reporting existe.
La fenêtre de reporting d'erreur est un process enfant (nommé 'dw20.exe') du process en cause et est créé par l'OS.
tonic8 écrit:

2/ surveiller la fenetre popup et la killer car le script attend quelle soit fermer pour passer al a boucle suivante
si je fais un start-job je peux lui mettre un timing? chaque tnsping prend entre 8-20s, si je dis au bout de 60s arrete la tache (donc kill du process et des enfants lancé dans le startjob) en retournant une erreur, je peux traiter.

On peut faute de temps prendre cette direction, pas certains que ce soit la bonne.

En cherchant un peu, Disabling Windows Error Reporting(AppCrash) dialog programmatically , mais je n'ai pas réussi un créer un launcher qui résolve ce problème.
Exclure une application du reporting (API WerAddExcludedApplication), pas mieux pour l'instant. Et l'eventwiever ne semble plus renseigné.

Configurer Windows Error Reporting (WER) :
[code:1]HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting\ForceQueue = 1[/code:1]
La fenêtre n'est plus affichée. L'eventwiever est tjrs renseigné.

Je pense qu'il faut étudier de plus près cette approche.
Il existe une liste d'exclusion :
[code:1]HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting\ExcludedApplications
[/code:1]

Mais pour le moment cela ne donne change rien, ni celle-ci :
[code:1]HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList
[/code:1]

Il y a un fenêtre pour le reporting et le debug et une autre pour le debug uniquement.<br><br>Message édité par: Laurent Dardenne, à: 7/04/15 14:20

Moi instinctivement j'essaierai de créer un job...

La fenêtre de reporting d'erreur reste un pb, on isole juste l'exécution, mais en cas de crash le job reste 'running' tant que la fenêtre de reporting existe.

Oui certes, mais l'avantage d'isoler ainsi l'exécution est que nous sommes capables de savoir depuis combien de temps le job s'exécute. Du coup s'il s'exécute depuis, disons, 5 minutes c'est qu'il est probablement planté. Du coup on peut se dire qu'il faut tuer le job.

Reste maintenant à savoir si en tuant le job, cela tue également la fenêtre de reporting du crash...

Arnaud

Donc si le tnsping crash, le $LastExitCode devrait etre au mieux à 1 au pire vide...
* comment m'assurer que la valeur du lastexit correspond bien a la sortie de mon tnsping et pas d'une autre commande precedente?

Facile ! Car la variable $LASTEXITCODE ne contient que le code de retour des exécutables Windows, pas des commandelettes PowerShell .

Dans l'idéal, il faut tester la valeur de cette variable juste après l'appel à ton exécutable Win32.

Arnaud