Szybkie uruchamianie w Windows 8 to mechanizm tworzony „na kolanie”

Windows 8 nie jest tutaj żadnym wyjątkiem. Wprost przeciwnie. Gdy dwa lata temu system ten debiutował na rynku, byłem nim zaciekawiony. Nie ze względu na interfejs Modern, bo ten nigdy nie przypadł mi do gustu, ale z niektórych funkcji których wcześniej nie było, a z których nareszcie można było skorzystać. Za przykłady podam zintegrowanego z systemem Windows Defendera, antywirusa, który spisuje się lepiej niż samodzielny Security Essentials, szyfrowanie dysków BitLockerem, który nie wymagał już inwestowania w wersję Ultimate (acz to z racji uproszczenia dystrybucji do wersji podstawowej i Pro), wbudowanego oprogramowania do wirtualizacji w postaci Hyper-V, czy też funkcji pozwalającej na odświeżanie systemu tj. przywracanie go do stanu po formacie, bez jego faktycznego przeprowadzania i ponownego męczenia się z procesem telefonicznej aktywacji.

Jedną z przydatnych funkcji miało być szybkie uruchamianie (Fast Boot). Do tej pory każda kolejna wersja systemu Windows w sposób standardowy zamykała system, a przy starcie inicjowała wszystkie urządzenia, sterowniki, kernel, aby nareszcie ruszyć z systemem. W Microsofcie ktoś wpadł na szalenie prosty pomysł, że przecież można to uprościć. Tak powstało wspomniane szybkie uruchamianie, które nazywane jest także uruchamianiem hybrydowym. Przy zamykaniu systemu kernel wraz ze swoimi ustawieniami jest hibernowany, a przy ponownym starcie po prostu wczytywany, co znacznie przyśpiesza całą procedurę. Jest to doskonale widoczne w szczególności na np. laptopach z dyskami talerzowymi, które uruchamiają się znacznie szybciej, od swoich odpowiedników pracujących pod kontrolą systemu Windows 7. Coś jednak za coś, bo ponowne uruchamianie trwa za to nieco dłużej, wtedy następuje ładowanie wszystkiego od postaw. O tym, jak wygląda to dokładnie i jakie są różnice pomiędzy poszczególnymi systemami dowiecie się z kapitalnego wpisu DjLeo, który pojawił się już spory czas temu na łamach blogów naszego portalu, a który nie stracił na aktualności i nadal dobrze opisuję specyfikę tego rozwiązania.

Oczywiście w świecie nic nie jest idealne, idealny nie mógł być więc i ten mechanizm stworzony przez Microsoft. W styczniu ubiegłego roku głośne stały się problemy, na jakie natrafili użytkownicy Linuksa, korzystający jednocześnie z Windows 8 na tym samym komputerze. Jak się okazało, szybkie uruchamianie powoduje również zapisywanie danych o buforze plików na partycjach NTFS i FAT32. Próba ich modyfikowania pod innym systemem w momencie, gdy Windows 8 był zahibernowany mogła skończyć się utratą danych. My nanosiliśmy zmiany, wgrywaliśmy nowe pliki i edytowaliśmy już istniejące, a następnie uruchamialiśmy system, dla którego one w ogóle nie istniały. Strata danych wisiała na włosku i często do niej dochodziło. Autorzy dystrybucji Linuksowych poradzili sobie z tym problemem bardzo dobrze: obecnie mogą one wykrywać stan zahibernowania i uniemożliwić edycję. Proste, może nieco ograniczające, ale przede wszystkim bezpieczne i skuteczne.

