Harmonogram nie dziedziczy PATH

Harmonogram nie dziedziczy PATH wskazuje, że zadania uruchamiane przez Harmonogram zadań korzystają z własnego, ograniczonego środowiska zmiennych — ścieżkę trzeba podać jawnie w akcji zadania.

Czym oznacza komunikat „Harmonogram nie dziedziczy PATH”

Określenie „Harmonogram nie dziedziczy PATH” odnosi się do sytuacji, w której zadanie uruchamiane automatycznie przez Harmonogram zadań systemu Windows nie otrzymuje takiego samego zestawu zmiennych środowiskowych jak program uruchomiony ręcznie w zalogowanej sesji użytkownika. Zmienna PATH zawiera listę katalogów przeszukiwanych przez system podczas wywoływania programu bez podania pełnej ścieżki do pliku wykonywalnego. W zwykłym oknie terminala polecenie może więc zadziałać po wpisaniu samej nazwy, ponieważ system odnajduje odpowiedni plik w jednym z katalogów zapisanych w PATH. Przy uruchomieniu zadania według harmonogramu dostępne środowisko może być jednak ograniczone, odmienne dla konkretnego konta albo pozbawione wpisów dodanych tylko do profilu użytkownika.

W praktyce oznacza to, że akcja zawierająca polecenie takie jak python, robocopy, powershell lub nazwę własnego programu może zakończyć się błędem, mimo że identyczne polecenie działa wpisane ręcznie. Nie świadczy to od razu o uszkodzeniu programu. Często przyczyną jest sposób przygotowania akcji, konto używane przez zadanie, katalog roboczy albo różnica między zmiennymi ustawionymi dla użytkownika i dla całego systemu. Harmonogram wykonuje polecenie w określonych warunkach, które powinny zostać opisane jawnie zamiast zakładać, że środowisko będzie takie samo jak podczas pracy przy komputerze.

Najpewniejszym rozwiązaniem jest wskazanie pełnej ścieżki do programu w polu programu lub skryptu, na przykład C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, a następnie przekazanie parametrów w osobnym polu argumentów. W przypadku skryptu warto również podać pełną ścieżkę do pliku, sprawdzić katalog „Rozpocznij w” oraz unikać odwołań względnych, których znaczenie może zmieniać się zależnie od sposobu uruchomienia. Tak przygotowana konfiguracja ogranicza zależność od bieżącej sesji i od zawartości zmiennej PATH.

Dlaczego uruchomienie ręczne różni się od działania zadania

Podczas ręcznego uruchamiania polecenia przez użytkownika system korzysta z kontekstu bieżącego konta. Obejmuje on między innymi zmienne środowiskowe użytkownika, zmienne systemowe, ustawienia powłoki, uprawnienia oraz katalog, w którym otwarto terminal. Zadanie harmonogramu może być wykonywane bez interaktywnego logowania, z zaznaczoną opcją uruchamiania niezależnie od tego, czy użytkownik jest zalogowany, albo przy użyciu innego konta. Każdy z tych wariantów może zmienić dostępne ścieżki i sposób interpretowania poleceń.

Istotne jest rozróżnienie między PATH użytkownika a systemowym PATH. Program zainstalowany wyłącznie dla jednego profilu może zostać dopisany do zmiennej tego profilu, ale nie musi być widoczny dla zadania uruchamianego z konta systemowego lub innego użytkownika. Podobny efekt występuje po zmianie zmiennej środowiskowej, gdy otwarta wcześniej powłoka nadal korzysta ze starej wartości, a nowe procesy otrzymują już inną konfigurację. W rezultacie dwa pozornie identyczne polecenia mogą odwoływać się do różnych plików albo jedno z nich może nie znaleźć programu wcale.

Podanie pełnej ścieżki zmniejsza liczbę zależności, ale nie rozwiązuje każdego problemu. Program może wymagać określonego katalogu roboczego, dostępu do profilu użytkownika, pliku konfiguracyjnego, udziału sieciowego lub uprawnień do zapisu. W skryptach powłoki należy zwracać uwagę na sposób przekazywania argumentów, znaki cudzysłowu, rozszerzenia plików oraz kolejność parametrów. Przydatne jest także przekierowanie standardowego wyjścia i błędów do pliku logu, aby można było ustalić, czy problem dotyczy odnalezienia programu, dostępu do danych, czy dopiero dalszego etapu wykonywania skryptu.

