Usługa nie uruchamia się po migracji systemu

Usługa nieuruchamiająca się po migracji systemu wskazuje na uszkodzoną lub niekompletną migrację wpisów rejestru usługi.

Co zmienia migracja w konfiguracji usługi Windows

Usługa, która po migracji systemu nie uruchamia się automatycznie albo kończy pracę zaraz po starcie, nie musi oznaczać wyłącznie uszkodzenia samego programu. W systemie Windows za uruchamianie usług odpowiada Menedżer kontroli usług, czyli Service Control Manager. Odczytuje on konfigurację zapisaną między innymi w gałęzi rejestru HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Dla konkretnej usługi znajdują się tam informacje o nazwie pliku wykonywalnego, typie uruchamiania, koncie używanym do pracy oraz zależnościach.

Migracja systemu może polegać na klonowaniu dysku, odtwarzaniu obrazu, zmianie instalacji systemu albo przeniesieniu programu na inny komputer. W każdym z tych przypadków może dojść do rozbieżności między wpisem usługi a rzeczywistym środowiskiem. Wartość ImagePath może wskazywać nieistniejący plik, dawną literę dysku lub katalog, który nie został przeniesiony. Nieprawidłowa może być także wartość Start, określająca sposób uruchamiania, albo wpis DependOnService, wskazujący usługę wymaganą wcześniej przez dany komponent.

Sam fakt obecności klucza w rejestrze nie dowodzi, że konfiguracja jest kompletna. Usługa może mieć poprawną nazwę, ale brakować jej pliku wykonywalnego, bibliotek DLL, plików konfiguracyjnych lub uprawnień do katalogu roboczego. Po zmianie instalacji systemu może również zmienić się identyfikator konta, dostęp do zasobów lokalnych albo sposób mapowania dysków. Dlatego opis „uszkodzona lub niekompletna migracja wpisów rejestru usługi” należy traktować jako hipotezę dotycząca całego łańcucha konfiguracji, a nie jako automatyczne rozpoznanie jednej konkretnej przyczyny.

Objawy widoczne w Menedżerze kontroli usług

Zakres problemu można zawęzić, porównując sposób uruchamiania usługi przed migracją z konfiguracją po migracji. W konsoli usług widoczny jest stan, typ uruchamiania oraz konto logowania, ale pełniejsze informacje można odczytać poleceniem sc.exe qc NazwaUsługi. Parametr ten pokazuje między innymi typ usługi, typ startu, konto oraz ścieżkę binarną. Polecenie sc.exe query NazwaUsługi pozwala sprawdzić bieżący stan, na przykład zatrzymanie, uruchamianie albo nieoczekiwane zakończenie.

Komunikat „nie można uruchomić usługi” jest zbyt ogólny, aby na jego podstawie wskazać przyczynę. Istotny jest kod błędu zwrócony przez Service Control Manager. Kod 2 oznacza brak wskazanego pliku, kod 3 wskazuje brak ścieżki, a kod 1068 oznacza, że usługa zależna lub grupa zależności nie mogła zostać uruchomiona. Przy błędach logowania często pojawia się kod 1069. Kod 1053 informuje, że usługa nie odpowiedziała na żądanie uruchomienia lub kontroli w wymaganym czasie, ale nie wyjaśnia samodzielnie, dlaczego proces nie wystartował.

Drugim źródłem informacji jest Podgląd zdarzeń. W dzienniku System należy zwrócić uwagę na zdarzenia związane z dostawcą Service Control Manager, natomiast szczegóły awarii programu mogą znajdować się również w dzienniku Aplikacja. Należy odróżnić usługę, która w ogóle nie została uruchomiona, od procesu uruchomionego przez usługę i zakończonego później z powodu braku biblioteki, błędnej konfiguracji lub konfliktu z innym komponentem. Ta różnica decyduje o dalszym kierunku diagnostyki.

Weryfikacja ścieżki, zależności i uprawnień

