cmd.exe nieuruchamiające PowerShell jako podrzędny proces wskazuje na błąd w składni wywołania lub brak PowerShell w zmiennej PATH.
cmd.exe nie uruchamia PowerShell jako podrzędny proces – czym jest ten problem
Komunikat lub zachowanie polegające na tym, że cmd.exe nie uruchamia PowerShell jako procesu podrzędnego, oznacza problem na styku dwóch powłok systemu Windows. W typowym scenariuszu wiersz polecenia powinien przekazać uruchomienie do programu PowerShell, wykonać wskazane polecenie, a następnie odebrać kod zakończenia działania. Jeżeli tak się nie dzieje, polecenie może zostać odrzucone od razu, może pojawić się informacja o nierozpoznanej nazwie albo okno może zamknąć się bez widocznego komunikatu.
Nie należy utożsamiać tego objawu wyłącznie z awarią samego PowerShell. Przyczyną może być błędna składnia, nieprawidłowe użycie cudzysłowów, pomieszanie składni właściwej dla cmd.exe i składni PowerShell, brak odpowiedniej ścieżki do pliku wykonywalnego lub ograniczenia zastosowane przez konfigurację systemu. Znaczenie ma również wersja środowiska. W systemie może znajdować się klasyczny powershell.exe, nowszy pwsh.exe albo oba programy jednocześnie. Są to podobne narzędzia, lecz nie zawsze są dostępne pod tą samą nazwą.
Określenie „proces podrzędny” opisuje relację uruchomienia, a nie osobną funkcję użytkową. Proces nadrzędny, którym jest w tym przypadku cmd.exe, tworzy proces PowerShell i oczekuje na jego zakończenie albo pozwala mu działać niezależnie, zależnie od użytych parametrów. Błąd może więc dotyczyć zarówno odnalezienia programu, jak i sposobu przekazania argumentów, ścieżek oraz znaków specjalnych.
PowerShell wywoływany z cmd.exe – kontekst techniczny i porównanie składni
cmd.exe oraz PowerShell są powłokami, ale posługują się innymi regułami interpretacji tekstu. W wierszu polecenia często wykorzystuje się konstrukcję powershell.exe -Command, po której przekazywane jest polecenie zapisane jako tekst. PowerShell analizuje wtedy przekazany fragment ponownie. Z tego powodu znaki takie jak cudzysłów, nawias, pionowa kreska, średnik czy znak procenta mogą zostać przetworzone przez pierwszą powłokę, zanim dotrą do drugiej.
Ważne jest rozróżnienie między uruchomieniem programu a wykonaniem polecenia przez ten program. Samo wskazanie powershell.exe powinno prowadzić do uruchomienia środowiska, natomiast parametr -Command określa kod, który ma zostać wykonany. Do uruchamiania skryptu służy zwykle parametr -File, ale jego użycie wymaga prawidłowej ścieżki i właściwego sposobu cytowania. Ścieżka zawierająca spacje powinna być traktowana jako jeden argument. Niewłaściwe umieszczenie cudzysłowu może spowodować, że część ścieżki zostanie uznana za oddzielne polecenie.
Przydatne jest także sprawdzenie, czy polecenie jest kierowane do właściwego programu. W zależności od instalacji może być konieczne wskazanie pełnej ścieżki do pliku, zamiast polegania na zmiennej PATH. Zmienna środowiskowa PATH jest listą katalogów, w których system szuka programów wywołanych bez pełnej lokalizacji. Jeżeli wpis został usunięty, zmieniony albo wskazuje na nieistniejący katalog, nazwa programu może nie zostać rozpoznana mimo jego obecności na dysku.
Nie powinno się również mieszać operatorów przekierowania. W cmd.exe symbole >, >>, < oraz | mają określone znaczenie, a PowerShell używa części z nich w podobny, lecz nie zawsze identyczny sposób. Przy przekazywaniu polecenia przez -Command interpretacja może przebiegać w dwóch etapach. Dlatego testowanie krótkiego polecenia bez parametrów, a dopiero potem dodawanie argumentów, ułatwia wskazanie miejsca błędu.
Typowe problemy, gdy cmd.exe nie przekazuje polecenia do PowerShell
Nieprawidłowa składnia wywołania. Literówka w nazwie parametru, brak odstępu albo źle ustawiony cudzysłów mogą spowodować, że cmd.exe odczyta całość jako nieznane polecenie. Szczególnie często występuje to przy ścieżkach zawierających spacje oraz przy zagnieżdżonych cudzysłowach.
Brak programu w zmiennej PATH. PowerShell może być zainstalowany, lecz system nie odnajduje go po samej nazwie. W takiej sytuacji można sprawdzić lokalizację pliku wykonywalnego i porównać ją z wpisami środowiskowymi. Zmiana zmiennej systemowej powinna być wykonywana ostrożnie, ponieważ błędna edycja może utrudnić uruchamianie także innych programów.
Wywołanie niewłaściwej wersji. Skrypt przygotowany dla jednej wersji PowerShell może korzystać z poleceń lub parametrów niedostępnych w innej. Warto ustalić, czy wywoływany jest powershell.exe, czy pwsh.exe, oraz czy dokumentacja skryptu odpowiada używanemu środowisku.
Blokada wykonywania skryptów. Systemowe zasady bezpieczeństwa mogą zezwalać na uruchamianie powłoki, ale ograniczać wykonywanie plików skryptowych. Wtedy samo otwarcie PowerShell działa, natomiast polecenie wskazujące plik może kończyć się odmową. Nie należy obniżać zabezpieczeń bez ustalenia, jaki zakres zmiany jest rzeczywiście potrzebny.
Nieprawidłowe przekazanie kodu wyjścia. Jeżeli skrypt jest uruchamiany z pliku wsadowego, znaczenie ma kod zwrócony przez proces PowerShell. Błąd może być maskowany przez kolejne polecenia albo przez automatyczne zamknięcie okna. Uruchomienie z już otwartego wiersza polecenia ułatwia odczytanie pełnego komunikatu.
Problemy z uprawnieniami lub profilem użytkownika. Polecenie uruchomione w jednym koncie może działać inaczej w innym. Różnice mogą dotyczyć zmiennych środowiskowych, profilu PowerShell, dostępu do katalogu oraz zasad lokalnych. Samo uruchomienie jako administrator nie jest uniwersalnym rozwiązaniem i powinno być stosowane tylko wtedy, gdy komunikat wskazuje na brak uprawnień.
Praktyczne wskazówki dla cmd.exe i PowerShell
Diagnostykę warto prowadzić etapami. Najpierw powinno się uruchomić samo cmd.exe i sprawdzić, czy prosty proces systemowy uruchamia się prawidłowo. Następnie można wywołać PowerShell bez dodatkowego skryptu. Jeżeli program zostanie otwarty, problem najprawdopodobniej dotyczy parametrów, ścieżki lub treści przekazywanego polecenia, a nie podstawowego uruchamiania środowiska.
Kolejny krok polega na sprawdzeniu rozpoznawania nazwy programu. Pomocne jest porównanie wyniku wyszukiwania polecenia z rzeczywistą lokalizacją pliku. W przypadku kilku instalacji należy zwrócić uwagę na kolejność katalogów w PATH. Wpis znajdujący się wcześniej może decydować o tym, która wersja zostanie uruchomiona. Po zmianie zmiennych środowiskowych konieczne bywa zamknięcie i ponowne otwarcie okna wiersza polecenia, ponieważ już uruchomiony proces zachowuje wcześniejszą kopię środowiska.
Przy analizie skryptu należy usunąć zbędne elementy i sprawdzać jedną rzecz naraz. Najpierw testuje się samą ścieżkę, później pojedynczy parametr, a na końcu pełną sekwencję. Dobrze jest używać pełnych, jednoznacznych ścieżek podczas testu, a dopiero po potwierdzeniu działania upraszczać zapis. Warto też zapisać dokładny komunikat, kod zakończenia oraz moment wystąpienia problemu. Informacja, czy błąd pojawia się przed otwarciem PowerShell, czy dopiero podczas wykonywania skryptu, znacząco zawęża obszar poszukiwań.
Jeżeli polecenie jest zapisane w pliku .bat, trzeba sprawdzić znaki specjalne charakterystyczne dla plików wsadowych. Znak procenta może być interpretowany jako odwołanie do parametru lub zmiennej, a nawiasy mogą zmieniać sposób przetwarzania bloku poleceń. Przydatne jest wykonanie testu z prostym komunikatem i bez przekierowania wyjścia. Dopiero po uzyskaniu prawidłowego wyniku można odtworzyć pierwotną konstrukcję.
Kiedy zgłosić cmd.exe i PowerShell do serwisu
Zgłoszenie do serwisu jest uzasadnione, gdy problem powtarza się mimo sprawdzenia składni, ścieżki programu i podstawowych uprawnień, a także wtedy, gdy nie można ustalić, która instalacja PowerShell jest aktywna. Weryfikacji może wymagać stan plików systemowych, konfiguracja profilu użytkownika, zmienne środowiskowe, zasady wykonywania skryptów oraz działanie konkretnego pliku wsadowego. Szczególnie ostrożnie należy postępować wtedy, gdy zmiana konfiguracji ma objąć cały komputer albo gdy problem występuje równocześnie przy wielu programach.
W Warszawie takie przypadki można przekazać do Warszawskiego Pogotowia Komputerowego 24/7 pod numerem +48 22 100 48 29. Przy zgłoszeniu warto przygotować pełną treść polecenia, dokładny komunikat, informację o wersji systemu Windows oraz opis tego, czy PowerShell uruchamia się samodzielnie. Nie powinno się przesyłać haseł ani poufnych danych znajdujących się w skryptach; wystarczy zanonimizowany fragment pokazujący składnię i sposób wywołania.
Po usunięciu usterki zaleca się ponowne uruchomienie testu z konta, na którym problem występował, a następnie sprawdzenie pliku wsadowego w warunkach zbliżonych do pierwotnych. Jeżeli polecenie ma być używane automatycznie, należy potwierdzić poprawne przekazywanie argumentów, kodu zakończenia oraz komunikatów błędów. Takie sprawdzenie ogranicza ryzyko sytuacji, w której samo okno PowerShell otwiera się prawidłowo, lecz właściwe zadanie nadal nie zostaje wykonane.
