Система, которая ещё вчера работала ровно, иногда начинает вести себя странно: программы вылетают без причины, отказывают штатные приложения, всплывают непонятные ошибки, а то и вовсе что-то перестаёт открываться. Нередко за этим стоит повреждение системных файлов - тех самых библиотек и компонентов, на которых держится сама Windows. Файл мог пострадать при сбое питания, неудачном обновлении, действии вредоноса или ошибке диска. Хорошая новость в том, что в системе есть штатные средства, которые умеют найти испорченные файлы и заменить их исправными, не прибегая к переустановке.
Двумя главными инструментами тут выступают проверка системных файлов и обслуживание образа системы. Первый сканирует защищённые системные файлы и восстанавливает повреждённые, второй чинит само хранилище эталонных компонентов, откуда первый берёт замену. Они работают в связке, и понимание того, как именно, отличает осмысленное лечение от беспорядочного запуска команд наугад. Грамотный администратор знает не только какие команды вводить, но и в каком порядке и почему.
Как Windows хранит эталонные копии своих файлов
Чтобы понять логику восстановления, нужно знать, откуда система берёт исправные файлы взамен испорченных. Windows держит у себя особое хранилище компонентов - набор эталонных копий системных файлов, спрятанный в служебных папках. Когда штатная проверка обнаруживает, что рабочий системный файл повреждён, она копирует его оригинальную версию именно из этого хранилища поверх испорченного. Таким образом восстановление - это не скачивание чего-то извне, а замена сломанного файла его же эталонной копией, хранящейся локально.
Отсюда вытекает неочевидное следствие. Если повреждено само хранилище компонентов, то проверке системных файлов попросту неоткуда брать исправные копии. Она находит повреждение, пытается его исправить, но эталон тоже испорчен, и замена не удаётся. Именно поэтому одной проверки системных файлов часто недостаточно: сначала нужно убедиться, что цел источник, из которого она черпает замену. Лечение хранилища компонентов - задача второго инструмента, обслуживания образа.
Этот двухуровневый порядок объясняет, почему запуск только одной команды иногда не помогает. Человек видит, что проверка нашла, но не смогла исправить файлы, и теряется. На деле это сигнал, что повреждено и само хранилище, и его надо чинить первым. Понимание двух уровней - рабочих файлов и эталонного хранилища - превращает набор разрозненных команд в осмысленную последовательность с понятной логикой.
Проверка системных файлов командой sfc
Первый и самый известный инструмент - проверка системных файлов, запускаемая командой sfc с ключом полного сканирования. Команда сканирует все защищённые системные файлы, сверяет их с эталонами и автоматически заменяет повреждённые исправными копиями из хранилища компонентов. Запускать её нужно из консоли с правами администратора, иначе доступа к системным файлам не будет.
sfc /scannowСканирование занимает несколько минут и завершается одним из нескольких вердиктов. Лучший исход - сообщение о том, что нарушений целостности не обнаружено, значит системные файлы в порядке. Если же повреждения нашлись и были устранены, появляется сообщение, что защита ресурсов обнаружила повреждённые файлы и успешно их восстановила. А вот третий вердикт тревожен: проверка нашла повреждённые файлы, но не смогла их восстановить - это и есть сигнал, что пора браться за хранилище компонентов.
После успешного восстановления полезно знать, что именно было исправлено. Подробный журнал работы проверки система ведёт в служебном файле, и из него можно выяснить, какие конкретно файлы оказались повреждены и заменены. Это пригодится, если повреждения повторяются: регулярная порча одних и тех же файлов намекает на более глубокую причину вроде сбойного диска, которую стоит искать отдельно.
Лечение хранилища компонентов инструментом dism
Когда проверка системных файлов не справилась, на сцену выходит инструмент обслуживания и развёртывания образов dism. Он умеет проверять и восстанавливать само хранилище компонентов, откуда при проверке целостности копируются оригинальные версии файлов. У него три ступени проверки и восстановления, идущие от лёгкой к тяжёлой.
Первая ступень - быстрая проверка, которая лишь сверяется с ранее записанными отметками о повреждении и срабатывает почти мгновенно. Вторая - углублённое сканирование, которое реально анализирует целостность хранилища и сообщает, есть ли повреждения и подлежат ли они восстановлению. Эти две команды только диагностируют, ничего не меняя.
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealthТретья и главная ступень - восстановление, которое не просто находит повреждения хранилища, но и чинит их. Команда восстановления пытается заменить повреждённые компоненты исправными, скачивая эталонные файлы из центра обновлений Windows. Именно эта команда лечит ту ситуацию, в которой проверка системных файлов оказалась бессильна.
DISM /Online /Cleanup-Image /RestoreHealthВосстановление хранилища может занять заметное время и иногда подолгу замирает на каком-то проценте - это нормально, процесс идёт. По завершении журнал своей работы инструмент тоже пишет в служебный файл, по которому можно разобрать ход восстановления, если что-то пошло не так.
Восстановление из локального источника, когда нет интернета
Команда восстановления по умолчанию тянет исправные файлы из центра обновлений, а значит, нуждается в интернете. Но бывает, что сеть недоступна, или сам центр обновлений не работает, и тогда восстановление проваливается. На этот случай инструменту можно явно указать локальный источник эталонных файлов - например, установочный образ Windows той же версии, что и установленная система.
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:6 /LimitAccessЗдесь источником назначен файл установочного образа на смонтированном носителе, а число в конце указывает на нужную редакцию внутри образа. Ключ ограничения доступа запрещает инструменту обращаться в интернет, заставляя брать файлы только из указанного локального источника. Это незаменимо в закрытых сетях и при ремонте машин без подключения, лишь бы версия образа точно совпадала с версией установленной системы.
Тот же подход доступен и через PowerShell, где у восстановления образа есть свой командлет с аналогичными параметрами.
Repair-WindowsImage -Online -RestoreHealthВыбор между классической командой и командлетом - дело привычки, результат одинаков: и тот и другой приводят хранилище компонентов в исправное состояние, после чего проверка системных файлов снова обретает надёжный источник для замены.
Отдельного упоминания заслуживает ситуация, когда система вообще не загружается, а чинить её надо. Тогда восстановление запускают из среды восстановления или с загрузочного носителя, в режиме работы с офлайн-образом. Команды при этом обзаводятся дополнительными ключами, указывающими, где лежит каталог системы и загрузочный раздел, ведь система не запущена и инструменты не могут определить это сами. Проверка системных файлов в офлайн-режиме принимает ключи, задающие путь к системной папке на ремонтируемом диске, и работает с ней так же, как работала бы с запущенной системой.
Правильный порядок команд и почему он именно такой
Самая частая ошибка при восстановлении - запускать команды в случайном порядке и удивляться, что не помогает. Между тем порядок строго логичен и вытекает из устройства двух уровней. Сначала чинят хранилище компонентов инструментом обслуживания образа, и только потом запускают проверку системных файлов, которая теперь сможет взять из исправного хранилища чистые копии. Запускать проверку до починки хранилища бессмысленно, если хранилище повреждено.
Полный осмысленный маршрут восстановления укладывается в понятную последовательность шагов:
- запустить проверку системных файлов и посмотреть на вердикт, ведь иногда этого одного и хватает;
- если проверка нашла, но не смогла исправить файлы, перейти к диагностике хранилища углублённым сканированием образа;
- при выявленных повреждениях хранилища запустить восстановление образа из сети или локального источника;
- после успешного восстановления хранилища повторно запустить проверку системных файлов, чтобы она заменила повреждённые рабочие файлы из уже исправленного хранилища;
- при необходимости заглянуть в служебные журналы обоих инструментов, чтобы понять, что именно чинилось;
- перезагрузить систему, чтобы все замены вступили в силу окончательно.
Такая последовательность не оставляет места случайности. Каждый шаг опирается на результат предыдущего, и вместе они закрывают как повреждения рабочих файлов, так и повреждения эталонного хранилища. Перезагрузка в конце важна, потому что часть файлов заменяется только при следующем запуске, когда они не заняты работающей системой.
Когда штатные средства не справляются
Иногда даже полный цикл восстановления не помогает: команда восстановления образа доходит до какого-то процента и срывается, а проверка системных файлов по-прежнему находит неисправимые повреждения. Это говорит о том, что повреждение глубже обычного, либо неисправен сам локальный источник, либо проблема выходит за рамки системных файлов. В таких случаях разумно сменить источник восстановления на заведомо исправный установочный образ нужной версии и повторить попытку с ним.
Стоит также проверить более фундаментальные причины. Если системные файлы повреждаются снова и снова после каждого восстановления, корень почти наверняка не в самих файлах, а в железе - чаще всего в сбойном накопителе, который портит данные при записи. Тогда восстановление файлов лечит симптом, а не болезнь, и пока не устранена аппаратная причина, повреждения будут возвращаться. Проверка диска на ошибки в такой ситуации важнее любого числа повторных запусков восстановления.
Крайняя мера, когда штатные средства исчерпаны, - восстановление системы из ранее сделанного образа или обновление системы с сохранением данных, при котором системные файлы переустанавливаются поверх. Но к ней прибегают лишь после того, как испробован полный цикл проверки и восстановления, потому что в подавляющем большинстве случаев связки двух штатных инструментов хватает. Они существуют именно для того, чтобы чинить систему без полной переустановки, и при верном порядке применения справляются с большинством повреждений.
Главное о восстановлении системных файлов
Если свести суть к одной мысли, она такова: восстановление системных файлов работает на двух уровнях, и лечить надо оба в правильном порядке. Сначала эталонное хранилище, потом рабочие файлы. Понимание этой двухуровневой логики снимает большую часть растерянности, которая возникает, когда одна команда не помогает и непонятно, что делать дальше.
Штатные инструменты Windows устроены так, чтобы система могла залечивать себя сама, опираясь на собственные эталонные копии. Это избавляет от драматичной переустановки в большинстве случаев повреждения файлов и возвращает систему к исправному состоянию за считанные минуты работы и одну перезагрузку. Нужно лишь знать порядок и не пугаться промежуточных вердиктов вроде неудачной попытки исправления - они не тупик, а указание на следующий шаг.
Зрелый подход к повреждённым системным файлам спокоен и методичен. Сначала диагностика, затем починка хранилища, затем замена рабочих файлов, в конце перезагрузка и проверка. А если повреждения упрямо возвращаются, взгляд переводится с файлов на железо, потому что чинить следствие, не устранив причину, означает обрекать себя на бесконечный повтор. Система способна восстановить себя сама, если дать ей исправный источник и приложить команды в верной последовательности.
Канал сайта в Telegram
Канал сайта на YouTube