Каталог System32 внутри установки Windows собран из тысяч взаимозависимых компонентов, и его целостность является тем фундаментом, на котором стоит всё остальное дерево запущенной системы. Разговор о том, что произойдёт при его удалении, интересен не как руководство к действию, а как диагностическая задача: архитектура операционной системы проявляет себя наиболее наглядно именно в момент, когда она начинает ломаться. Системный инженер, наблюдая за таким сценарием, видит не мгновенный взрыв, а медленно разворачивающийся каскад отказов, где каждый следующий обрыв связан с предыдущим по цепочке зависимостей. Разбираться в этом стоит по нескольким причинам: такой разбор учит понимать роль механизмов защиты ресурсов, логику загрузчика, природу мандатных блокировок файлов и поведение систем, которые теряют критичные зависимости под нагрузкой. Материал построен исключительно как технический анализ катастрофы, без каких-либо указаний по её воспроизведению.
Что физически хранится внутри System32 и почему каталог незаменим
System32 это гораздо больше, чем папка с библиотеками. Внутри живут нативные библиотеки уровня ядра пользовательского режима, прежде всего ntdll.dll, через которую проходит каждый системный вызов из любого процесса. Любой вызов Win32-функции в конечном счёте уходит в ntdll, а та формирует переход в режим ядра через инструкцию syscall. Рядом лежат kernel32.dll и kernelbase.dll, реализующие API работы с памятью, процессами, файлами и синхронизацией, а также user32.dll и gdi32.dll, отвечающие за окна и графику. Удалить эти файлы означает выдернуть опорные стойки из-под всего пользовательского режима сразу.
Далее идут исполняемые файлы другого класса серьёзности. smss.exe, Session Manager Subsystem, это первый пользовательский процесс, который запускает загрузчик ядра при старте; он создаёт сессии, запускает клиент-серверную подсистему csrss.exe и менеджер входа winlogon. csrss.exe относится к критическим процессам: ядро помечает его флагом, и ненормальное завершение такого процесса инициирует STOP-ошибку 0xEF CRITICAL_PROCESS_DIED. Образ svchost.exe обслуживает сотни системных служб, упакованных в DLL и запускаемых под его крышей по параметрам из реестра. Без svchost не живут сетевой стек, планировщик заданий, аудио, Windows Update.
Третий слой это подкаталог drivers с драйверными образами .sys: ntfs.sys, tcpip.sys, classpnp.sys, драйверы дисков, видео, USB. Четвёртый слой это утилиты командной строки и диагностики, от cmd.exe до chkdsk.exe и sfc.exe, то есть сами инструменты починки. Наконец, config содержит ульи реестра: SYSTEM, SOFTWARE, SAM, SECURITY. Реестр это база данных конфигурации ядра и всех служб, и его потеря эквивалентна потере памяти о том, как система вообще устроена.
Слои защиты TrustedInstaller и Windows Resource Protection
Архитекторам Windows было очевидно, что каталог такого значения нельзя доверять даже администратору. Поэтому владельцем критических файлов поставлена служебная учётная запись TrustedInstaller, SID которого не относится ни к одному живому пользователю, а именно этой записи выданы полные DACL-права. У группы Administrators и даже у встроенной SYSTEM остаются в основном чтение и выполнение. Попытка стирания файла, защищённого таким дескриптором безопасности, завершается упломом отказа в доступе, и обход этой схемы требует смены владельца объекта и правки DACL, что само по себе уже выходит за рамки любого штатного сценария.
Второй слой это Windows Resource Protection, наследница Windows File Protection времён Windows 2000. WRP ведёт кэш эталонных копий защищённых файлов в WinSxS и связанных каталогах, а службы восстановления умеют вернуть целостную версию из хранилища компонентов. Планировщик регулярно запускает задачу проверки целостности, а инструмент sfc /scannow ходит именно по списку, который WRP считает обязательным. Файл, физически исчезнувший из System32, но имеющий сигнатурную копию в хранилище, восстанавливается при первой же проверке, и пользователь может даже не заметить инцидента, если разрушена была малая часть.
Третий, самый неочевидный слой защиты устроен на уровне подсистемы файлового ввода-вывода. Windows использует мандатные блокировки доступа к открытым файлам: когда исполняемый образ загружен в память как секция image, менеджер памяти держит на него ссылку, и попытка удалить такой файл через разделяющий доступ вызывает STATUS_SHARING_VIOLATION, код 0xC0000043. Запущенный smss.exe, csrss.exe, svchost.exe и загруженные DLL именно так и заперты: дескриптор секции открыт, режим совместного доступа не включает FILE_SHARE_DELETE, и стереть их из под живой системы нельзя штатными вызовами API. Это тот же принцип, по которому нельзя снести на исполняющемся сервере бинарный файл, чей процесс на нём работает, только Windows применяет его жёстче и без POSIX-семантики отложенного удаления.
Почему система живёт после потери части файлов и что успевает стереться при обходе защит
Парадокс сценария состоит в том, что старые и работающие экземпляры кода в памяти не нуждаются в своих файлах на диске. Системный вызов, законченный загрузкой DLL в адресное пространство процесса, не требует дёргать диск повторно: маппированные страницы обслуживаются страничной памятью. Менеджер памяти выгружает неизменённые страницы образа под давлением, потому что знает, где взять их снова, и именно здесь накапливается бомба замедленного действия: чтение выгруженной страницы из уже отсутствующего файла обернётся внутристраничной ошибкой, которую нельзя разрешить, и процесс рухнет с нарушением доступа при следующем обращении к этой области кода. До того момента, однако, кэш страниц и pagefile продлевают агонию: страницы, исписанные выгрузкой в файл подкачки, читаются оттуда, и система с наполовину стёртым System32 может десятки минут выглядеть почти живой.
Если же представить сценарий, когда все слои защиты были сняты тем или иным способом и стирание пошло, в первую очередь исчезают неоткрытые файлы: драйверы .sys, не загруженные сейчас в память, утилиты, шаблоны, манифесты, cat-файлы каталога безопасности, часть DLL узкого назначения. Система не падает сразу - падают функции. Перестаёт открываться новое окно приложения, потому что загрузчик LdrLoadDll не находит импорт; lsass светится ошибками при попытке аутентификации; проводник зависает на отрисовке. Процессы, чьи зависимости сохранились полностью в памяти, продолжают шевелиться, что создаёт обманчивое ощущение выжившей системы.
Каскад запускается тогда, когда умирает первый критический процесс. Невозможность создать новый процесс, потому что ntdll или kernel32 недоступны из дискового образа, ломает и ветку обслуживания системы: дочерний процесс, который по сценарию обязан подняться, не стартует, родитель ловит timeout и пишет в журнал Event ID одну за другой. При потере или аварийном завершении csrss.exe или smss.exe ядро безальтернативно останавливает всю машину, выбрасывая синий экран CRITICAL_PROCESS_DIED с кодом 0x000000EF. Утилиты, пытающиеся починить систему, сами сидят внутри удалённого каталога: sfc.exe, dism.exe, powershell лежат там же, и команды починки нечем выполнить. Система умирает не мгновенно, а диагонально по дереву зависимостей - как отказ кластера, где сначала отваливается второстепенный сервис, потом сквозная аутентификация, потом координационные задачи и лишь в конце сам наблюдатель.
Загрузка после перезагрузки и роль winload и WinRE
До перезагрузки разрушение частично компенсируется страничной памятью, но сама перезагрузка становится точкой невозврата. Цепочка старта устроена так: UEFI загружает bootmgfw.efi из системного раздела EFI, тот читает BCD-хранилище и вызывает winload.efi, который лежит уже внутри System32. Именно winload.efi отвечает за загрузку ntoskrnl.exe, hal.dll, куста реестра SYSTEM из каталога config и набора драйверов, помеченных как boot-start. Потеря winload.efi или любого из этих файлов выбивает старт: на экране появляется либо ошибка 0xc000000e «требуемое устройство недоступно», либо 0xc000000f о том, что winload.efi отсутствует или повреждён, либо бесконечный цикл автоматического восстановления. Если дело доходило и до ульев config, ядро при раннем старте падает со STOP 0x74 BAD_SYSTEM_CONFIG_INFO, потому что не смогло открыть или разобрать куст SYSTEM.
Резервные механизмы существуют и очень недурственны. Среда восстановления Windows RE живёт в отдельной wim-копии на отдельном разделе и работает из RAM-диска: она способна восстановить загрузочные файлы, выполнить sfc и dism в офлайн-режиме против лежащей установки, воспользоваться точками восстановления и откатом обновлений. Точки восстановления держат теневые копии системных файлов и реестра через VSS, и до тех пор, пока теневое хранилище цело, откат реально извлекает систему даже из глубокого разрушения System32. Пределы тоже есть: если удаление затронуло сами файлы WinRE, проломило теневое хранилище или раздел EFI, офлайн-ремонт уже потребует установочного носителя и переустановки с сохранением данных либо без. В профессиональной практике вывод прост: у живой резервной копии ценность выше, чем у самых красивых механизмов внутреннего восстановления.
Архитектурные выводы из сценария удаления System32
Разбор этого сценария даёт несколько уроков, применимых далеко за пределами экзотического эксперимента.
- Цепочка зависимостей описывает надёжность системы точнее, чем сумма надёжностей компонентов. Файл не важен сам по себе - важно его место на графе: ntdll сидит у всех путей, winload на единственной загрузочной нитке, куст SYSTEM кормит параметры десятков драйверов, и обрыв в этих узлах недопустим, тогда как потеря утилиты второго плана переживается незаметно.
- Возраст кода и механизм его загрузки определяют, когда именно отказ проявится. Страничная память и кэш маскируют разрушение на время, но чем дольше работает система в таком полуживом состоянии, тем шире блуждающее повреждение в логах, кэшах и несохранённых данных.
- Иерархия защитных слоёв, от DACL до WRP и мандатных блокировок, строит оборону в глубину, где каждый уровень работает против своего класса ошибок, и оператору важно понимать, каким именно слоем сейчас ограждён ресурс.
- Доступные инструменты починки должны быть физически отделены от дирижабля, который чинят: WinRE на отдельном разделе и установочный носитель иллюстрируют правило, что аварийный комплект складывают вне зоны возможного разрушения.
Кому нужен этот опыт на практике. Знание механики разрушения помогает двум профессиям сразу. Администратор восстановления читает симптомы как карту: если система грузится, но не запускает процессы, дело во вторичных цепочках; если загрузка прерывается на раннем экране - ищи проблему в winload или в контроллере диска. Разработчик антивируса или инсталлятора учится на ней обратному: важность staged-write (сначала новая версия целиком, потом атомарная замена), невозможность редактирования файлов внутри защищённых каталогов без последствий, способы регистрации компонентов в реестре компонентов, а не прямыми манипуляциями. Даже автор собственного сервиса здоровее представляет себе приоритет зависимостей, когда видел, что начинает ломаться первым, а что держится до конца.
Наблюдение за тем, как Windows умирает, даёт сильное образование по архитектуре: видна роль менеджера памяти, поведение секций образов, логика загрузчика, экономика реестра и историческая эволюция защиты от пользователя-администратора. Система, выстроенная так, что мельчайший файл может оказаться на её опорном пути, и система, в которой десятки согласованных механизмов защищают этот путь месяцами напролёт, это одна и та же система, и разбирать её стоит именно в этой двойственности.