2.01. Устройство файловой системы Windows

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ

Разработчику Архитектору Инженеру

Устройство файловой системы Windows

Проводник и абстракция файловой системы

Файловая система Windows — это сложный многоуровневый механизм, реализующий семантическую и техническую структуру хранения данных в операционной среде. Визуальное представление этой структуры пользователю предоставляется через Проводник (Explorer) — стандартное приложение оболочки Windows, являющееся не только инструментом навигации, но и ключевым элементом интеграции файловой системы с интерфейсом пользователя.

Проводник работает с логическим пространством имён, в которое входят:

• традиционные дисковые корни (C:\, D:\ и т.д.),
• виртуальные папки («Рабочий стол», «Этот компьютер», «Сеть», «Панель управления»),
• библиотеки («Документы», «Изображения», «Музыка»),
• пространства подключения облаков и внешних хранилищ (OneDrive, SharePoint, WebDAV),
• папки перенаправления (Folder Redirection),
• оболочечные расширения (Shell Extensions), регистрируемые через COM и реализующие кастомные узлы дерева.

Проводник — это клиент интерфейса Shell Namespace, а не прямой «просмотрщик диска». Сами же логические имена файлов и папок в Windows преобразуются в физические пути через механизм Object Manager Namespace ядра (\??\, \Device\, \GLOBAL??\ и пр.), но этот уровень трансляции скрыт от пользователя и даже от большинства приложений.

Файловая система Windows, в подавляющем большинстве случаев, форматируется как NTFS (New Technology File System) — основная файловая система, разработанная для Windows NT, и последовательно развивающаяся с 1993 года. NTFS обеспечивает поддержку:

• метаданных (временные метки, атрибуты, ACL),
• журналирования изменений (ускоряет восстановление после сбоев),
• жёстких и символьных ссылок (junction, symlink),
• точек повторного анализа (reparse points), используемых для монтирования VHD, облаков, OneDrive Files On-Demand и т.п.,
• альтернативных потоков данных (ADS),
• шифрования (EFS),
• сжатия,
• квот,
• репарс-тегов, задействуемых в механизмах виртуализации приложений (App-V, MSIX).

Важно понимать: даже если диск отформатирован как exFAT или FAT32 (например, для флешки), в системных разделах Windows только NTFS. Системные файлы требуют функций NTFS — без них невозможна загрузка.

---

Стандартные каталоги верхнего уровня

Стандартная структура корня системного диска (обычно C:\) включает ряд предопределённых каталогов, каждый из которых имеет чёткое назначение, закреплённое документацией Microsoft, и поддерживаемое самой ОС и экосистемой ПО.

inetpub

Каталог inetpub (Internet Publishing) — историческое наследие времён Windows NT 4.0 и IIS 4.0. Является корневой папкой по умолчанию для служб Internet Information Services (IIS). Внутри находятся подкаталоги:

• wwwroot — корневой каталог веб-сайта по умолчанию,
• admin — скрипты администрирования IIS (в старых версиях),
• logs — логи HTTP-запросов и ошибок,
• ftproot — корень FTP-сервера, если включён.

Хотя современные развёртывания IIS часто используют нестандартные пути, inetpub остаётся символом интеграции Windows с веб-стеком и часто встречается при развёртывании ASP.NET-, PHP- или Node.js-приложений на Windows Server.

OneDriveTemp

Временная папка синхронизации OneDrive — используется клиентским агентом OneDrive для хранения файлов в процессе загрузки или выгрузки. Содержимое нестабильно, может быть очищено автоматически, и не предназначено для прямого доступа. Часто содержит фрагменты файлов (.tmp, .partial) и журналы синхронизации.

PerfLogs

Каталог PerfLogs (Performance Logs) — место хранения журналов производительности, собираемых средствами Performance Monitor (perfmon.exe) и Windows Performance Recorder (wpr.exe). Это в первую очередь файлы в формате .blg (binary log), а также их XML-эквиваленты и метаданные. Логи используются для анализа:

• загрузки CPU, диска, памяти,
• задержек ввода-вывода,
• проблем с десериализацией,
• блокировок потоков.

По умолчанию логи не ведутся — только при явной настройке сценариев сбора.

Program Files и Program Files (x86)

Эти каталоги — основные репозитории установленных приложений для 64- и 32-битных архитектур соответственно.

• Program Files — место для 64-битных приложений. Все приложения, скомпилированные под x64 или ARM64, устанавливаются сюда.
• Program Files (x86) — для 32-битных (x86) приложений, запускаемых в эмуляционном режиме WOW64 (Windows-on-Windows 64-bit).

Важно: эти каталоги защищены контролем учётных записей (UAC) и доступом по ACL — запись в них возможна только от имени администратора или через installer-механизмы (MSI, ClickOnce, AppX). Самописные программы, пытающиеся писать сюда напрямую, провоцируют ошибки прав и снижают безопасность.

