2009-05-14 4 views
6

Dans le processus de déploiement de notre application .net, j'ai environ 20 tâches planifiées sur un serveur, qui font essentiellement la même chose: invoquer une petite application console .net qui tire les données d'un db SQL et le poste sur un service Web. Chaque tâche appelle une copie distincte de l'application, chaque copie ayant une valeur d'ID de recherche différente dans son fichier de configuration.Comment faire pour résoudre Windows tâche planifiée ne fonctionne pas?

Toutes ces tâches sauf deux fonctionnent de manière fiable chaque nuit. Deux des tâches semblent cesser sporadiquement de courir de temps en temps, et c'est actuellement un mystère pour savoir pourquoi. Lorsqu'ils s'arrêtent, l'interface de tâche planifiée affiche correctement leur dernière date d'exécution, soit un jour ou plus par rapport aux autres tâches, qui ont continué à s'exécuter à l'heure planifiée. Les tâches qui ont cessé de fonctionner ne s'exécutent pas toutes seules, bien qu'elles soient indiquées comme programmées pour s'exécuter toutes les nuits. Aucune erreur n'est enregistrée dans le journal des événements ou dans l'interface de tâche planifiée elle-même. Et voici la partie la plus étrange pour nous: Si je démarre manuellement la tâche planifiée, il fonctionne bien, il appelle l'application console .net et tout se termine sans anomalie. Et puis il continue à fonctionner correctement à l'heure prévue, pendant des jours ou des semaines à la fois, pour finalement échouer, apparemment à l'improviste. Il semble que les deux tâches commencent toujours à échouer le même soir.

+1

Je pense que la réponse à cette question http://stackoverflow.com/questions/32589381/ pourrait également aider certaines personnes à expliquer pourquoi les tâches qui s'exécutent manuellement ne s'exécutent pas toujours dans les temps. (Mais de la façon dont ils sont décrits, ce ne sont pas des questions en double.) Résumé: Les tâches planifiées de Windows 2012 ne voient pas toujours les variables d'environnement correctes, y compris 'PATH', pour le compte sur lequel la tâche est exécutée; en fait, ils ne voient que l'ensemble correct des variables alors que l'utilisateur de la tâche est réellement connecté. –

Répondre

7

Il y a une colonne "Dernier résultat" qui devrait vous donner un code lié à la tâche elle-même en cours d'exécution (il n'y aura pas de données d'exception). 0 signifie que la tâche est terminée sans erreur. Rien d'autre que vous pouvez rechercher et voir pourquoi la tâche ne démarre pas. Si la tâche semble toujours ne pas être en cours d'exécution, mais que vous voyez toujours un 0 pour le dernier résultat, cela signifie qu'il y a quelque chose de cassé dans votre code, mais il se termine gracieusement.

0

Peut-être qu'ils pendaient et étaient toujours en cours d'exécution?

Vous pouvez cliquer sur le bonus-menu et choisissez l'entrée de menu pour afficher le journal, le Bloc-notes ouvre un fichier journal du planificateur de tâches

1

L'une des raisons pour les tâches planifiées ne fonctionne pas se produit lorsque les associant à un compte d'utilisateur Windows sans mot de passe: par défaut, les tâches planifiées ne peuvent pas être exécutées avec un mot de passe vide. Si vous souhaitez exécuter une tâche planifiée à partir d'un compte sans mot de passe que vous devez désactiver une variable système:

  • Aller à: Démarrer> Outils d'administration> Stratégie de sécurité locale> Paramètres de sécurité> Stratégies locales> Options de sécurité
  • Sélectionner: « comptes: limiter l'utilisation du compte local des mots de passe vides à ouverture de session console »
  • Désactiver cette variable

Avertissement: C'EST pas recommandé d'avoir des comptes sans mot de passe.

3

TaskScheduler suppose sur les systèmes 64 bits que l'applicaiton est de 64 bits. S'il s'agit d'un 32 bits, lancez-le à partir de la ligne de commande 32 bits, c'est-à-dire si vous voulez exécuter c: \ program files (x86) \ Myprogram \ Program.exe, dites TaskScheduler lancer:

  • % systemroot% \ SysWOW64 \ cmd.exe/C "c: \ program files (x86) \ MyProgram \ Program.exe"

Cela oblige à lancer à partir de l'invite de commande 32 bits et donc avec une émulation 32 bits.

+0

Merci, je pense que le silence a été résolu. – fatihpense

3

Avez-vous défini la propriété "Démarrer"? Si ces applications console .NET ont besoin d'app.config ou de fichiers situés dans leur chemin, vous devez définir la propriété "Démarrer" sur "c: \ votre \ app \ chemin \, sinon elles démarrent comme si elles étaient dans le répertoire système, et ils ne peuvent pas trouver les fichiers dont ils ont besoin

0

La réponse à la question SO ci-dessous peut également être très pertinente pour les personnes lisant cette question (mais, NB, il décrit seulement un problème possible avec Scheduled Tâches et je crois qu'aucune de ces questions n'est une copie de l'autre):

Why is my Scheduled Task updating its 'Last Run Time' correctly, and giving a 'Last Run Result' of '(0x0)', but still not actually working?

Le résumé de la réponse à cette autre question est que les tâches planifiées de Windows 2012 ne voient pas les variables d'environnement correctes, y compris PATH, pour le compte sur lequel la tâche est définie. En ce qui concerne le dépannage de tâches planifiées plus général (comme demandé dans cette question), vous pouvez tester ce problème particulier (par exemple, exécuter SET > test.txt dans la tâche, comme suggéré dans cette réponse), et une fois que vous pouvez le voir se produire , vous pouvez contourner cela si cela vous affecte.

0

Dans mon cas, la tâche planifiée ne s'exécuterait pas même si elle indiquait que la dernière exécution avait réussi (0). Il s'est avéré que le compte d'utilisateur Windows qui exécutait les tâches était devenu verrouillé. J'ai seulement réalisé ceci parce que j'ai essayé éditer la tâche programmée existante, ai placé le compte d'utilisateur au même, alors le coup OK et il m'a donné une erreur au sujet du compte étant verrouillé.