Я использую Windows Server 2003, и у меня есть запланированная задача, которую не удается выполнить. Задача настроена на запуск командного сценария Windows (.cmd) в 15:00 каждый день. Сценарий запускает программу, которая извлекает некоторые данные из базы данных SQL Server и загружает эти данные на FTP-сервер.
Код ошибки, отображаемый в столбце «Последний результат» папки запланированных задач, - 0xc000013a. Быстрый поиск в Google приводит к эта страница поддержки Microsoft который гласит: Наиболее распространенный код ошибки «C» - «0xC000013A: приложение завершено в результате нажатия CTRL + C».
Во время выполнения задачи никто не входит в систему, поэтому никого нет, чтобы нажать CTRL + C. Я не уверен, что понимаю, о чем здесь говорится в документации Microsoft.
Я проверил элементарные вещи - запланированная задача включена, запускается каждый день и указывает на файл, который действительно существует в допустимом месте. Интересно, что когда я запускаю эту задачу вручную (либо путем запуска сценария .cmd из командной строки, либо путем щелчка правой кнопкой мыши по задаче и нажатия «Выполнить»), задача успешно завершается.
Что означает этот код ошибки и как я могу запустить эту задачу, когда меня нет на месте, чтобы заставить ее выполнить?
Устранение неполадок запланированных скриптов:
Если вы еще этого не сделали, проверьте Дела по расписанию файл журнала в графическом интерфейсе под Продвинутый > Посмотреть журнал. Найдите в файле "***
", чтобы найти самые последние записи, и вы можете увидеть небольшую дополнительную информацию об ошибке.
Определите файл журнала для записи вывода и отправьте туда как стандартный вывод, так и стандартную ошибку. Изменить любой эхо выключено к эхо ВКЛ чтобы убедиться, что вы не скрываете никаких сообщений об ошибках.
Например, если ваш скрипт называется ftp.data.cmd
тогда ваша запланированная задача может выглядеть так,
cmd /c ftp.data.cmd >> ftp.data.log 2>&1
Скрипт висит? Возможно, планировщик задач убивает скрипт (отсюда и код ошибки CTRL + C) через определенный период времени. Добавьте некоторые из них в стратегические точки вашего сценария,
echo %DATE% %TIME%
Вы уверены, что учетная запись, на которой запущен сценарий, имеет разрешения / доступ ко всему в сценарии?
Если вы не можете получить какую-либо радость, запустите эту команду и опубликуйте результат здесь, может быть, мы можем начать с планирования,
schtasks /query /v /fo LIST /s YOURSERVER
Я не могу ответить на этот вопрос напрямую, поскольку я не знаю конкретно, что означает сообщение об ошибке (и, следовательно, как его исправить), но если бы я пытался устранить его, я бы добавил несколько записей в файл журнала на стратегические точки в сценарии, а затем по истечении запланированного времени посмотрите, какая контрольная точка будет запущена последней.
Я подозреваю, что что-то выходит из строя из-за учетных данных, под которыми работает скрипт, или что-то в скрипте требует авторизованного пользователя. Уточнение того, где в скрипте что-то не получается, может помочь вам найти "оскорбительный" код.
Я понимаю, что это старый пост, но он очень полезен при поиске решений, и, возможно, то, что я нашел, тоже может быть полезным. Я использовал WinSCP на Windows Server 2003 для загрузки на ftp-сервер и получил то же сообщение об ошибке, а файл SchedLgU.txt указал на недостаточное время в разделе «Остановить задачу, если она предоставлена:», хотя я дал задачу достаточно времени для загрузки.
Заглянув в диспетчер задач, я увидел, что WinSCP.exe не очищается, и у меня было множество процессов в списке, поэтому я создал командный файл (taskkill / f / im winscp.exe), чтобы убить любой открытый процесс, и я запустите этот командный файл до WinSCP, и теперь он работает хорошо.
Я столкнулся с этим сегодня на удаленном сервере, и решение состояло в том, чтобы изменить настройку запуска с «Запускать только при входе пользователя в систему» на «Запускать независимо от того, находится ли пользователь в системе или нет».
С «Запускать, только когда пользователь вошел в систему» задача запускает командное окно, которое было закрыто по истечении времени ожидания сеанса удаленного рабочего стола. При выборе «Запускать вне зависимости от того, вошел ли пользователь в систему или нет» во время выполнения задачи окно не отображается, поэтому выполнение не останавливается по завершении сеанса удаленного рабочего стола.
Подобно ответу Кори, я бы порекомендовал вам проверить, от кого настроена запланированная задача, поскольку я видел, что эта ошибка возникает, когда учетная запись пользователя, которая запускает задачу, не имеет тех же разрешений, что и вошедший в систему пользователь
Если это выполнялось раньше, возможно, причиной сбоя может быть отказ сети или проблема на другом узле.
У меня была такая же ошибка, потому что командный файл, который я запускал, предлагал удалить некоторые файлы с помощью команды DEL. Поскольку нет пользователя, который ответил бы «да / нет» на пакетный процесс, запланированная задача завершается. В журнале запланированных задач я обнаружил следующее сообщение: «задача была завершена. Это действие было инициировано администратором или службой планировщика задач (например, потому что компьютер теперь не находится в режиме ожидания)». Я рекомендую запустить задачу вручную из командной строки, чтобы увидеть, где она останавливается или запрашивает какое-либо взаимодействие с пользователем, исправьте это, и ваша задача будет работать нормально.
Если вы пытаетесь запустить программу под управлением планировщика заданий, System.Environment.CurrentDirectory вернет C: \ Windows \ System32, а НЕ то место, где находится ваш исполняемый файл. Эта ошибка может быть ошибкой «файл не найден»; Я пытался войти в подкаталог, но его не было в дереве System32.
По моим сценариям это ясно. Это происходит из-за того, что у меня есть «пауза» в конце командного файла, а запланированное задание ограничено 20 минутами. Когда пользователь присутствует, он может видеть ход выполнения задания. Когда нет, командный файл завершается запланированной задачей через 20 мин. Это вызывает 0xc000013a, и это нормально.
У меня была такая же проблема, и я исправил ее, изменив триггер с «При запуске системы» на «При входе в систему».
была та же проблема .. исправлена игрой с пользователем, который зарегистрирован для запуска запланированной задачи. в конце концов, ответом стала смена домена.