W przypadku poleceń systemowych można testować pełną lokalizację pliku za pomocą polecenia where albo sprawdzić właściwości programu w Eksploratorze plików. Warto jednak zachować ostrożność przy kopiowaniu ścieżek z innego komputera, ponieważ lokalizacja zależy od wersji systemu, sposobu instalacji oraz architektury aplikacji. Lepsze rezultaty daje sprawdzenie konfiguracji bezpośrednio na urządzeniu, na którym działa zadanie.

Typowe błędy i objawy błędnej konfiguracji

Najczęstszym objawem jest komunikat informujący, że nazwa polecenia nie jest rozpoznawana, plik nie został znaleziony albo wykonanie zakończyło się kodem błędu. W historii Harmonogramu zadań może być widoczne samo uruchomienie zadania, lecz bez oczekiwanego efektu. Czasami zadanie przez krótki czas otrzymuje status działania, po czym kończy się bez wyraźnego komunikatu na ekranie, ponieważ działa w tle i nie ma interaktywnego okna. Brak okna nie oznacza, że polecenie zostało wykonane poprawnie.

Do powtarzających się przyczyn należą:

• użycie samej nazwy programu zamiast pełnej ścieżki do pliku wykonywalnego,
• dodanie wymaganej lokalizacji tylko do zmiennych środowiskowych konkretnego użytkownika,
• uruchamianie zadania przy użyciu konta, które nie ma dostępu do programu lub katalogu danych,
• pominięcie katalogu roboczego przy skrypcie korzystającym ze ścieżek względnych,
• umieszczenie parametrów w niewłaściwym polu akcji,
• zależność od mapowanego dysku, który nie jest dostępny poza sesją użytkownika,
• brak cudzysłowu przy ścieżce zawierającej spacje,
• wywołanie skryptu za pomocą powłoki, której lokalizacja również nie została podana jawnie,
• zapis logu w katalogu chronionym przed zapisem dla używanego konta.

Weryfikację najlepiej rozpocząć od porównania środowiska ręcznego i harmonogramu. Można utworzyć tymczasowy skrypt zapisujący do pliku wartość %PATH%, nazwę konta, bieżący katalog oraz wynik wywołania programu. Taki test pokazuje, czy zadanie korzysta z innego kontekstu niż terminal. Należy przy tym unikać zapisywania haseł, tokenów i innych poufnych danych do logu. Po ustaleniu przyczyny warto zastąpić testy rozwiązaniem opartym na pełnych ścieżkach, jasno określonym katalogu roboczym i kontrolowanym pliku logu.

Nie powinno się również bez potrzeby dopisywać przypadkowych katalogów do globalnego PATH. Może to utrudnić późniejsze ustalenie, która wersja programu jest uruchamiana, a także wprowadzić konflikt między aplikacjami o tych samych nazwach. Bezpieczniej jest odwoływać się do konkretnego pliku i sprawdzić jego właściwości, zwłaszcza gdy zadanie ma działać regularnie lub wykonywać operacje na ważnych danych.

Kiedy trzeba oddać urządzenie do diagnozy - Harmonogram nie dziedziczy PATH

Do serwisu warto zgłosić się wtedy, gdy zadanie nadal nie wykonuje polecenia mimo użycia pełnej ścieżki, poprawienia argumentów i sprawdzenia konta uruchamiającego. Pomoc może być potrzebna również wtedy, gdy problem pojawia się po aktualizacji systemu, zmianie użytkownika, reinstalacji programu albo przeniesieniu zadania na inne urządzenie. Analiza powinna objąć konfigurację akcji, uprawnienia, katalogi robocze, wpisy w zmiennych środowiskowych, logi oraz zależności używanego skryptu.

W ramach takiej diagnostyki można odtworzyć uruchomienie w warunkach zbliżonych do tych, w których działa Harmonogram zadań, ustalić dokładny etap zakończenia operacji i przygotować czytelniejszą konfigurację. Szczególnej uwagi wymagają zadania wykonywane bez zalogowanego użytkownika, korzystające z dysków sieciowych, folderów profilu albo programów instalowanych wyłącznie dla jednego konta. W takich przypadkach sam wpis w PATH jest tylko jednym z elementów całego środowiska wykonawczego.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić sprawdzenie problemu z działaniem zadań automatycznych, a w przypadku laptopa dostępna jest darmowa diagnoza LAPTOPA. Przed przekazaniem urządzenia dobrze przygotować opis objawu, nazwę zadania, informację o tym, czy problem występuje przy ręcznym uruchomieniu, oraz treść komunikatu z historii Harmonogramu. Takie dane ułatwiają odtworzenie sytuacji i ograniczają ryzyko zmiany konfiguracji bez potwierdzenia przyczyny.