Каждое приложение внутри обычно размещается в своей подпапке, с иерархией bin\, lib\, data\, config\ и т.д. Отсутствие единого стандарта внутри этих каталогов — одна из причин, почему Windows исторически страдала от «разбросанности» конфигураций.

Users

Каталог Users — центральное хранилище профилей пользователей. Каждая учётная запись (локальная или доменная) имеет здесь собственную папку, название которой совпадает с именем пользователя (например, C:\Users\Тимур). Внутри находятся:

• Desktop — Рабочий стол,
• Documents, Pictures, Videos, Music — библиотеки по умолчанию,
• Downloads — папка для скачанных файлов,
• AppData — скрытая папка, хранящая настройки и данные приложений (подробнее ниже),
• NTUSER.DAT — системный hive-файл реестра текущего пользователя (загружается при входе в сессию),
• ntuser.dat.LOG1, ntuser.dat.LOG2 — журналы изменений для восстановления hive.

Пользовательские профили могут быть:

• локальными (хранятся только на машине),
• блуждающими (roaming profile — синхронизируются с доменным контроллером),
• обязательными (mandatory — доступны только для чтения, часто в корпоративах),
• временными (temporary — создаются при проблемах с загрузкой основного профиля).

Windows

Корневой каталог операционной системы — C:\Windows — является центральной точкой размещения всех системных компонентов: ядра, драйверов, служб, оболочки, инструментов диагностики. Содержимое этого каталога строго регламентировано, и прямое вмешательство в него без понимания архитектуры ОС чревато нестабильностью.

Однако прежде чем перейти к Windows, кратко упомянем другие системные папки верхнего уровня.

Windows.old

Папка Windows.old создаётся автоматически при обновлении Windows (например, с 21H2 на 22H2), если старая система сохраняется для отката. Внутри — полная копия предыдущей установки Windows, включая /Windows, /Program Files, /Users, а также boot-секторы и загрузчики. Она занимает десятки гигабайт, и после подтверждения стабильности обновления может быть удалена через «Очистку диска» → «Очистить системные файлы» → «Предыдущие установки Windows».

Важно: Windows.old не создаётся при чистой установке — только при обновлении «поверх».

WindowsApps

WindowsApps — это скрытая и защищённая папка, являющаяся физическим местом хранения пакетов MSIX / AppX, установленных через Microsoft Store (или enterprise-каналы). Расположена по пути C:\Program Files\WindowsApps, но права доступа к ней ограничены — даже администратор по умолчанию не может её открыть без изменения ACL.

Внутри — иерархия папок вида PackageName_PublisherId_Version_arch__Hash, где каждый пакет развёрнут в свой sandbox. Каждый такой пакет — это ZIP-архив с манифестом (AppxManifest.xml), метаданными, исполняемыми файлами и ресурсами. Запуск приложения происходит через AppX Deployment Service, который создаёт виртуальную файловую среду, скрывающую реальный путь.

---

Содержимое каталога Windows

Каталог C:\Windows — это единая экосистема, объединяющая ядро, драйверы, службы, пользовательский интерфейс, инструменты диагностики и конфигурационные данные. Его структура не возникла случайно: она эволюционировала от первых версий NT (1993) и отражает десятилетия развития Windows как корпоративной и клиентской платформы. Ниже — разбор ключевых подкаталогов и файлов с указанием их назначения, архитектурной роли и взаимосвязей.

ADAM

ADAM (Active Directory Application Mode) — устаревшее имя для AD LDS (Active Directory Lightweight Directory Services). Каталог содержит бинарные файлы и схемы для развёртывания локального LDAP-совместимого хранилища, не требующего полного домена AD. Используется в сценариях, где нужна лёгкая директория для аутентификации (например, веб-приложения на IIS). В современных версиях Windows (Windows Server 2016+, Windows 10 1809+) ADAM отсутствует — заменён на AD LDS, устанавливаемый как роль.

appcompat

Подкаталог appcompat содержит данные механизма совместимости приложений (Application Compatibility Toolkit, ACT). Здесь хранятся:

• AppCompatCache.bin — кэш совместимости, анализируемый при запуске приложений (тот самый «Shim Cache»),
• базы sdb-файлов — подписанные базы правил совместимости (Shim Databases),
• логи диагностики совместимости.

Этот каталог используется службой AppReadiness, а также CompatTelRunner.exe — компонентом Diagnostics Tracking Service, который собирает данные для Microsoft Compatibility Telemetry.

apppatch

Папка apppatch — физическое хранилище патчей совместимости (shim-патчей), применяемых к исполняемым файлам без их перекомпиляции. Каждый патч — это DLL, инжектируемая в адресное пространство целевого процесса через механизм Application Verifier или через записи в реестре (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom). В отличие от appcompat, apppatch содержит не метаданные, а непосредственно код коррекции поведения API.

AppReadiness

AppReadiness — служебный каталог, используемый службой App Readiness (AppReadiness.dll, svchost.exe -k wsappx). Эта служба управляет фоновыми задачами подготовки системы к обновлениям Windows и развёртыванию MSIX-пакетов:

• предварительная загрузка и проверка целостности обновлений,
• индексация манифестов приложений,
• кэширование метаданных ресурсов.

Каталог содержит AppReadiness.etl (ETW-трасса), AppReadiness.db (локальная база SQLite/ESent), и временные папки вида Package_XXXX.

assembly

assembly — это GAC (Global Assembly Cache) — хранилище общих .NET-сборок, доступных всем приложениям на машине. Содержимое зависит от установленных версий .NET Framework:

• GAC_32, GAC_64 — 32- и 64-битные сборки,
• GAC_MSIL — нейтральные по архитектуре сборки (AnyCPU),
• NativeImages_vX.Y.Z — предварительно скомпилированные образы (ngen), ускоряющие запуск.

После .NET Core и .NET 5+ GAC больше не используется — сборки развёртываются side-by-side или через dotnet SDK, но assembly остаётся для обратной совместимости.

bcastdvr

bcastdvr (Broadcast DVR) — каталог службы Broadcast DVR Server, отвечающей за запись игрового стриминга (Game Bar, Xbox Game DVR). Он содержит:

• конфигурации кодеков и резолюций,
• временные файлы сегментов записи (.mp4, .ts),
• метаданные сессий (session.json, manifest.xml).

Служба bcastdvruserservice (пользовательская) и BcastDVRBroker (системная) используют этот каталог для взаимодействия с GameBarPresenceWriter.exe.

Boot

Boot — критически важный каталог, содержащий файлы загрузчика Windows Boot Manager (BOOTMGR) и данные BCD (Boot Configuration Data):

• bootmgr — начальный загрузчик (ранее NTLDR),
• BCD — база конфигурации загрузки (внутри — %SystemRoot%\Boot\BCD),
• memtest.exe — встроенный тест оперативной памяти,
• fonts\ — шрифты загрузочного экрана (.ttf, .fon),
• Resources\ — локализованные ресурсы (строки, изображения).

Манипуляции с этим каталогом требуют повышенных привилегий и инструментов bcdedit.exe, bcdboot.exe. Повреждение BCD делает систему незагружаемой.

Branding, ShellExperiences, ImmersiveControlPanel

Эти каталоги относятся к визуальному оформлению и UX-слою Windows 10/11:

• Branding — корпоративные и OEM-брендированные ресурсы: обои, логотипы, звуки при входе/выходе,
• ShellExperiences — XAML-ресурсы и DLL для современного интерфейса: панель задач, меню «Пуск», Центр уведомлений, виджеты,
• ImmersiveControlPanel — реализация панели управления в стиле UWP (SettingsApp), заменяющая классическую control.exe.

Все они содержат .pri-файлы (Package Resource Index), .xbf (скомпилированные XAML), и бинарные оболочки, загружаемые SIHost.exe, ShellExperienceHost.exe.

CbsTemp, Logs, Panther, Setup

Группа каталогов, связанная с установкой, обновлением и восстановлением ОС:

• CbsTemp — временные файлы для Component Based Servicing (CBS). Используются при установке обновлений через DISM, wusa.exe, Windows Update. Удаляются автоматически после завершения.
• Logs — централизованное хранилище системных журналов:
  • CBS.log — лог компонентного обслуживания,
  • DISM.log — лог DISM-операций,
  • Msi*.log — установщики MSI,
  • NetSetup.log — присоединение к домену.
• Panther — журналы установки Windows (setupact.log, setuperr.log). Здесь фиксируется каждый шаг setup.exe, включая этапы auditUser, oobeSystem. Критичен для диагностики неудачных развёртываний.
• Setup — файлы конфигурации развёртывания: unattend.xml, Autounattend.xml, кастомные ответные файлы.

Containers

Containers — физическое размещение Windows Server Containers и Hyper-V Isolated Containers. Содержит:

• Hives\ — hive-файлы реестра контейнеров,
• LayerDB\ — метаданные слоёв образов (аналог layerdb в Docker),
• Volatile\ — временные тома.

В отличие от Linux, где контейнеры — процессы в изолированных пространствах имён, контейнеры Windows — это процессы в изолированных экземплярах svchost.exe, управляемых vmcompute.exe и hostguardianservice.

CSC (Client-Side Caching)

CSC — каталог офлайн-файлов, используемый технологией Offline Files (CSC — Client Side Caching). Здесь хранятся:

• локальные копии сетевых папок (SMB-шар),
• метаданные синхронизации (cscdb),
• журналы конфликтов.

Включается через \\server\share → Свойства → «Всегда доступно автономно». Управляется службой CscService.

Fonts

Fonts — системное хранилище установленных шрифтов. Windows не копирует шрифты в приложения — все процессы получают доступ к общему C:\Windows\Fonts. Форматы:

• .ttf (TrueType),
• .otf (OpenType),
• .woff2 (веб-шрифты, начиная с Windows 10 20H1),
• .fon (растровые шрифты — legacy).