Pierwszym krokiem jest sprawdzenie, czy ścieżka zapisana w konfiguracji wskazuje właściwy plik wykonywalny. Trzeba uwzględnić cudzysłowy przy ścieżkach zawierających spacje oraz argumenty przekazywane programowi. Błąd w rozdzieleniu ścieżki i parametrów może spowodować, że Menedżer kontroli usług spróbuje uruchomić niewłaściwy plik. Należy też sprawdzić, czy plik istnieje w systemie po migracji i czy zachowano wymagane biblioteki oraz pliki konfiguracyjne.

Do odczytu podstawowych właściwości usługi można użyć programu PowerShell i klasy WMI/CIM Win32_Service. Przykładowe zapytanie Get-CimInstance Win32_Service -Filter "Name='NazwaUsługi'" zwraca między innymi nazwę wyświetlaną, stan, tryb startu, konto oraz ścieżkę binarną. Warto porównać te dane z wpisem rejestru i z dokumentacją instalowanego programu. Zmiana nazwy wyświetlanej nie jest tym samym co zmiana nazwy systemowej, dlatego do identyfikacji należy stosować właściwość Name, a nie tylko tekst widoczny w interfejsie.

Następnie trzeba sprawdzić zależności. Usługa może wymagać uruchomienia podstawowych składników systemu, sterownika albo innej usługi dostarczanej przez ten sam program. Jeżeli zależność wskazuje nazwę, której nie ma w nowej instalacji, uruchomienie może zakończyć się błędem 1068. Jeżeli usługa działa na koncie innym niż lokalne konto systemowe, należy zweryfikować, czy konto nadal istnieje, czy hasło nie zostało unieważnione i czy konto ma prawo logowania jako usługa. Trzeba również sprawdzić uprawnienia NTFS do pliku wykonywalnego, katalogu programu, katalogów tymczasowych i wymaganych lokalizacji danych. Przywracanie obrazu może odtworzyć pliki, ale nie zawsze odtwarza prawidłowo wszystkie zależności instalatora.

Naprawa konfiguracji po przeniesieniu systemu

Bezpieczna naprawa powinna rozpocząć się od zapisania aktualnej konfiguracji i zebrania kodów błędów, a nie od ręcznego usuwania klucza usługi z rejestru. Jeżeli problem dotyczy programu zainstalowanego po migracji, prawidłowym rozwiązaniem jest często ponowne uruchomienie jego instalatora albo wykonanie naprawy instalacji. Instalator może odtworzyć brakujące pliki, zarejestrować biblioteki, utworzyć zależności i zapisać poprawną ścieżkę binarną. Ręczna edycja rejestru ma sens dopiero wtedy, gdy wiadomo, która wartość jest błędna i jaki powinien być jej prawidłowy stan.

Jeżeli plik usługi istnieje, ale proces nadal się zatrzymuje, należy uruchomić diagnostykę samego programu: sprawdzić jego pliki konfiguracyjne, dostęp do wymaganych katalogów, wpisy w dziennikach oraz zgodność architektury programu z systemem. Niektóre usługi wymagają ponownej rejestracji komponentu, odtworzenia certyfikatu lokalnego albo ustawienia prawidłowego katalogu roboczego. Takie czynności powinny wynikać z dokumentacji konkretnego oprogramowania, ponieważ ogólna zmiana parametrów usługi może doprowadzić do kolejnych błędów.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę problemów z uruchamianiem usług po migracji systemu, sprawdzenie konfiguracji oprogramowania oraz weryfikację podstawowych zależności potrzebnych do prawidłowej pracy komputera. W przypadku podejrzenia uszkodzenia systemu można najpierw ustalić, czy problem dotyczy pojedynczej usługi, czy szerszej niezgodności po migracji. Dopiero po takim rozróżnieniu można dobrać właściwe działanie: korektę konfiguracji, naprawę instalacji programu, przywrócenie brakujących składników albo ponowną migrację.