web-dev-qa-db-fra.com

Le programme ne fonctionne pas correctement en tant que tâche planifiée

Situation

J'ai un script batch qui prépare certains fichiers, exécute un programme (.exe), puis supprime lesdits fichiers.

Cette tâche doit s'exécuter toutes les heures, j'essaie donc de la configurer à l'aide de tâches planifiées. Le problème est que le programme mentionné précédemment ne s'exécute pas correctement lorsqu'il est appelé à partir de la tâche (ni via le .bat script, ni lors de l'appel du .exe directement), mais je ne reçois aucun avertissement ni message d'erreur dans les journaux.

Installer

La tâche est configurée pour s'exécuter en tant que compte de service Windows disposant de tous les privilèges correctement définis. Lorsque j'utilise ce compte pour me connecter via RDP, je peux exécuter le .bat et .exe directement sans problème, mais la tâche semble toujours ne rien faire. Ceci est facilement observé car le programme toujours modifie un fichier, et modifié sur l'horodatage ne change pas à travers la tâche.

Dans les journaux des tâches planifiées, j'obtiens les messages d'information pour la tâche qui démarre un processus, se termine, etc. Le "code de résultat", cependant, est 111 (j'ai essayé de Google sans succès, la seule association que j'obtiens est "le nom de fichier est trop long", ce qui n'est tout simplement pas pertinent AFAIK). Dans les journaux d'application, je ne reçois absolument rien.

Ce que je soupçonne, c'est le problème

Le programme est une ancienne monstruosité qui génère une sorte d'écran de démarrage (c'est en fait une fenêtre normale), même si l'interface graphique n'est pas nécessaire car elle ne nécessite aucune interaction et se ferme après les opérations. La fenêtre apparaît pendant environ 2 secondes.

Je soupçonne que cette exigence d'interface graphique a quelque chose à voir avec l'échec de la tâche, mais je ne suis pas sûr. Lorsque je me connecte avec l'utilisateur sous lequel la tâche s'exécute (via RDP), aucune fenêtre n'apparaît lorsque je démarre la tâche planifiée.

Modifier sur l'interface graphique

J'ai construit un très petit exécutable C # qui lance le programme sans la fenêtre principale (en utilisant ProcessStartInfo.WindowStyle = ProcessWindowStyle.Hidden). Même de cette façon, la tâche planifiée ne réussit toujours pas à lancer le programme correctement, mais le code retour est maintenant 0.

Mise à jour

Lorsque je configure la tâche pour dire "exécuter, que l'utilisateur soit connecté ou non", et le run with highest privileges l'option est non cochée, la valeur d'erreur est 2147943859.

Que puis-je faire pour dépanner?

OS = Windows Server 2008 R2 SP1

Si plus d'informations sont nécessaires, veuillez me le faire savoir dans les commentaires.

windows-server-2008-r2scheduled-tasktroubleshootingbatch
12
MarioDS

Les gars de l'entreprise qui gère les serveurs de nos clients ont déclaré qu'un programme GUI ne s'exécuterait pas via des tâches planifiées de quelque manière que ce soit.

Ils utilisent un système de surveillance qui dispose également de fonctionnalités de planification des tâches. Ils l'ont mis en place grâce à cela et cela semble fonctionner.

Désolé de ne pas avoir eu la chance d'évaluer plus de suggestions ici, mais merci d'avoir essayé de toute façon. J'espère que cela pourra aider d'autres à l'avenir, ce que je pense certainement.

1
MarioDS

Je crois que votre problème est lié soit aux autorisations du compte utilisé pour exécuter la tâche, soit au contexte du compte tel qu'il existe lorsque vous essayez d'exécuter la tâche.

Test de l'exigence de session de console

Il est possible que votre . EXE doit être exécuté dans la session Console (alias Session 0) sur l'ordinateur. Pour tester cela:

  1. Configurez la tâche pour Exécuter uniquement lorsque l'utilisateur est connecté et spécifiez une heure de début de tâche de 2 minutes à l'avenir
  2. Connectez-vous à la machine avec le même compte d'utilisateur que celui utilisé pour exécuter la tâche (de préférence, connectez-vous à la session de console, soit en étant physiquement sur la console, soit en utilisant un programme d'accès à distance qui donne accès à la console. Pour confirmer que vous utilisez le session de console, à partir d'une invite de commandes exécutez QWINSTA, observez la colonne SESSIONNAME et confirmez > l'indicateur est à côté de console, en d'autres termes, il doit apparaître comme >console)
  3. Attendez que la tâche s'exécute

Si la tâche s'exécute correctement, essayez de planifier la tâche avec SCHTASKS.EXE en utilisant le /IT paramètre. A défaut, vous pouvez n'avoir d'autre choix que de configurer l'ordinateur pour qu'il se connecte automatiquement en tant que compte d'utilisateur de service et exécute la tâche en tant que programme de démarrage.

Vérifier les autorisations

De plus, comme je l'ai déjà suggéré, vérifiez les points suivants pour confirmer que le compte utilisé pour exécuter la tâche est correctement autorisé:

  1. Accordez au compte le droit d'utilisateur Ouverture de session en tant que tâche par lots (trouvé dans la stratégie de groupe locale à Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignments)
  2. Confirmez que la tâche est configurée pour Exécuter avec les privilèges les plus élevés
  3. Confirmez que l'utilisateur dispose d'autorisations NTFS complètes sur tous les dossiers et fichiers avec lesquels il doit interagir. Ne faites aucune hypothèse; confirmez à la place en naviguant vers ces emplacements de fichiers et en utilisant le Effective Permissions onglet dans les propriétés du fichier/dossier à Security > Advanced

