За привычными папками и ярлыками Windows ведёт молчаливую бухгалтерию. Каждая учётная запись получает собственный угол в системном реестре, и все эти углы собраны в ветке с именем HKEY_USERS. Именно здесь система держит обои рабочего стола, закреплённые программы, настройки Проводника и тысячи мелких предпочтений каждого, кто заходил в систему. Понимание устройства этой ветки помогает чинить испорченные профили, переносить настройки между учётными записями и находить следы давно удалённых пользователей.
Разделы куста HKEY_USERS перечисляют все учётные записи компьютера
Реестр Windows состоит из пяти корневых веток: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS и HKEY_CURRENT_CONFIG. HKEY_USERS среди них самая людная. Обычный пользователь видит в ней лишь собственную ветку, а администратор – весь список целиком. Заглянуть в неё нетрудно: сочетание клавиш Win + R открывает окно "Выполнить", в поле вводится regedit, после нажатия кнопки ОК система просит подтверждение в окне Контроля учётных записей, где остаётся щёлкнуть кнопку Да. В левой панели редактора раскрывается список веток, среди которых видна HKEY_USERS.
Внутри ждёт компактный перечень. Ветка .DEFAULT обслуживает систему до входа пользователя. Рядом лежат три служебных раздела с номерами S-1-5-18, S-1-5-19 и S-1-5-20, закреплёнными за системными учётными записями LocalSystem, LocalService и NetworkService. Затем идут ветки вида S-1-5-21-длинный-номер, по одной на каждого пользователя с активным сеансом. У такой ветки есть младший сосед с суффиксом _Classes, куда подключаются настройки классов COM.
По сути, HKEY_USERS работает как многоквартирный дом: каждая ветка – отдельная квартира, а HKEY_CURRENT_USER лишь табличка на двери текущего жильца. Открыв HKCU в том же редакторе, можно увидеть ровно ту ветку из HKEY_USERS, что соответствует вошедшему пользователю. Отсюда практический вывод: правки в HKCU немедленно попадают в конкретный профиль. А ветки пользователей, завершивших сеанс, из списка исчезают, что поначалу сбивает с толку.
Идентификатор SID служит точным адресом профиля в реестре
Громоздкие имена вроде S-1-5-21-1004336348-1177238915-682003330-1001 пугают новичков, но на деле это просто адрес. Буква S обозначает сам формат, первая цифра задаёт версию структуры, пятёрка указывает на авторство Windows, средние числа называют домен или конкретный компьютер, а замыкающий номер, RID, закреплён за конкретной учётной записью. Встроенный администратор всегда получает RID 500, гость 501, а обычные учётные записи начинают отсчёт с 1000. Есть и вечные номера, одинаковые на любой машине: S-1-1-0 закреплён за группой "Все", а S-1-5-32-544 за группой Администраторы. Такие идентификаторы называют известными: система узнаёт их без справочника. Windows выдаёт RID один раз и никогда не использует повторно: даже если учётную запись удалить и создать заново с тем же именем, идентификатор будет другим.
Имя при этом ничего не решает. Переименование учётной записи не меняет SID, поэтому реестр привязан к номеру, а не к надписи на экране входа. Узнать свой идентификатор можно без редактора: консоль открывается через Win + X, а команда whoami /user выводит SID текущего пользователя.
whoami /userКонсоль ответит строкой с именем машины, именем пользователя и искомым идентификатором. Полный перечень локальных учётных записей с их SID выдаёт PowerShell:
Get-LocalUser | Format-Table Name, SIDТакая табличка выручает, когда в HKEY_USERS висит безымянная ветка и требуется понять, чей это профиль. Заодно бросаются в глаза учётные записи, которые давно не активны.
Файлы NTUSER.DAT и USRCLASS.DAT хранят настройки профиля на диске
Каждая пользовательская ветка не живёт в реестре вечно, а подгружается из файла при входе в систему. Корневой файл профиля называется NTUSER.DAT и лежит в папке C:\Users\<имя пользователя>. Почему Проводник его не показывает? Файл помечен как скрытый системный, поэтому по умолчанию невидим. Включить показ можно прямо в Проводнике: в Windows 10 путь такой: Вид → Скрытые элементы, в Windows 11 он длиннее: Вид → Показать → Скрытые элементы.
Второй файл, USRCLASS.DAT, прячется глубже, в каталоге C:\Users\<имя>\AppData\Local\Microsoft\Windows. Он отвечает за регистрацию классов COM отдельно взятого пользователя и при загрузке подключается к ветке с суффиксом _Classes. Пока пользователь работает, оба файла заняты системой, скопировать или открыть их напрямую не выйдет. Рядом лежат журналы с расширением .log, куда реестр записывает каждое изменение, поэтому даже после сбоя питания файлы восстанавливаются по журналу.
Живой куст копируют не файлом, а командой reg save: она выгружает содержимое ветки в файл с расширением .hiv прямо из реестра, и блокировка профиля мешать не станет. Команда вводится в командной строке, готовая копия появится в той папке, что записана в команде, а позже файл монтируется обратно командой reg load:
reg save HKCU "C:\Backup\ntuser.hiv" /yСистема связывает SID и папку профиля через ключ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Внутри лежат подразделы с именами SID, а в каждом хранится параметр ProfileImagePath с путём к папке. Проверить соответствие можно одной командой в командной строке, консоль на выходе перечислит все известные системе профили:
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" /s /v ProfileImagePathПротив каждой ветки HKEY_USERS сразу видно, какая папка на диске ей принадлежит. Осиротевшие записи без папок тоже бросаются в глаза.
Ветка .DEFAULT обслуживает систему до входа пользователя
Название .DEFAULT намекает на шаблон, и тут кроется ловушка. Файлом этой ветки служит не профиль из папки пользователей, а системный файл Default из каталога C:\Windows\System32\Config. Ветка загружена всегда, но обслуживает период до входа: настройки экрана приветствия, раскладку клавиатуры по умолчанию, оформление для служб, работающих от имени системы. Изменения здесь видны ещё до того, как пользователь наберёт пароль.
Практический пример: раскладка клавиатуры до входа задаётся в разделе HKEY_USERS\.DEFAULT\Keyboard Layout\Preload. Добавленный туда язык встречает пользователя уже на экране приветствия, без всяких параметров учётной записи.
Настоящий шаблон для новых учётных записей лежит отдельно, в скрытой папке C:\Users\Default, где ждёт своего часа файл NTUSER.DAT. Когда система создаёт пользователя, она копирует содержимое этой папки в свежий профиль. Правки в HKEY_USERS\.DEFAULT новый профиль никак не затронут. Перепутать эти два хранилища легко, а последствия путаницы тихи и обидны: настройки вроде бы внесены, а на экране входа ничего не поменялось.
Просмотр куста доступен через regedit и командную строку
Редактор реестра показывает только подгруженные кусты, поэтому в HKEY_USERS обычно видны активные пользователи и служебные записи. Обновить картину можно клавишей F5 или через меню Вид → Обновить. Тот же список без графики выдаёт командная строка: после запуска reg query HKU консоль перечислит все смонтированные сейчас ветки.
reg query HKUPowerShell повторяет трюк собственной командой. Вывод получится тем же, только без графики и без лишних щелчков:
Get-ChildItem Registry::HKEY_USERSОбе команды удобны в скриптах: сначала узнав SID активных пользователей, затем обращаются к нужной ветке по адресу. Для затянутых поисков по большим веткам в regedit служит окно Правка → Найти, открываемое сочетанием Ctrl + F.
Практичный пример изнутри – раздел автозагрузки текущего пользователя. Команда вводится в той же консоли, а на выходе появляется перечень программ, стартующих вместе с системой именно для этой учётной записи:
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"Команда reg load подключает куст чужого профиля к реестру
Самая ценная способность кустов проявляется, когда профиль повреждён и пользователь не может войти в систему. Настройки физически целы, лежат в NTUSER.DAT, просто не подключены. Их можно смонтировать к работающему реестру и поправить. Понадобится другая учётная запись с правами администратора. Порядок действий такой:
- убеждаются, что проблемный пользователь завершил сеанс, иначе файл NTUSER.DAT останется заблокированным;
- открывают консоль с повышенными правами через Win + X, выбрав Терминал (Администратор) в Windows 11 или Windows PowerShell (Администратор) в Windows 10;
- монтируют куст командой reg load, указав временное имя ветки и путь к файлу NTUSER.DAT;
- правят параметры в появившемся разделе через regedit;
- выгружают куст командой reg unload и проверяют, что ветка исчезла из списка.
Команда монтирования вводится в консоли администратора, и сразу после её выполнения в HKEY_USERS появляется ветка TempUser с полным набором настроек неактивного пользователя. Кавычки обязательны, если путь содержит пробелы:
reg load HKU\TempUser "C:\Users\Иван\NTUSER.DAT"Аналогично подключается и USRCLASS.DAT, если правки касаются регистрации классов COM. Ветка TempClasses появится в HKEY_USERS тем же способом:
reg load HKU\TempClasses "C:\Users\Иван\AppData\Local\Microsoft\Windows\USRCLASS.DAT"Справка reg load упоминает файлы, сохранённые командой reg save с расширением .hiv, на деле команда спокойно монтирует и сам NTUSER.DAT. Завершает работу обратная команда. После её выполнения ветка TempUser исчезает из списка, а система отпускает файл:
reg unload HKU\TempUserЕсли выгрузка заканчивается отказом, значит какая-то программа держит ветку открытой. Редактор реестра закрывают, затем повторяют команду. Успех проверяется просто: код возврата 0 означает удачу, единица сигналит об ошибке.
Резервные копии и перенос настроек спасают испорченный профиль
Перед правками чужого куста разумно сделать копию. Для активного пользователя выгрузку целой ветки выполняет reg export: команда сохранит раздел в файл с расширением .reg, который потом открывается двойным щелчком и возвращает всё на место:
reg export HKCU "C:\Backup\settings.reg"Файл получается текстовым, его можно открыть Блокнотом и вырезать лишнее. Способ выручает при переносе привычных настроек в новую учётную запись: экспортировали ветку из старого профиля, загрузились под новым именем, импортировали файл. Внутренности куста переезжают вместе с привязками к SID лишь частично, поэтому отдельные программы после переезда просят первичную настройку, и это нормально.
Отдельного упоминания заслуживает симптом временного профиля. Если при входе система сообщает про вход во временный профиль, а рабочий стол выглядит пустым, чаще всего виноват остаток в ProfileList: запись SID указывает на удалённую папку. Лекарство известно: убрать осиротевший подраздел из ProfileList, перезагрузиться и дать системе собрать профиль заново из шаблона C:\Users\Default.
Разобраться, почему профиль собрался заново с нуля, помогает журнал событий. Открывается он через Win + X → Управление компьютером → Служебные программы → Просмотр событий, дальше Журналы Windows → Приложение. Ищутся записи с источником User Profile Service: там система честно описывает, что помешало загрузке профиля.
Освободить машину от ненужного профиля можно и без реестра: Параметры → Система → раздел "О системе" (в части сборок он подписан "О программе") → Дополнительные параметры системы → Профили пользователей → Параметры. Диалог перечисляет профили с примерным размером, кнопка Удалить стирает папку и запись в ProfileList одновременно. Место освобождается, а вместе с ним уходит и источник будущих сбоев.
HKEY_USERS остаётся частью Windows, куда заглядывают нечасто, а зря. Одна ветка рассказывает о пользователе многое: где лежит его папка, какие программы стартуют вместе с системой, какие настройки он уже успел поменять. Умение читать этот журнал превращает реестр из пугающего лабиринта в понятную картотеку, где у каждой учётной записи своя аккуратная ячейка.