web-dev-qa-db-fra.com

Mon application C # renvoie 0xE0434352 au planificateur de tâches Windows mais ne se bloque pas.

J'ai écrit quelques applications C # exécutées via le planificateur de tâches Windows. Ils fonctionnent correctement (comme le montrent les fichiers journaux en cours d’écriture), mais le planificateur de tâches Windows leur indique de renvoyer le résultat de la dernière exécution de 0xE0434352. Dois-je effectuer quelque chose dans mon application C # pour renvoyer un code de réussite au planificateur de tâches Windows?

64
Kynrek

Une autre option consiste simplement à utiliser le journal des applications accessible via l'afficheur d'événements Windows. L'erreur .Net sera enregistrée dans le journal des applications.

78
voidmain

Lorsque vous configurez un travail dans de nouvelles fenêtres, vous disposez de deux champs "programme/script" et "Démarrer dans (facultatif)". Mettez le nom du programme en premier et son emplacement en second. Si vous ne le faites pas et que votre programme ne démarre pas dans le répertoire exe, il ne trouvera pas les fichiers qui s'y trouvent.

32
Dmitry Bosikov

Hans Passant était correct, j'ai ajouté un gestionnaire pour AppDomain.CurrentDomain.UnhandledException comme décrit ici http://msdn.Microsoft.com/en-us/library/system.appdomain.unhandledexception (v = vs.71) .aspx J'ai pu trouver l'exception qui se produisait et la corriger.

23
Kynrek

Je faisais référence à un lecteur mappé et j'ai constaté que les lecteurs mappés ne sont pas toujours disponibles pour le compte d'utilisateur qui exécute la tâche planifiée. J'ai donc utilisé \\IPADDRESS au lieu de MAPDRIVELETTER: et Je suis opérationnel.

12
RandyMorris

Au cas où cela aiderait les autres, j’ai eu cette erreur lorsque le service sur lequel la tâche était exécutée n’avait pas l’autorisation d’écriture sur l’emplacement exécutable. Il essayait d'écrire un fichier journal à cet endroit.

7
MDave

J'avais ce problème et c'était dû à la version du framework .Net. J'avais mis à niveau le build vers le framework 4.0 mais cela semblait affecter certaines DLL de communication utilisées par l'application. Je suis revenu au framework 3.5 et cela a bien fonctionné.

2
user3936738

J'ai la même erreur mais je l'ai corrigée en changeant le chemin de lecture du fichier de "ConfigFile.xml" en AppDomain.CurrentDomain.BaseDirectory.ToString () + "ConfigFile.xml"

Dans mon cas, cette erreur est due à une erreur de chemin de fichier car le gestionnaire de tâches démarre le programme à partir de "System32" comme chemin initial, mais dans le dossier que nous pensions.

1
RUTIS

Je recevais le même message dans dotNet Core 2.2 en utilisant MVC 5, mais rien n’était enregistré dans l’Observateur d’événements Windows.

J'ai constaté que j'avais modifié le sdk du projet de Microsoft.NET.Sdk.Web à Microsoft.NET.Sdk.Razor (visible dans le fichier projects.csproj). J'ai changé ça et ça a bien fonctionné :)

1
MrBritton