Autres choses à vérifier/essayer

  • La tâche nécessite-t-elle un accès pour accéder aux ressources réseau? Des éléments tels que les lecteurs mappés peuvent être présents lorsque vous vous connectez avec le compte d'utilisateur, mais selon la configuration du serveur peut ne pas être présent dans le contexte du compte d'utilisateur lorsqu'il est exécuté à partir du Planificateur de tâches.

  • Ajoutez une journalisation à votre fichier de commandes. Après chaque ligne qu'il exécute, faites-lui écrire une sortie dans un fichier journal afin que vous sachiez où il se bloque. Par exemple:

    @echo off
echo Line 1 >> "C:\MyLog.txt"
"C:\My Folder\myOldProgram.exe"
echo Line 2 >> "C:\MyLog.txt"
DEL somefile.dat
echo Line 3 >> "C:\MyLog.txt"

  • Essayez d'exécuter votre . EXE avec START, par exemple START "myTitle" "C:\full\path\to\my.EXE"

6
I say Reinstate Monica

Je réponds à un ancien message au cas où cela aiderait quelqu'un d'autre. J'ai eu le même problème. Le journal des événements indique que le programme s'est terminé normalement, mais même la première ligne de code n'écrirait pas pour moi dans le journal. Il a fini par être l'option "Démarrer dans" dans le Planificateur de tâches. Il m'est venu à l'esprit que le programme fonctionnait bien à partir de la ligne de commande lorsque j'étais dans le répertoire actuel. Il existe des fichiers manifestes et d'autres dépendances dans le même répertoire. Par conséquent, si vous indiquez au travail planifié de démarrer dans le même répertoire que l'EXE, vous pouvez obtenir des résultats favorables. C'était la solution pour moi.

2
Rob Wilson

peut-être que cela vous aide?

https://stackoverflow.com/questions/6939548/a-workaround-for-the-fact-that-a-scheduled-task-in-windows-requires-a-user-to-be

Nous avons eu un problème similaire et votre seule solution était de créer un compte spécial sur le serveur avec la connexion automatique. Donc, si la tâche s'est déroulée sous l'utilisateur déjà connecté, notre .exe a bien fonctionné ...

je sais que ce n'est pas une très bonne solution mais pour nous, c'est la seule chose qui a fonctionné. je ne sais pas si cela fonctionne pour vous ... (Mais avec ce travail, vous devez vérifier si l'utilisateur est vraiment connecté tout le temps ...)

1
frupfrup

J'essayais de démarrer et l'ancien programme VB6 en utilisant le planificateur de tâches sur un serveur Windows 2008 R2. L'application s'exécuterait à partir de l'exe, via un fichier de commandes ou en cliquant sur un raccourci, mais ne s'exécuterait pas à partir du planificateur de tâches. J'ai constaté que lorsque les fichiers de configuration de l'application, qui étaient stockés dans le dossier applications du répertoire C:\program files (x86), étaient copiés dans le dossier d'application sur c:\programdata. l'ordonnanceur a fonctionné. il semble que cmd.exe applique la configuration à partir d'un emplacement différent de celui utilisé par le planificateur de tâches. Si votre application possède des fichiers de configuration, vous pouvez essayer de les déplacer vers le dossier c:\programdata\application.

1
Kasa

Peut-être que la réponse à cette question aidera quelqu'un d'autre à lire ce fil?

https://stackoverflow.com/questions/32589381/

Résumé: Les tâches planifiées de Windows 2012 font pas voir les variables d'environnement correctes, y compris PATH, pour le compte sous lequel la tâche doit être exécutée.

J'ai lu tout cela assez longtemps avant de travailler sur ce qui précède. (Ce qui était mon propre problème menant à la même chose que la question du PO.)

Une fois que vous (enfin!) Le savez, il est assez facile de le tester (selon la réponse stackoverflow), de le voir se produire et de le contourner ....

0
MikeBeaton

Faites-vous référence à des lecteurs réseau mappés dans votre script ou programme? J'ai eu un problème similaire il y a quelque temps, où ma tâche planifiée ne s'exécuterait pas, et je ne pouvais pas comprendre pourquoi. Le changement de chemin (s) en chemins UNC l'a résolu pour moi.

Changement T:\Apps\MyProgram.exe à \\MyServer\MyShare\Apps\MyProgram.exe

0
AdamsTips

Lorsque je configure la tâche pour dire "exécuter, que l'utilisateur soit connecté ou non" et que l'option d'exécution avec les privilèges les plus élevés ne soit pas cochée, la valeur d'erreur est 2147943859.

2147943859 converti en hexadécimal est 800705b3 qui, selon un bref voyage vers Google, signifie "Impossible de démarrer le programme d'installation sur l'ordinateur. Cette opération nécessite une station Windows interactive".

Maintenant, il peut y avoir un moyen de le faire fonctionner de manière interactive sans utiliser PSEXEC (de Sysinternals) mais comme je sais déjà comment le faire via PSEXEC, c'est ce que j'utiliserais.

PSExec: http://technet.Microsoft.com/en-us/sysinternals/bb897553.aspx

Par conséquent, modifiez votre action pour tout ajouter au début avec psexec.exe -i (et -h si vous en avez besoin élevé) et cela devrait fonctionner.

J'ai essayé cela sur Windows Server 2008 R2 SP1 avec ce qui suit dans mon "action":

c:\windows\system32\cmd.exe

puis les paramètres:

/c psexec.exe -h -i notepad.exe

Lorsque j'exécute manuellement la tâche (car je ne l'ai pas planifiée), j'obtiens un bloc-notes élevé en cours d'exécution dans ma session actuelle.

0
Mark Allen