Добавление шрифта — просто копирование в эту папку (с правами SYSTEM); удаление — через fontview.exe. Шрифтовый кэш (C:\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache\) ускоряет перечисление.

Globalization

Globalization — данные локализации и региональных настроек:

• sortdefault.nls, sorttbls.nls — таблицы сортировки (collation),
• locale.nls — локальные настройки (дата, валюта, число),
• nls-файлы — NLS (National Language Support) данные.

Эти файлы используются kernelbase.dll, normaliz.dll, shlwapi.dll для локализованных операций строк, дат и чисел. Например, сортировка файлов в Проводнике зависит от sortdefault.nls.

Help

Help — устаревшее хранилище справки в формате CHM (Compiled HTML Help) и HxS (Help 2.x). В современных Windows заменено на онлайн-документацию (support.microsoft.com), но каталог остаётся для совместимости. Файлы:

• windows.hxs — основная справка Windows SDK,
• netfw.hxs — справка по брандмауэру,
• shell.hxs — API оболочки.

Запускается через HelpPane.exe, hh.exe.

INF

INF — каталог системных INF-файлов, описывающих драйверы и компоненты. Здесь лежат:

• layout.inf — карта всех файлов Windows (используется sysocmgr, syssetup),
• net*.inf — драйверы сетевых адаптеров,
• input.inf — HID-устройства,
• usb.inf, usbport.inf, usbaudio.inf — USB-стек.

Инфраструктура Plug and Play читает эти файлы при подключении устройств. Пользовательские INF-файлы обычно не сюда — в %SystemDrive%\Drivers\ или в папку драйвера.

L2Schemas

L2Schemas — схемы уровня 2 политик безопасности, используемые в Security Policy Snap-in (secpol.msc) и Group Policy. Файлы .xsd и .policy описывают:

• права пользователей (User Rights Assignment),
• параметры аудита (Audit Policy),
• параметры безопасности (Security Options).

Транслируются в записи реестра (HKLM\SOFTWARE\Policies\Microsoft\Windows), но схемы обеспечивают строгую типизацию и валидацию.

Microsoft.NET

Microsoft.NET — корневой каталог .NET Framework, установленного как часть ОС. Содержит:

• Framework\ — 32-битные версии (.NET 2.0–4.8),
• Framework64\ — 64-битные версии,
• assembly\ — GAC (уже упоминалось),
• NGen\ — образы native images.

Важно: .NET Core / .NET 5+ не устанавливаются сюда — они side-by-side в %ProgramFiles%\dotnet\.

Prefetch

Prefetch — кэш трасс загрузки приложений, используемый SuperFetch (в Windows 10 заменён на SysMain). Здесь хранятся:

• .pf-файлы — бинарные профили запуска (что, когда, в каком порядке читается с диска),
• ReadyBoot\ — профили загрузки ОС (для SSD/HDD оптимизации).

Очистка этой папки не ускоряет систему — SuperFetch перестроит кэш. На SSD SuperFetch отключён по умолчанию.

Registration

Registration — метаданные COM-классов и интерфейсов, зарегистрированных на системном уровне. Содержит:

• CRMLog\ — Component Registration Manager — журнал регистрации COM-компонентов,
• R000000000001.clb — кэш registration database (CLB — COM Library Binary),
• Assemblies\ — манифесты Side-by-Side (SxS) сборок.

При вызове regsvr32.exe или DllRegisterServer обновляется именно этот каталог, а не реестр напрямую (хотя реестр тоже обновляется как кэш).

rescache, Resources

rescache и Resources — кэши локализованных ресурсов (строки, иконки, диалоги):

• rescache\ — бинарные кэши .mui-файлов (MUI — Multilingual User Interface),
• Resources\ — ресурсы оболочки, UWP-приложений.

Каждая DLL с локализацией (kernel32.dll.mui, user32.dll.mui) имеет копию в C:\Windows\System32\<lang>\. При смене языка интерфейса обновляется rescache.

SchCache

SchCache — кэш запланированных задач (Task Scheduler). Содержит:

• *.job — старые задачи (до Windows Vista),
• *.xml — задачи в формате Task Scheduler 2.0,
• TaskScheduler.xml — индекс.

Задачи из C:\Windows\System32\Tasks\ компилируются и кэшируются сюда для быстрого запуска.

security

security — локальная база безопасности (Security Accounts Manager) вне домена:

• database\ — файл SECURITY (hive реестра),
• logs\ — журналы изменений ACL,
• templates\ — шаблоны политик безопасности (.inf).

Управляется через secedit.exe, secpol.msc. В домене используется Active Directory, но локальная база остаётся для built-in аккаунтов (Administrator, Guest).

ServiceProfiles

ServiceProfiles — профили учётных записей служб, аналогичные C:\Users, но для системных аккаунтов:

