DISM - Napraw obraz Windows krok po kroku

Narzędzie do obsługi obrazów Windows przydaje się nie tylko wtedy, gdy system zaczyna się sypać. W praktyce pozwala naprawić magazyn składników, pracować na obrazach instalacyjnych i przygotowywać środowiska offline, więc jest użyteczne zarówno dla administratorów, jak i dla osób, które chcą odratować system bez pełnej reinstalacji. Poniżej pokazuję, kiedy ma sens, jakich komend używam najczęściej i gdzie leżą typowe pułapki.

Czym jest to narzędzie i kiedy naprawdę się przydaje

DISM traktuję jako narzędzie do dwóch zadań naraz: serwisu działającego Windowsa i obsługi obrazów offline. Dzięki temu mogę nim sprawdzać, naprawiać, montować i modyfikować obrazy .wim, .vhd oraz .vhdx, a także pracować z Windows PE, Windows RE i instalatorem systemu.

Najwygodniejsza cecha jest prosta: na współczesnych Windowsach narzędzie jest już w systemie, więc zwykle nie trzeba nic doinstalowywać. Gdy pracuję z starszym środowiskiem albo przygotowuję nośniki wdrożeniowe, sięgam po Windows ADK, bo daje mi większą kontrolę nad wersją i zakresem funkcji.

W praktyce to nie jest „magiczna naprawa wszystkiego”, tylko precyzyjny serwis warstwy komponentów Windows. Dzięki temu ma sens tam, gdzie zwykłe skanowanie plików nie wystarcza, ale zanim przejdę do komend, pokazuję sytuacje, w których naprawdę warto go uruchomić.

Kiedy używam go do naprawy systemu

Najczęściej sięgam po to narzędzie wtedy, gdy Windows Update kończy się błędem, instalacja funkcji albo aktualizacji zatrzymuje się bez jasnej przyczyny, a SFC zgłasza, że nie potrafi odtworzyć części plików. Przydaje się też po nieudanej aktualizacji wersji Windows albo wtedy, gdy magazyn składników zaczyna zachowywać się niestabilnie.

• gdy Windows Update pobiera poprawki, ale nie potrafi ich domknąć,
• gdy system zgłasza uszkodzone pliki, ale zwykła naprawa nie pomaga,
• gdy funkcje opcjonalne albo składniki systemu nie chcą się włączyć,
• po nieudanej aktualizacji lub przerwanym wdrożeniu systemu,
• przy przygotowywaniu obrazu instalacyjnego, który ma trafić na wiele maszyn.

Jeśli problem wygląda jak uszkodzony dysk, pamięć RAM albo infekcja, nie zaczynam od naprawy obrazu. Najpierw sprawdzam sprzęt i dopiero potem system, bo w przeciwnym razie łatwo pomylić objaw z przyczyną. Gdy wiem już, że chodzi o komponenty Windows, przechodzę do samej procedury.

Jak naprawiam obraz Windows krok po kroku

W codziennej pracy idę od krótkiego testu do pełnej naprawy, bo to oszczędza czas i pozwala uniknąć zbędnego pobierania plików. Na typowym laptopie szybki test kończy się prawie od razu, skan zajmuje zwykle od kilku do kilkunastu minut, a pełna naprawa potrafi trwać od 15 do 60 minut, zależnie od skali uszkodzeń i źródła plików.

1. Uruchamiam terminal jako administrator.
2. Sprawdzam stan magazynu składników poleceniem Dism /Online /Cleanup-Image /CheckHealth.
3. Jeśli wynik sugeruje problem, wykonuję pełniejszy skan: Dism /Online /Cleanup-Image /ScanHealth.
4. Gdy system rzeczywiście wymaga naprawy, uruchamiam Dism /Online /Cleanup-Image /RestoreHealth.
5. Po zakończeniu sprawdzam pliki chronione systemu poleceniem sfc /scannow.
6. Na końcu restartuję komputer i dopiero wtedy oceniam efekt.

Jeśli naprawa ma pobrać brakujące składniki z internetu, pozwalam jej pracować do końca. Gdy aktualizacje są zablokowane albo komputer nie ma dostępu do sieci, przechodzę na lokalne źródło i wtedy cała procedura staje się bardziej przewidywalna. To prowadzi wprost do najważniejszych komend, które warto mieć pod ręką.

Najważniejsze komendy, które warto mieć pod ręką

Najbardziej praktyczne polecenia da się sprowadzić do kilku scenariuszy. Nie używam ich na ślepo, tylko dobieram do sytuacji, bo każda z tych opcji robi trochę coś innego.

W praktyce źródło często wskazuję na obraz instalacyjny z tym samym wydaniem Windows, na przykład na nośnik z folderem sources. Przy obrazach WIM trzeba czasem doprecyzować indeks, bo w jednym pliku może być kilka edycji systemu.

