Windows 11: problemy, na które nie pomaga nawet reinstalacja [OPINIA]
Windows jest niezwykle zaawansowany pod względem zdalnego zarządzania na masową skalę. Jest to często zapominana cecha, od kilku lat głównie ze względu na kiepską reputację jego konsumenckiej, wierzchniej warstwy. Na pewnym etapie, złożoność może wymknąć się spod kontroli.
Z dość nudnych powodów zawodowych, o których musiał ostatnio sporo słuchać Oskar, zaszła u mnie potrzeba lekkiego przemeblowania z systemami operacyjnymi. Musiałem zainstalować drugi system na laptopie, przeznaczony wyłącznie do pracy.
Pierwszy nie nadawał się do tego, ze względu na nadmiar zastosowań, w tym prywatnych… a w dodatku miał zainstalowaną wersję Insider Preview. Choć był to wariant Dev, czyli jedynie "wajcha" przerzucona w wydaniu 24H2, tej skromnej różnicy nie lubi całkiem dużo programów.
Piekielny dual-boot
Zmniejszyłem partycję głównego systemu, zainstalowałem na wolnym miejscu drugą, "oficjalną" Jedenastkę i… system zachowywał się nieco dziwnie. Nie był w stanie wybrać poprawnej rozdzielczości ekranu i odrzucał też instalację klienta VPN, zgłaszając w logach błąd pozbawiony opisu.
Dalsza część artykułu pod materiałem wideo
Ponieważ większość klientów VPN instaluje własne sterowniki, a ja do roli komputera służbowego oddelegowałem nieco starszy sprzęt, ze sterownikami niezgodnymi z najnowszymi zabezpieczeniami Windows 11, stwierdziłem, że muszę zainstalować system ponownie, ale wyłączyć w obrazie automatyczne włączanie HVCI, a sterowniki "wmusić" - zintegrować z obrazem instalacyjnym WIM. Do integracji użyłem zwykłego DISM-a, a do wyłączania HVCI - przeklętego Rufusa.
Tak zainstalowany system powitał mnie poprawnie wybraną rozdzielczością (sterowniki działają!), ale tym razem zamiast pędzić instalować potrzebne oprogramowanie, pozwoliłem mu się najpierw zaktualizować - wszak tym razem instaluję z ISO, a nie z wersji z Media Creation Tool, więc jest trochę starsza. System zaktualizował się, uruchomił ponownie… i znów zaoferował 720p zamiast 2560x1080 w 75Hz.
Aktualizacje? Rufus?
Czyżby źródłem problemów była aktualizacja? A może to Rufus "wyłączył" HVCI w sposób, który coś psuje? Nie lubię tego programu, nie ufam mu i już wyobrażałem sobie, jak piszę felieton z cyklu "a nie mówiłem!", pokazujący ciemne strony stosowania nieoficjalnych hacków. Postanowiłem zrobić obraz instalacyjny za pomocą MCT, a plik WIM potraktować NTLite. Wrzuciłem sterowniki, aktualizacje i ustawienia - w tym te wyłączające HVCI.
Instalacja z NTLite zakończyła się powodzeniem i nie było żadnych problemów z HVCI. Ha! Czyli to Rufus! Triumfalnie rozpocząłem instalację na docelowym systemie. Tym razem, system nie tylko przywitał mnie zbyt niską rozdzielczością, ale na ekranie wyboru systemu operacyjnego nie działała nawet klawiatura. Działał za to ekran dotykowy! To była jakaś grubsza sprawa.
Niespodziewany winny
Problem ze sterownikami i HVCI w ogóle okazał się poważniejszy. To nie HVCI wyładowywało moje sterowniki. Robił to App Control for Business. Odkryłem to, znajdując brakujący opis błędów (w niespodziewanym miejscu zamiast oczekiwanego). System odmawiał ładowania jakiegokolwiek kodu niepochodzącego z Microsoftu.
To dlatego, a nie przez HVCI, nie działały sterowniki i dlatego VPN i 7-Zip nawet nie chciały zacząć się instalować. A to, że samo HVCI było jakimś cudem włączone(!) i nie dawało się w ogóle wyłączyć - przełącznik nie był szary, dawał się przestawiać, ale sam wracał do poprzedniego stanu - było oddzielnym zjawiskiem, potęgującym jedynie problem.
Coś zapisało mój komputer do Intune? Przecież jeszcze się nie zalogowałem do pracy! Czyżbym miał tak naprawdę używany komputer? Skąd indziej brałyby się polityki App Control na świeżym systemie? Postanowiłem sprawdzić tę hipotezę. Podmieniłem dysk twardy i zainstalowałem system na całkowicie świeżym SSD, zamiast reinstalowania. Okazało się, że… problem nie wystąpił. Występował tylko w scenariuszu dual boot i tylko w tym drugim systemie.
Code Integrity!
Byłem w kropce. Dawno już przygotowałem do pracy inny komputer, ale nie umiałem odpuścić problemów z tamtym. Sięgnąłem po systemowy CiTool - narzędzie do zarządzania funkcją Code Integrity, pozwalające na ładowanie polityk ograniczających wykonywanie kodu w Windows. To genialne narzędzie. Dzięki niemu można na przykład zezwolić wyłącznie na uruchamianie oprogramowania podpisanego przez konkretne firmy - to znacznie mądrzejsze od białych list programów i dawnego AppLockera. CiTool pozwala wypisać aktywne polityki.
Poza zbiorem systemowych (wyłączonych) polityk, na liście znajdowały się trzy obce, w tym jedna dająca zero wyników w Google: "NXTLockdownPolicy". Jej źródła nie znalazłem nigdzie na dysku C:. Była jednak gdzie indziej. Na partycji zero. EFI System Partition (ESP). Partycji menedżera ładowania, wspólnej(!) dla wszystkich Windowsów na dysku. Nowe instalacje nie tworzą kolejnych partycji ESP, może istnieć tylko jedna. Zamiast tego dopisują się więc do już istniejącej.
Niezniszczalne reguły
Reguły z ESP zostały dopisane na próbę przez wersję Insider Preview, żeby testować dziedziczenie zasad z ESP. Wersje Insider wiedzą jednak, że mają ją ignorować. Wersje 24H2 w ogóle jej nie rozumieją… dopóki nie zostaną zaktualizowane! Wtedy próbują ją egzekwować - bo przecież są oficjalne, a nie próbne, więc plik musi tam być na serio.
Dlatego problem wystąpił dopiero na drugim systemie, po drugim reboocie i nie ustępował mimo pięciu reinstalacji. Problem został opisany w notach wydawniczych, ale w taki sposób, że czytając je uznałem, że dotyczy to scenariusza, który mi się nie przytrafi. Dopiero wątek na forum Microsoft Answers dorzucił detal, że dotyczy on także przypadków Dual Boot.
Code Integrity to rewelacyjne rozwiązanie. Jego zaletom dorównuje jednak skala problemów, jakie może ono wywołać. A w świecie UEFI nic już nie jest zbyt proste - "bezpieczny rozruch" tworzy bardzo skomplikowane, potencjalne scenariusze. Niestety, zaawansowanie funkcjonalne Windowsa ginie w jego kiepskim interfejsie. Nie dało się z niego kompletnie wywnioskować, że za blokadę odpowiada App Control. Dostępny, ale nieskuteczny przełącznik "Integralność pamięci" także był zagadkowym zachowaniem, pochodną niedokończonego GUI.
Polowanie na App Control zajęło mi łącznie trzy dni. Początkowo winnych szukałem w zupełnie błędnych miejscach. Tymczasem powodem nie tylko nie był Rufus, NTLite ani Intune. Nie było nim również wykorzystanie wersji Insider ani instalacja na nieobsługiwanym sprzęcie. Insider, owszem, był źródłem wadliwych polityk, ale powodem bezowocnych poszukiwań był tragiczny, niekompletny i często wręcz mylący interfejs Windows 11. Jest to coś, co nie uległo przez 3,5 roku od wydania znaczącej poprawie…
Kamil J. Dudek, współpracownik redakcji dobreprogramy.pl