• LocalService\ — профиль NT AUTHORITY\LocalService,
• NetworkService\ — профиль NT AUTHORITY\NetworkService,
• LocalSystem\ — профиль NT AUTHORITY\SYSTEM (на самом деле — виртуальный, данные в HKLM\SYSTEM\CurrentControlSet\Control\hivelist).

Службы, выполняемые от имени этих аккаунтов, имеют здесь AppData, NTUSER.DAT, Cookies, Local Settings.

servicing

servicing — ядро Component Based Servicing (CBS) — механизма установки обновлений на уровне компонентов:

• Packages\ — все установленные CAB-пакеты (Package_for_KBXXXXXX~...),
• Version\ — версии компонентов (manifests, catalogs),
• LCU\, SSU\ — кэш последних Cumulative и Servicing Updates.

Инструменты DISM /Online /Cleanup-Image, sfc /scannow работают именно с этим каталогом.

SoftwareDistribution

SoftwareDistribution — рабочая область Windows Update:

• Download\ — загруженные .cab, .msu-файлы,
• DataStore\ — база данных обновлений (SQL Compact),
• SelfUpdate\ — клиент обновления (wuaueng.dll, wuapi.dll),
• ReportingEvents.log — лог отправки телеметрии.

Очистка Download\ освобождает место, но не сбрасывает статус обновлений — только net stop wuauserv && rd /s SoftwareDistribution.

System32 и SysWOW64

Эти каталоги вынесем в отдельный подраздел — они заслуживают особого внимания.

---

Каталог System32: архитектурная роль и содержимое

C:\Windows\System32 — основной каталог системных библиотек и исполняемых файлов 64-битной архитектуры на 64-битных версиях Windows. Несмотря на название, не следует полагать, что здесь находятся 32-битные компоненты — наоборот, исторически System32 был корневым каталогом 32-битной NT, и при переходе на x64 Microsoft сохранил имя для обратной совместимости. 32-битные аналоги размещаются в SysWOW64.

Система обеспечивает трансляцию путей через файловую перенаправку (File System Redirection): 32-битное приложение, обращающееся к System32, автоматически перенаправляется в SysWOW64 ядром через wow64.dll. Отключить перенаправку можно вызовом Wow64DisableWow64FsRedirection, но это требует осторожности.

Архитектурная структура System32

Каталог можно условно разделить на следующие группы:

1. Ядро Win32 API и базовые системные DLL

Эти файлы предоставляют непосредственный интерфейс к ядру ОС и являются основой для всех пользовательских приложений:

• ntdll.dll — низкоуровневая обёртка над системными вызовами NT (Nt* и Zw* функции), загружается первой в каждый процесс.
• kernel32.dll, kernelbase.dll — основа Win32: управление процессами, потоками, памятью, файлами, синхронизацией.
• user32.dll, gdi32.dll, gdi32full.dll — управление окнами, вводом и графикой 2D.
• advapi32.dll — расширенные API: реестр, безопасность (ACL, SIDs), службы, криптография.
• combase.dll, ole32.dll, oleaut32.dll — реализация COM и автоматизации.
• ws2_32.dll, iphlpapi.dll, dnsapi.dll — сетевой стек Winsock и вспомогательные функции.
• msvcrt.dll, ucrtbase.dll — стандартная библиотека C (CRT): malloc, printf, fopen.

Эти DLL не являются «статическими» библиотеками — они динамически связаны и обновляются через компонентное обслуживание (CBS). Изменение их содержимого вручную ведёт к нестабильности и блокировке загрузки.

2. Интерфейсы подсистем и расширенных API

• shell32.dll, shcore.dll, shlwapi.dll, propsys.dll — API оболочки (Shell): ярлыки, библиотеки, свойства файлов, Common Item Dialogs.
• setupapi.dll, cfgmgr32.dll, devmgr.dll — управление оборудованием: перечисление устройств, установка драйверов.
• wlanapi.dll, netapi32.dll, mpr.dll — управление сетью: Wi-Fi, домены, общие ресурсы.
• crypt32.dll, ncrypt.dll, bcrypt.dll, rsaenh.dll — криптографический стек (CNG, CryptoAPI).
• d3d11.dll, dxgi.dll, d2d1.dll, dwrite.dll — графические API DirectX и Direct2D/DirectWrite.

Все эти интерфейсы строго версионированы, и их контракты (signature, calling convention, структуры данных) являются частью Windows SDK, гарантируя обратную совместимость на уровне двоичного кода.

3. Системные исполняемые файлы — утилиты администрирования

Это исполняемые файлы командной строки и графические инструменты, используемые как администраторами, так и системными службами:

