WSL crashuje przy starcie GUI aplikacji

WSL crashujący przy starcie GUI aplikacji wskazuje na brak skonfigurowanej obsługi WSLg lub konflikt sterownika graficznego.

Dlaczego WSL może zakończyć pracę podczas uruchamiania aplikacji GUI

WSL, czyli Windows Subsystem for Linux, pozwala uruchamiać środowisko Linuksa bez tworzenia klasycznej maszyny wirtualnej. Samo WSL nie jest jednak aplikacją graficzną. Programy z interfejsem okienkowym wymagają dodatkowej warstwy integracyjnej WSLg, dostępnej przede wszystkim w WSL 2 na obsługiwanych instalacjach Windows. WSLg przekazuje obraz aplikacji do pulpitu Windows oraz zapewnia obsługę dźwięku, grafiki i urządzeń wejściowych. Jeżeli WSLg nie działa, aplikacja może nie otworzyć okna, zakończyć się natychmiast albo sprawiać wrażenie, że cały WSL uległ awarii.

Komunikat o crashu przy starcie GUI nie wskazuje automatycznie jednej przyczyny. Błąd może powstać podczas inicjalizacji dystrybucji, podczas uruchamiania serwera Wayland lub X11, przy nawiązywaniu połączenia z warstwą RDP albo podczas tworzenia kontekstu graficznego. Znaczenie ma także rodzaj aplikacji. Program korzystający wyłącznie z X11 może zachowywać się inaczej niż aplikacja używająca Wayland, OpenGL, Vulkanu lub akceleracji sprzętowej. Dlatego konieczne jest ustalenie, czy zamyka się proces WSL, konkretna dystrybucja, czy tylko aplikacja graficzna.

Rola WSLg, Wayland i sterownika graficznego

WSLg korzysta z kompozytora Weston działającego w środowisku WSL oraz z mechanizmu zdalnego wyświetlania zintegrowanego z systemem Windows. Aplikacje mogą używać zmiennych środowiskowych takich jak DISPLAY i WAYLAND_DISPLAY, aby znaleźć odpowiedni serwer graficzny. Ich brak, pusta wartość albo ręczne ustawienie nieprawidłowego adresu może spowodować błąd startu. Dotyczy to szczególnie konfiguracji przenoszonych ze zwykłego serwera X uruchamianego niezależnie w Windows, ponieważ stare wpisy w plikach powłoki mogą kolidować z automatyczną konfiguracją WSLg.

Drugim elementem jest sterownik grafiki po stronie Windows. WSLg wykorzystuje sterownik producenta karty graficznej oraz warstwę DirectX dostęp­ną dla środowiska WSL. Nieaktualny, uszkodzony albo niezgodny sterownik może powodować awarie przy tworzeniu akcelerowanego kontekstu OpenGL lub Vulkan. Objawem bywa uruchamianie aplikacji w trybie programowym, czarny ekran, natychmiastowe zamknięcie okna albo błąd dotyczący biblioteki Mesa. Sama obecność plików aplikacji w dystrybucji nie potwierdza więc poprawności całego łańcucha graficznego.

Warto również odróżnić WSL 1 od WSL 2. WSL 1 nie zapewnia tego samego środowiska jądra i integracji graficznej co WSL 2, dlatego instrukcje dotyczące WSLg nie mogą być bezpośrednio przenoszone na każdą dystrybucję. Stan komponentu można sprawdzić poleceniami wsl --status oraz wsl --version, a listę dystrybucji i ich tryb pracy poleceniem wsl --list --verbose. Wyniki pokazują, czy używana dystrybucja działa z WSL 2 i czy komponenty WSL są dostępne w aktualnej instalacji.

Metody rozróżnienia awarii środowiska od błędu programu

Pierwszy etap diagnostyki polega na uruchomieniu samej dystrybucji bez aplikacji graficznej. Jeżeli powłoka działa, polecenia tekstowe wykonują się poprawnie, a problem występuje wyłącznie po wywołaniu programu GUI, bardziej prawdopodobny jest błąd aplikacji, jej bibliotek albo komunikacji z WSLg. Jeżeli natomiast dystrybucja zamyka się również przy zwykłym uruchomieniu, trzeba zbadać stan WSL, systemu plików i konfiguracji dystrybucji niezależnie od grafiki.

Następnie można sprawdzić, czy środowisko przekazuje aplikacji oczekiwane zmienne wyświetlania oraz czy istnieją gniazda używane przez X11 lub Wayland. Przydatne są polecenia echo $DISPLAY, echo $WAYLAND_DISPLAY i env | grep -E 'DISPLAY|WAYLAND|XDG_RUNTIME_DIR'. Polecenie z filtrem dotyczy wyłącznie diagnostyki wartości środowiskowych; jego wynik należy interpretować razem z typem aplikacji. W przypadku programów opartych na GTK, Qt, Electronie lub bibliotekach OpenGL warto sprawdzić także komunikat błędu uruchomienia, ponieważ może wskazać brak biblioteki, nieprawidłowy backend albo problem z akceleracją.

Bezpiecznym krokiem odświeżającym stan komponentów jest wykonanie w Windows polecenia wsl --shutdown, a następnie ponowne uruchomienie dystrybucji. Nie usuwa ono dystrybucji ani jej plików; kończy działające instancje WSL. Jeżeli problem pozostaje, można użyć wsl --update, aby zaktualizować komponent WSL, o ile system i uprawnienia na to pozwalają. Dalsza diagnostyka powinna obejmować wersję Windows, wersję WSL, model i sterownik karty graficznej, logi aplikacji oraz Podgląd zdarzeń systemu Windows. Rejestrację awarii warto porównać z momentem uruchomienia programu, zamiast traktować każdy wpis ostrzegawczy jako przyczynę.

Zakres naprawy problemu z aplikacją GUI w WSL

Usunięcie awarii może polegać na skorygowaniu zmiennych środowiskowych, usunięciu błędnych ręcznych wpisów konfiguracji X11, aktualizacji WSLg i sterownika graficznego albo przełączeniu aplikacji na właściwy backend renderowania. Czasem problem dotyczy pojedynczego programu: uszkodzonego profilu użytkownika, niezgodnych bibliotek systemowych lub błędnej konfiguracji zapisanej w katalogu domowym dystrybucji. W takiej sytuacji reinstalacja całego WSL może być niepotrzebna i mogłaby utrudnić zachowanie istniejących danych.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, w tym diagnostyką problemów z systemem Windows oraz środowiskiem WSL używanym na komputerze użytkownika.

Przed zmianami w konfiguracji należy ustalić, czy w dystrybucji znajdują się ważne projekty, pliki konfiguracyjne lub dane aplikacji. Nie powinno się wykonywać poleceń usuwających dystrybucję, resetujących jej system plików ani kasujących katalogi użytkownika bez potwierdzenia zakresu problemu. Prawidłowa diagnoza kończy się wskazaniem konkretnego elementu łańcucha: WSL, WSLg, biblioteki aplikacji, sterownika grafiki albo samego programu GUI. Dopiero wtedy można dobrać naprawę, która przywróci uruchamianie aplikacji bez niepotrzebnej utraty konfiguracji.