Zaplanowane zadanie systemu Windows nie kończy się z kodem błędu 0xc000013a

Korzystam z systemu Windows Server 2003 i mam zaplanowane zadanie, które się nie kończy. Zadaniem jest uruchamianie skryptu poleceń systemu Windows (.cmd) o godzinie 15:00 każdego dnia. Skrypt uruchamia program, który wyodrębnia niektóre dane z bazy danych SQL Server i przesyła te dane na serwer FTP.

Kod błędu wyświetlany w kolumnie „Ostatni wynik” w folderze zaplanowanych zadań to 0xc000013a. Szybkie wyszukiwanie Google prowadzi do strony pomocy technicznej Microsoft, która stwierdza: Najczęstszym kodem błędu „C” jest „0xC000013A: Aplikacja została zakończona z powodu CTRL + C”.

W czasie wykonywania zadania nikt nie jest zalogowany, więc nie ma nikogo, kto mógłby nacisnąć klawisze CTRL + C. Nie jestem pewien, czy rozumiem, co tu jest powiedziane w dokumentacji Microsoft.

Sprawdziłem podstawowe rzeczy - zaplanowane zadanie jest włączone, zaplanowane do uruchomienia każdego dnia i wskazując plik, który istnieje w prawidłowej lokalizacji. Co ciekawe, kiedy uruchamiam to zadanie ręcznie (albo uruchamiając skrypt .cmd z wiersza poleceń, albo klikając prawym przyciskiem myszy zadanie i klikając „Uruchom”), zadanie kończy się pomyślnie.

Co oznacza ten kod błędu i jak mogę uruchomić to zadanie, gdy nie ma mnie, aby go wymusić?

Rozwiązywanie problemów z zaplanowanymi skryptami:

1. Jeśli jeszcze tego nie zrobiłeś, sprawdź plik dziennika Zaplanowane zadania w interfejsie GUI w obszarze Zaawansowane > Wyświetl dziennik . Wyszukaj w pliku „ ***”, aby znaleźć najnowsze wpisy, a możesz zobaczyć dodatkowe informacje o błędzie.

2. Zdefiniuj plik dziennika, aby przechwycić dane wyjściowe i wysłać tam zarówno standardowy komunikat wyjściowy, jak i błąd standardowy. Zmień dowolny echo off do Echo dnia być pewien, że nie tłumiąc wszelkie komunikaty o błędach.
   Na przykład, jeśli skrypt zostanie wywołany, ftp.data.cmdzaplanowane zadanie może wyglądać tak:

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

3. Czy skrypt się zawiesił? Być może harmonogram zadań zabija skrypt (stąd kod błędu CTRL + C) po określonym czasie. Dodaj niektóre z nich w strategicznych punktach w swoim dokumencie,

   echo %DATE% %TIME%

4. Czy na pewno konto uruchamiające skrypt ma uprawnienia / dostęp do wszystkiego w skrypcie?

5. Jeśli nie możesz czerpać radości, uruchom to polecenie i opublikuj wynik tutaj, być może możemy zacząć od planowania,

   schtasks /query /v /fo LIST /s YOURSERVER

Nie mogę bezpośrednio odpowiedzieć na pytanie, ponieważ nie wiem dokładnie, co oznacza komunikat o błędzie (ani dlatego, jak to naprawić), ale gdybym próbował go rozwiązać, dodałbym kilka zapisów do pliku dziennika na strategiczne punkty w skrypcie, a następnie po zaplanowanym czasie zobacz, jaki jest ostatni punkt kontrolny do uruchomienia.

Podejrzewam, że coś jest nie tak z powodu poświadczeń, na których działa skrypt lub że coś w skrypcie wymaga zalogowanego użytkownika. Zawężenie miejsca, w którym występują błędy w skrypcie, może pomóc ci znaleźć kod „obrażający”.