• cmd.exe, conhost.exe — интерпретатор команд и его хост-контейнер (для изоляции консоли).
• reg.exe, regedit.exe — работа с реестром через CLI и GUI.
• sc.exe, schtasks.exe, taskkill.exe, tasklist.exe — управление службами и процессами.
• net.exe, ipconfig.exe, ping.exe, tracert.exe, nslookup.exe, netsh.exe — сетевые диагностические утилиты.
• diskpart.exe, chkdsk.exe, fsutil.exe, robocopy.exe — управление дисками и файловой системой.
• cipher.exe, icacls.exe, whoami.exe, runas.exe — управление безопасностью и правами доступа.
• dism.exe, sfc.exe, wusa.exe, winsta.exe — обслуживание компонентов, восстановление и обновление системы.

Многие из этих утилит не имеют отдельного GUI-интерфейса и используются в скриптах, групповых политиках, задачах планировщика и CI/CD-пайплайнах.

4. Интерфейсы COM-объектов и proxy/stub

• activeds.dll, adsldp.dll — Active Directory Service Interfaces (ADSI).
• wbemcomn.dll, wmi.dll, fastprox.dll — инфраструктура WMI.
• mshtml.dll, urlmon.dll, wininet.dll — компоненты Trident (движка IE/Edge Legacy), включая IWebBrowser2, IHTMLElement.
• scrrun.dll, vbscript.dll, jscript.dll, jscript9.dll — среды выполнения скриптов (VBScript, JScript, Chakra).
• atl.dll, mfc*.dll — фреймворки для нативной разработки (ATL, MFC).

COM-объекты регистрируются через regsvr32.exe, который вызывает DllRegisterServer, но на самом деле данные регистрации хранятся не только в реестре — метаданные COM-классов также кэшируются в C:\Windows\Registration.

5. Драйверы пользовательского режима (UMDF) и фильтры

• winusb.dll, hid.dll, setupapi.dll — взаимодействие с USB-, HID-устройствами.
• d3d*.dll, dxgi.dll, opencl.dll, vulkan-1.dll — драйверы графики в пользовательском режиме.
• msacm32.dll, wdmaud.drv, avrt.dll — звуковая подсистема (Audio Session API, WASAPI).
• wimgapi.dll, cabinet.dll, expand.exe — работа с образами WIM и CAB.

В отличие от драйверов ядра (.sys в drivers\), UMDF-драйверы работают в изолированных процессах (WUDFHost.exe), что повышает стабильность: сбой драйвера не приводит к BSOD.

6. Локализация и региональные ресурсы

• *.mui-файлы — Multilingual User Interface: строки, диалоги, описания на разных языках.
• *.nls, sort*.nls, locale.nls — данные сортировки, локалей, кодовых страниц.
• C_*.NLS — таблицы преобразования кодировок (например, C_1251.NLS — CP1251 → Unicode).

Windows загружает .mui-ресурсы динамически в зависимости от языка интерфейса. Например, kernel32.dll.mui в en-US\ содержит английские строки, а в ru-RU\ — русские. Это позволяет устанавливать языковые пакеты без замены основных бинарных файлов.

7. Службы и хост-процессы

• svchost.exe — универсальный хост для DLL-служб (группируемых по общим библиотекам: netsvcs, LocalService, DcomLaunch и т.п.).
• dllhost.exe — COM+ приложение-хост, COM Surrogate (для out-of-proc COM-объектов).
• taskhostw.exe — хост для фоновых задач (планировщика заданий).
• runtimebroker.exe — хост для UWP-приложений и их разрешений (capability access).
• backgroundTaskHost.exe — выполнение фоновых задач UWP.

Каждый из этих процессов изолирован по ACL и запускается от имени различных системных аккаунтов (SYSTEM, LocalService, NetworkService, User), обеспечивая принцип минимальных привилегий.

---

Ключевые системные файлы в корне C:\Windows

Помимо подкаталогов, в корне Windows находятся файлы, критичные для загрузки, работы и диагностики:

Файл	Назначение
bootstat.dat	Статистика загрузки: время, успешность, причины перезагрузки. Используется bootmgr и winload.exe.
explorer.exe	Процесс оболочки (Проводник и панель задач). Не обязательный — можно заменить на кастомную оболочку.
notepad.exe, regedit.exe, cmd.exe	Основные утилиты, доступные даже в минимальных средах восстановления.
system.ini, win.ini	Унаследованные конфигурационные файлы от Windows 3.x/9x. Сейчас почти не используются, но некоторые legacy-приложения (например, 16-битные) всё ещё читают их.
winhlp32.exe	Совместимость с *.hlp-файлами (Windows Help Format). С 2010 года не входит в состав по умолчанию — устанавливается отдельно.
py.exe, pyw.exe	Python Launcher — стандартный загрузчик Python, поставляемый с Windows 10 20H2+ и Windows 11. Перенаправляет вызовы py в установленную версию Python (из Microsoft Store или MSI).
splwow64.exe	Компонент печати для 32-битных приложений на 64-битной системе — обёртка для spoolsv.exe.
DPINST.LOG, setupact.log, setuperr.log, WindowsUpdate.log	Журналы установки драйверов, ОС и обновлений — ключевые файлы для диагностики ошибок развёртывания.
PFRO.log	Protected File Read-Only log — фиксирует попытки записи в защищённые файлы (например, при сбое UAC).
xhunter1.sys	Пример драйвера, не входящего в стандартную поставку — появление этого файла требует проверки на наличие ПО для обхода защиты (например, антидетект-утилит). В чистой Windows его нет.

