Заплановане завдання Windows не вдалося виконати з кодом помилки 0xc000013a

Я використовую Windows Server 2003 і маю планове завдання, яке не вдалося виконати. Поставлено завдання запускати командний скрипт Windows (.cmd) о 15:00 щодня. Сценарій запускає програму, яка витягує деякі дані з бази даних SQL Server і завантажує ці дані на FTP-сервер.

Код помилки, відображений у стовпці "Останній результат" в папці запланованих завдань, становить 0xc000013a. Швидкий пошук Google приводить до цієї сторінки підтримки Microsoft, де зазначено: Найпоширеніший код помилки "C" - "0xC000013A: Програма припинена внаслідок CTRL + C".

Ніхто не входить у систему під час виконання завдання, тому навколо немає кому натискати CTRL + C. Я не впевнений, що розумію, про що йдеться в документації Microsoft.

Я перевірив рудиментарні речі - заплановане завдання ввімкнено, його потрібно виконувати щодня і вказувати на файл, який існує у дійсному місці. Цікаво, що коли я запускаю це завдання вручну (або запустивши скрипт .cmd з командного рядка, або клацаючи правою кнопкою миші та натиснувши «Виконати») завдання успішно завершується.

Що означає цей код помилки, і як я можу змусити цю задачу виконувати, коли мене немає, щоб змусити її?

Усунення несправностей із запланованими сценаріями:

1. Якщо ви ще цього не зробили, перевірте файл журналу запланованих завдань у графічному інтерфейсі в розділі Додатково > Переглянути журнал . Шукайте у файлі " ***", щоб знайти останні записи, і, можливо, ви побачите трохи додаткової інформації про помилку.

2. Визначте файл журналу для збору результатів і надішліть туди і стандартну, і стандартну помилку. Змініть будь-яке відлучення вимкнено, щоб відлучити його, щоб переконатися, що ви не подавляєте жодних повідомлень про помилки.
   Наприклад, якщо ваш скрипт викликається, ftp.data.cmdто ваше заплановане завдання може виглядати так,

   cmd /c ftp.data.cmd >> ftp.data.log 2>&1

3. Чи висить сценарій? Можливо, планувальник завдань вбиває скрипт (звідси код помилки CTRL + C) через деякий визначений проміжок часу. Додайте деякі з них у стратегічні моменти вашого наука,

   echo %DATE% %TIME%

4. Ви впевнені, що в обліковому записі, де працює сценарій, є дозволи / доступ до всього сценарію?

5. Якщо ви не можете отримати будь-якої радості, запустіть цю команду та опублікуйте висновок тут, можливо, ми можемо почати з планування,

   schtasks /query /v /fo LIST /s YOURSERVER

Я не можу відповісти на питання безпосередньо, оскільки не знаю конкретно, що означає повідомлення про помилку (а отже, як її виправити), але якби я намагався його усунути, я додав би кілька записів у файл журналу на стратегічні точки в сценарії, а потім після запланованого часу подивіться, що є останнім контрольним пунктом для запуску.

Я підозрюю, що щось не вдається через облікові дані, під якими працює сценарій, або те, що в скрипті потребує зареєстрований користувач. Звуження, де в сценарії речі не вдається, може допомогти вам знайти "ображаючий" код.

Я усвідомлюю, що це стара публікація, але вони дуже корисні при пошуку рішень, і, можливо, те, що я знайшов, може бути корисним також. Я використовував WinSCP на Windows Server 2003 для завантаження на ftp-сервер і отримав те саме повідомлення про помилку, і файл SchedLgU.txt вказав на недостатньо часу в розділі "Зупинити завдання, якщо він надає для:", хоча я дав завдання достатньо часу для завантаження.

Заглянувши в диспетчер завдань, я міг побачити, що WinSCP.exe не очищав, і у мене було багато процесів у списку, тому я створив пакетний файл (taskkill / f / im wincp.exe), щоб вбити будь-який відкритий процес, і я запустити цей пакетний файл до WinSCP, і він працює добре зараз.

Я зіткнувся з цим сьогодні на віддаленому сервері, і рішенням було змінити налаштування запуску з "Запустити лише тоді, коли користувач увійшов" на "Запустити, чи користувач увійшов чи ні".

Завдяки "Запустити лише тоді, коли користувач зареєстрований" завдання запускає вікно команд, яке було закрите, коли час мого сеансу віддаленого робочого столу закінчився. З "Запустити, чи користувач увійшов чи ні", під час виконання завдання не відображається вікно, тому виконання не припиняється, коли закінчується сеанс мого віддаленого робочого столу.

Як і у відповіді cori, я рекомендую вам перевірити, для кого встановлено заплановану задачу, оскільки я бачив, що ця помилка виникає, коли обліковий запис користувача, який виконує завдання, не має тих самих прав, що й зареєстрований користувач

Якщо це запускалося раніше, можливо, такий стан, як відключення мережі чи проблема іншого хазяїна, може пояснити збій.

У мене була така ж помилка, і це було через те, що пакетний файл, який я працював, запропонував видалити деякі файли командою DEL. Оскільки немає жодного користувача, який би відповів "Так / Ні" на пакетний процес, заплановане завдання припиняється. Далі йде повідомлення, яке я знайшов у своєму журналі запланованих завдань: "завдання було припинено. Цю дію було ініційовано або адміністратором, або службою планувальника завдань (оскільки, наприклад, комп'ютер зараз не працює)." Моя рекомендація - запустити завдання вручну з командного рядка, щоб побачити, де воно зупиняється або спонукає до якоїсь взаємодії з користувачем, виправте його, і ваше завдання буде нормально працювати.

Якщо ви намагаєтеся запустити програму під керуванням планувальника завдань, System.Environment.CurrentDirectory поверне C: \ Windows \ System32, а не там, де знаходиться ваш виконуваний файл. Ця помилка може бути помилкою, яку не знайдено у файлі; Я намагався увійти до підкаталогу, і він не існував у дереві System32.

За моїми сценаріями це зрозуміло. Це трапляється тому, що у мене "пауза" в кінці пакетного файлу, а заплановане завдання обмежується 20 хвилин. Коли користувач присутній, привіт може побачити потік завдання. Якщо пакетний файл не закінчується плановим завданням, через 20 хв. Це викликає 0xc000013a, і це нормально.

У мене була така ж проблема і виправлено її, змінивши тригер з "При запуску системи" на "При вході".

була така ж проблема .. Виправлена, граючи з користувачем, який зареєстрований для виконання запланованого завдання. врешті-решт, зміна домену стала відповіддю.