Zdaję sobie sprawę, że jest to stary post, ale są bardzo pomocne przy poszukiwaniu rozwiązań i być może to, co znalazłem, może być pomocne. Korzystałem z WinSCP w systemie Windows Server 2003, aby przesłać na serwer ftp i otrzymałem ten sam komunikat o błędzie, a plik SchedLgU.txt wskazywał na niewystarczającą ilość czasu w sekcji „Zatrzymaj zadanie, jeśli to wystarcza dla:”, mimo że dałam zadanie mnóstwo czasu na przesłanie.

Przeglądając w Menedżerze zadań, zauważyłem, że program WinSCP.exe nie został wyczyszczony i miałem mnóstwo procesów na liście, więc utworzyłem plik wsadowy (taskkill / f / im winscp.exe), aby zabić dowolny otwarty proces, a ja uruchomić ten plik wsadowy przed WinSCP i działa teraz dobrze.

Natknąłem się na to dzisiaj na zdalnym serwerze, a rozwiązaniem była zmiana ustawienia uruchamiania z „Uruchom tylko wtedy, gdy użytkownik jest zalogowany” na „Uruchom bez względu na to, czy użytkownik jest zalogowany”.

W przypadku opcji „Uruchom tylko, gdy użytkownik jest zalogowany” zadanie uruchamia okno poleceń, które zostało zamknięte, gdy upłynęła limit czasu mojej sesji pulpitu zdalnego. Przy opcji „Uruchom bez względu na to, czy użytkownik jest zalogowany” nie wyświetla się żadne okno podczas wykonywania zadania, więc wykonanie nie zatrzymuje się po zakończeniu sesji pulpitu zdalnego.

Podobnie do odpowiedzi Cori, zalecam sprawdzenie, kto ma być uruchamiany zgodnie z harmonogramem, ponieważ widziałem ten błąd występujący, gdy konto użytkownika, które uruchamia zadanie, nie ma takich samych uprawnień jak zalogowany użytkownik

Jeśli tak było wcześniej, być może stan taki jak awaria sieci lub problem na innym hoście może wyjaśnić awarię.

Miałem ten sam błąd, a to dlatego, że uruchomiony plik wsadowy monitował o usunięcie niektórych plików za pomocą polecenia DEL. Ponieważ nie ma użytkownika, który mógłby odpowiedzieć T / N na przetwarzanie wsadowe, zaplanowane zadanie zostało zakończone. Oto komunikat, który znalazłem w moim dzienniku zaplanowanych zadań: „zadanie zostało zakończone. To działanie zostało zainicjowane przez administratora lub usługę Harmonogramu zadań (ponieważ na przykład komputer nie jest bezczynny)”. Zalecam, aby uruchomić zadanie ręcznie z wiersza polecenia, aby zobaczyć, gdzie się zatrzymuje lub monituje o interakcję użytkownika, popraw je, a zadanie będzie działać poprawnie.

Jeśli próbujesz uruchomić program pod kontrolą Harmonogramu zadań, System.Environment.CurrentDirectory zwróci C: \ Windows \ System32, NIE w miejscu, w którym znajduje się plik wykonywalny. Ten błąd może być błędem braku pliku; Próbowałem zalogować się do podkatalogu, który nie istniał w drzewie System32.

Na moich skryptach jest to jasne. Dzieje się tak, ponieważ mam „pauzę” na końcu pliku wsadowego, a zaplanowane zadanie jest ograniczone do 20 minut. Gdy użytkownik jest obecny, hi widzi przepływ pracy. Gdy plik wsadowy nie jest kończony przez zaplanowane zadanie, po 20 minutach. To powoduje 0xc000013a i jest w porządku.

Miałem ten sam problem i naprawiłem go, zmieniając wyzwalacz z „Po uruchomieniu systemu” na „Po zalogowaniu”.

miał ten sam problem .. naprawiony przez grę z użytkownikiem zarejestrowanym do uruchomienia zaplanowanego zadania. w końcu zmiana domeny była odpowiedzią.