Следует подчеркнуть: файл explorer.exe не является частью ядра. Его завершение (например, через Диспетчер задач) не приводит к остановке системы — сессия пользователя остаётся активной, можно запускать процессы, работать со службами, открывать окна через ShellExecute. Это важно для киоск-режимов и кастомных UI-решений.

---

SysWOW64: 32-битная среда на 64-битной Windows

Каталог C:\Windows\SysWOW64 содержит точные 32-битные аналоги большинства файлов из System32. Например:

• SysWOW64\kernel32.dll — 32-битная версия kernel32,
• SysWOW64\cmd.exe — 32-битный интерпретатор,
• SysWOW64\odbcad32.exe — 32-битный ODBC-администратор.

Разделение необходимо, потому что:

• 32- и 64-битные DLL несовместимы по ABI (смещения полей, calling convention, указатели),
• COM-серверы должны быть зарегистрированы отдельно для каждой архитектуры,
• процессы 32- и 64-битные изолированы по адресному пространству.

При установке 32-битного ПО (например, старого Java, 32-битного Office) установщик должен использовать SysWOW64 и Program Files (x86). Если он пишет в System32 — это ошибка и нарушение политик безопасности.

---

WinSxS: Side-by-Side Assembly Store и компонентное обслуживание

C:\Windows\WinSxS — хранилище всех установленных версий системных компонентов. Это не «мусор», а централизованная база CBS (Component Based Servicing).

Каждый файл в WinSxS имеет строгое имя:
amd64_microsoft-windows-kernel32_31bf3856ad364e35_10.0.22621.1_none_7df38a7e950a0e12\kernel32.dll

Где:

• amd64 — архитектура,
• microsoft-windows-kernel32 — компонент,
• 31bf3856ad364e35 — vendor ID (Microsoft),
• 10.0.22621.1 — версия (Windows 11 22H2),
• none — язык (none — neutral),
• хеш — уникальный идентификатор сборки.

Файлы в System32 — это жёсткие ссылки на файлы в WinSxS. Проверить можно командой:

fsutil hardlink list C:\Windows\System32\kernel32.dll

Удаление файлов из WinSxS через Проводник невозможно (права SYSTEM), но можно через:

• DISM /Online /Cleanup-Image /StartComponentCleanup — удалить устаревшие версии,
• DISM /Online /Cleanup-Image /SPSuperseded — удалить старые пакеты обслуживания.

Объём WinSxS может достигать 10–15 ГБ — это нормально и необходимо для отката обновлений.

---

Реестр Windows: физическое размещение и связь с файловой системой

Реестр Windows — это иерархическая база конфигурационных данных, но не отдельная сущность. Он физически представлен набором файлов — так называемых hive-файлов — которые хранятся в файловой системе и загружаются в память ядра при старте или входе пользователя.

Основные системные hive-файлы

Hive	Физический путь	Назначение
DEFAULT	C:\Windows\System32\config\DEFAULT	Шаблон профиля для локальной учётной записи по умолчанию (используется при загрузке до входа пользователя — например, в среде восстановления).
SAM	C:\Windows\System32\config\SAM	Security Accounts Manager — локальные учётные записи, хэши паролей (NTLM), группы. Доступен только SYSTEM.
SECURITY	C:\Windows\System32\config\SECURITY	Локальные политики безопасности: ACL, права пользователей, аудит.
SOFTWARE	C:\Windows\System32\config\SOFTWARE	Глобальные настройки ПО, компонентов, служб, COM-классов.
SYSTEM	C:\Windows\System32\config\SYSTEM	Конфигурация драйверов, служб, загрузочных параметров (ControlSet*), аппаратных профилей.

Эти файлы заблокированы для прямого доступа в работающей системе: их эксклюзивно удерживает ядро через Configuration Manager. Для резервного копирования или восстановления используется reg.exe save, reg.exe load, или утилиты вроде Offline NT Password & Registry Editor.

Профильные hive-файлы

Для каждого пользователя в C:\Users\<Имя>\ находятся:

• NTUSER.DAT — hive HKEY_CURRENT_USER, загружается при входе.
• AppData\Local\Microsoft\Windows\UsrClass.dat — hive HKEY_CURRENT_USER\Software\Classes, содержит COM-регистрацию на уровне пользователя (например, ассоциации файлов .myapp).
• AppData\Local\Microsoft\Windows\INetCache\ и AppData\Local\Temp\ — кэш, часто связанный с реестровыми настройками браузеров и .NET-приложений.