Od premiery systemu minęły dwa lata, w międzyczasie pojawił się Windows 8.1, a także cały szereg aktualizacji, który zapewne spokojnie wypełniłby nie jedną, ale dwie płyty DVD jakie normalnie zajmuje ten system. W ostatnim czasie byłem zmuszony do przeinstalowania systemu na komputerze stacjonarnym. Najpierw postanowiłem skopiować dane, a więc podłączyłem do niego drugi dysk z laptopa, przeniosłem co trzeba i zabrałem się do roboty. Dla uściślenia dodam, że na obu komputerach był zainstalowany Windows 8.1, wszystko w pełni zaktualizowane. Popełniłem błąd. Zaufałem producentowi systemu i w chwili gdy na stacjonarce instalował się system, włożyłem dysk do laptopa, uruchomiłem system i pobrałem kilka niezbędnych programów i sterowników. Później podłączyłem ten sam dysk do stacjonarki, tylko po to aby przekonać się, że owszem, miejsce jest zajęte, ale moich plików, które wcześniej przenosiłem, nigdzie już tutaj nie ma.

Co się stało? Dokładnie to samo, co w przypadku dystrybucji linuksowych. Szybkie uruchamianie zbuforowało dane, a następnie system nie wiedział, że ja coś na tych partycjach zapisałem. Niby logiczne, a jednak niepojęte biorąc pod uwagę, że na obu komputerach korzystałem z Windowsa i problem ten zdecydowanie nie powinien mieć miejsca. Żonglerka dyskami nie jest raczej codzienną czynnością, ale obecnie zastanawia mnie, jak wiele osób w ten sposób straciło swoje dane? Oczywiście ktoś może mnie teraz wyśmiać, że gdzie jest kopia zapasowa. Bez obaw, była, w chmurze i bardzo się przydała. Kopiowanie stosowałem tylko po to, aby nie czekać, aż wszystko mi się pobierze. Przy okazji mogłem przekonać się, że po zastosowaniu skanowania aplikacją chkdsk możemy odzyskać przynajmniej część straconych tak plików. Po pełnym skanowaniu system przeniesie je do folderu found.000 na partycji z której wyparowały. Na koniec wystarczy zmiana uprawnień do niego, oraz przeszukiwanie w celu odnalezienie zguby. Niestety, nie każdy plik będzie działał, to jest całkowita loteria.

Jak najbardziej można zrozumieć ten problem w konfrontacji dwóch systemów tworzonych przez inne środowiska. Nie można jednak go pojąć w momencie, gdy dotyczy on tego samego systemu. Co kierowało Microsoftem w sytuacji, gdy podjęto decyzję o wypuszczaniu na rynek czegoś tak niedopracowanego? Dodajmy do tego fakt, że nawet na komputerze stacjonarnym korzystającym jedynie z dysku SSD hibernacja jest uruchamiana domyślnie. Najwidoczniej dla tej firmy kilka GB w tą czy tamtą stronę nie ma różnicy, ale biorąc pod uwagę cenę znacznie wyższą od HDD, trudno to zignorować. Kolejne problemy objawiają się w momencie próby skorzystania z mechanizmu sprzętowego szyfrowania za pomocą eDrive, jaki pojawił się w Windows 8. Sam mechanizm nie zawsze wykrywa dysk i nie zawsze działa, a szybkie uruchamianie dorzuca nam dodatkowych problemów w postaci braku możliwości uruchomienia systemu. Skąd typowy Kowalski, ma w ogóle wiedzieć, że może natrafić na tego typu problemy?

Do wielu zarzutów w stronę Windows 8 ja dokładam własną cegiełkę, właśnie za wyraźnie źle wdrożoną funkcję szybkiego uruchamiania, która nie została poprawiona przez dwa lata aktualizowania. Nawet, jeżeli system został wypuszczony za szybko i wręcz zaplanowano, że będzie łatany z czasem, to jak widać niektóre mechanizmy są robione zupełnie na opak. Czy Windows 10 też jest narażony na takie problemy? Tego nie wiem i szczerze mówiąc, raczej nie będę już sprawdzał. Tym bardziej, że serwery OneDrive nie cechują się dużymi transferami i chyba nawet w tym wypadku warto rozejrzeć się za lepszą alternatywą.