Dism /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess

Jeśli odwołuję się do lokalnego źródła, pilnuję zgodności wersji. To nie jest detal, który da się zignorować, bo starsze narzędzie nie naprawi obrazu nowszego niż ono samo. Z takiej perspektywy naturalnie wychodzi porównanie z SFC i Windows Update.

DISM, SFC i Windows Update nie robią tego samego

Najwięcej nieporozumień widzę wtedy, gdy ktoś traktuje wszystkie trzy mechanizmy jak zamienniki. W rzeczywistości każde z nich dotyka innej warstwy problemu, więc kolejność ma znaczenie.

W praktyce najskuteczniejsza kolejność to najpierw naprawa magazynu składników, potem SFC. Odwracanie tej kolejności czasem daje wrażenie, że coś się udało, ale tylko maskuje głębszy problem. Gdy pracuję nie na działającym systemie, tylko na obrazie instalacyjnym, wchodzę już w zupełnie inny tryb.

Praca z obrazami offline i wdrożeniami

Gdy przygotowuję obraz instalacyjny, traktuję go jak zwykły katalog offline, który można zamontować, zmodyfikować i odmontować z zapisem. To właśnie tutaj narzędzie pokazuje pełną siłę: mogę dodawać funkcje, sterowniki, pakiety językowe, usuwać zbędne składniki i przygotowywać obraz do wdrożenia na kolejne maszyny.

1. Montuję obraz komendą Dism /Mount-Image /ImageFile:C:\images\install.wim /Index:1 /MountDir:C:\mount.
2. Wykonuję potrzebne zmiany na obrazie offline.
3. Stosuję naprawę lub modyfikacje na zamontowanym katalogu, używając Dism /Image:C:\mount ....
4. Odmontowuję obraz z zapisem: Dism /Unmount-Image /MountDir:C:\mount /Commit.

Ten tryb przydaje się przy budowie firmowych standardów, przygotowaniu reinstalacji albo serwisowaniu maszyn bez pełnego uruchamiania systemu. Ma jednak sens tylko wtedy, gdy rozumiem, na której warstwie pracuję, bo obraz offline i działający Windows nie zachowują się identycznie. Właśnie dlatego warto znać także ograniczenia, które najczęściej blokują naprawę.

Najczęstsze błędy i ograniczenia, które blokują naprawę

Najwięcej czasu tracę zwykle nie na samą naprawę, tylko na prosty błąd w założeniach. Gdy coś się nie udaje, sprawdzam przede wszystkim zgodność wersji, dziennik C:\Windows\Logs\CBS\CBS.log i to, czy system ma w ogóle skąd pobrać poprawne pliki.

• Brak uprawnień administratora - bez nich część poleceń po prostu nie ruszy.
• Zła wersja źródła naprawy - nośnik musi odpowiadać wydaniu, architekturze i najlepiej buildowi systemu.
• Za szybkie użycie /ResetBase - ta opcja potrafi utrudnić wycofanie aktualizacji.
• Mylenie awarii systemu z awarią sprzętu - uszkodzony dysk albo RAM dadzą podobne objawy, ale wymagają innego podejścia.
• Pomijanie logów - bez CBS.log trudno ustalić, co faktycznie się zepsuło.
• Próba naprawy nowszego obrazu starszym narzędziem - to ograniczenie wersji potrafi skutecznie zablokować cały proces.

To właśnie te drobiazgi najczęściej decydują, czy naprawa kończy się za pierwszym razem, czy zamienia się w serię nietrafionych prób. Po udanej naprawie zostaje już tylko kilka rzeczy, które warto zrobić, żeby problem nie wrócił.

Co robię po naprawie, żeby nie wracać do tego samego problemu

Po udanej naprawie zwykle nie zamykam tematu od razu. Uruchamiam aktualizacje, sprawdzam stan dysku i zapisuję, jakiego źródła użyłem do odtworzenia plików, bo ten szczegół później oszczędza kolejne minuty albo nawet godziny.

• sprawdzam, czy Windows Update działa bez błędów,
• weryfikuję, czy nie ma ponownych komunikatów o uszkodzeniu plików,
• kontroluję dysk i SMART, jeśli wcześniej pojawiały się objawy niestabilności,
• zostawiam sobie źródło naprawy zgodne z wersją systemu na przyszłość,
• robię kopię zapasową albo punkt przywracania, jeśli sytuacja tego wymaga.

Jeżeli mimo poprawnej procedury system dalej zwraca te same błędy, traktuję to jako sygnał ostrzegawczy, a nie zachętę do kolejnej identycznej próby. Wtedy szybciej opłaca się zweryfikować sprzęt, nośnik instalacyjny i historię aktualizacji niż liczyć na to, że następne uruchomienie zrobi różnicę.