При входе в домен UsrClass.dat может быть частью roaming-профиля, но NTUSER.DAT — всегда. Объединение локальных и доменных политик происходит через механизм Group Policy Processing, где gpsvc.dll применяет настройки из HKLM\SOFTWARE\Policies\ и HKCU\SOFTWARE\Policies\.

Транзакционные logfile и целостность

Каждый hive имеет пару журнальных файлов:

• *.LOG1, *.LOG2 — write-ahead logs для восстановления после сбоя.
• При повреждении hive ядро пытается выполнить автовосстановление из логов.

Формат hive — двоичная структура с заголовком(REGF), блоками (HBIN), и элементами (NK, VK, SK). Он не предназначен для прямого редактирования, но может быть проанализирован утилитами вроде RegRipper, Registry Explorer, yarp.

---

Профили пользователей: C:\Users\, AppData и перенаправление

Структура профиля

Папка C:\Users\<Имя>\ — это рабочая среда пользователя, но лишь часть её видима напрямую. Внутри:

• Видимые папки: Desktop, Documents, Downloads, Pictures и т.д. — это, как правило, библиотеки (Libraries) или перенаправленные папки (Folder Redirection), а не физические каталоги. Их реальное размещение может быть в облаке (OneDrive) или на сетевом ресурсе.
• Скрытая папка AppData — ключевое хранилище:
  • Roaming\ — данные, синхронизируемые при roaming-профиле: настройки Outlook, Chrome, Visual Studio и т.д.
  • Local\ — данные, привязанные к машине: кэши, временные файлы, нативные сборки .NET (ngen), данные LocalDB.
  • LocalLow\ — изолированное хранилище для приложений с пониженной целостностью (например, IE в режиме защищённого просмотра), ACL: Low Mandatory Level.

Перенаправление и виртуализация

Для обеспечения безопасности и управления:

• Folder Redirection — через групповые политики можно перенаправить Documents в \\server\share\%username%, не меняя UX.
• AppData Virtualization — для legacy-приложений, пытающихся писать в Program Files, включается файловая виртуализация: запись в C:\Program Files\App\config.ini прозрачно перенаправляется в %LOCALAPPDATA%\VirtualStore\Program Files\App\config.ini. Включена только для 32-битных приложений без манифеста requestedExecutionLevel.

---

Службы и драйверы: размещение, регистрация, запуск

Службы (Services)

Службы — это процессы, управлямые Service Control Manager (services.exe). Их метаданные хранятся в:

• HKLM\SYSTEM\CurrentControlSet\Services\<Name> — основные параметры: ImagePath, Start, Type, Dependencies, ServiceSidType.
• ImagePath может указывать на:
  • Исполняемый файл (C:\Windows\System32\svchost.exe -k netsvcs),
  • DLL, загружаемую через svchost.exe (настройка в Parameters\ServiceDll),
  • WMI-провайдер или PowerShell-скрипт (через ServiceDll и COM).

Сами бинарные файлы обычно лежат в:

• C:\Windows\System32\ — системные службы,
• C:\Program Files\<Vendor>\ — сторонние (например, MongoDB, Docker Desktop Service).

Драйверы ядра (Kernel-mode Drivers)

Драйверы *.sys размещаются в:

• C:\Windows\System32\drivers\ — основное хранилище,
• C:\Windows\System32\DriverStore\FileRepository\<inf-hash>\ — репозиторий драйверов, установленных через pnputil.exe, devcon.exe, или Plug and Play.

Регистрация драйвера происходит:

1. Копированием в DriverStore (через SetupAPI).
2. Применением INF-файла (devcon install mydriver.inf myhwid).
3. Созданием записи в HKLM\SYSTEM\CurrentControlSet\Services\<DrvName>, где Type=1 (kernel driver), Start=3 (demand start), ImagePath=\SystemRoot\System32\drivers\mydrv.sys.

Проверка подписи: при загрузке драйвера Windows проверяет его цифровую подпись через Kernel-Mode Code Signing (KMCS). На серверных и клиентских сборках с отладкой можно отключить (bcdedit /set testsigning on), но в продакшене — только подписанное.

---

Облачные интеграции: OneDrive, Files On-Demand, Offline Files

OneDrive

• Локальное размещение: C:\Users\<Имя>\OneDrive\ — это реальная папка, но управляемая OneDrive.exe.
• Files On-Demand — реализован через точки повторного анализа (reparse points): каждый файл имеет тег IO_REPARSE_TAG_CLOUD_1, и при открытии OneDrive.exe загружает его «на лету».
• Метаданные: хранятся в C:\Users\<Имя>\AppData\Local\Microsoft\OneDrive\settings\Personal\ — settings.dat, ClientPolicy.ini, SyncEngine.db (SQLite).

Offline Files (CSC)

• Включается для сетевых шар: \\server\share → Свойства → «Всегда доступно автономно».
• Кэш хранится в C:\Windows\CSC\ — зашифрован, привязан к SID пользователя.
• Управляется службой CscService, политики — в HKLM\SOFTWARE\Policies\Microsoft\Windows\NetCache.

---