Я уже писал про то, что надо бекапить самое ценное у винды, как что-то сделать с упавшей виндой, и как работать с реестром в не загружающейся.
Сегодня чуть-чуть расскажу про то, что можно сделать, если винда пережила экзистенциальный кризис, но загружается и местами пытается работать.
В качестве примера буду приводить систему, с которой недавно боролся после того, как она сама себе испоганила диск. Точнее не она, заглючил RAID-контроллер и вместо обеспечения целостности запорол кучу файлов (похоже писал данные не в те блоки), потом он, конечно, отправил систему в синий экран, но это было уже потом.
Винда, с трудом но поднялась после всего этого, правда для этого пришлось починить несколько важных для загрузки файлов и собрать монстра из реестра (комбинация из встроенного бекапа в C:\Windows\System32\config\RegBack\ и основного реестра), но в общем-то фатальных проблем не было.
Правда при работе слегка глючила, не давала подключиться удалённо, плюс были ещё мелкие и не очень проблемы (некоторые выявились только спустя несколько месяцев).
Что можно с этим сделать, и как чинить?
Так что этот способ не очень хорош, кроме того требует некоторого даунтайма системы (на установку и настройку сервисов снова). У меня был один такой системный сервис, который очень не хотелось трогать (и да, он разваливается при переустановке, можно поднять его из бекапа, и потом донастроить).
Так что я пробовал другие способы
Таким образом я починил большинство проблем и система жила, пока не потребовалось ещё кое-что настроить.
Но для начала
DISM.exe /Online /Cleanup-image /Restorehealth
или
DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess
Первый способ обещает починить файлы через Windows Update, второй использует локальное хранилище в случае невозможности подключиться.
Вкратце: способ мне не помог, хотя что-то делал и явных ошибок работы не выдавал. Тем не менее, он много каши не просит, поэтому стоит его попробовать.
Файлы были починены, но потом неожиданно начал стрелять реестр, причём совершенно непредсказуемо. Я подобных проблем ещё не встречал, гугл тоже даёт подозрительно мало вариантов. Поэтому, тут я расскажу только общие проблемы и возможные пути их решения, ибо если у вас будет подобное, оно будет подобным, а не точно таким.
Итак, на первый взгляд проблемы появились в том, что не ставились апдейты. Изучение ошибок и логов привело к парадоксальному результату: они не ставились, потому что валился Task Scheduler со статусом что-то типа Initialize::UserTable (за точность ошибки не ручаюсь, ибо по памяти). Т.е. совершенно невменяемая ошибка. Были перепробованы все средства, пока не оказалось, что проблема в том, что в управлении пользователями отсутствовали локальные пользователи, а при открытии групп вылезало две ошибки с чтением данных. Т.е. проблема не в этом, а в том что есть именно проблема с пользователями. При этом из консоли (net user, net localgroup) проблем явных не было.
Тут я полез уже в дебри и выяснил следующее:
Вся информация о пользователях хранится в ветке реестра SAM, которая в реестре замаплена на HKEY_LOCAL_MACHINE\SAM. Если вы откроете ветку сейчас, вы ничего там не увидите. Рекомендую добавить себе права.
Там всё внутри устроено оригинально и не так как в остальном реестре. В частности, есть группы пользователей (SAM\Domains\Account\Aliases) и сами локальные пользователи (SAM\Domains\Account\Users). Они идентифицируется неким id, а сопоставление имён и id идёт в отдельном разделе (SAM\Domains\Account\Users\Names\), где в качестве типа указан данный id. Т.е. не значение, а тип. который обычно DWORD, STRING, BINARY. Впрочем, это можно списать на особенности отображения и то, что этот раздел не предназначен для обычных глаз.
У пользователей есть бинарные параметры F и V, а у групп С, которые содержат описание объекта, SIDы, и кто кому принадлежит.
В моём случае, были повреждены разделы C (их тупо не было) у групп администраторов и пользователей, и был один повреждённый пользователь (хотя визуально он был в порядке.
Эти проблемы и вызывали странное поведение в управлении пользователями.
Если хочется тут что-то сделать, вначале делаем бекап, потом играемся как хотим. У нас есть возможность откатиться.
Эмпирическим путём проблемный пользователь был вычислен и уничтожен (удалением ветки реестра), пользователи вернулись в норму. Раздел C, был импортирован с соседнего компьютера и всё ожило (Планировщик, а вместе с ним и апдейты. То ли у них были проблемы с группами, то ли с пользователем). К сожалению, в управлении группами в этих группах появились неизвестные SIDы (неудивительно, с таким-то импортом), которые не удалялись, а также не добавлялись новые пользователи.
Наилучшим решением проблемы я посчитал следующее (очень не хотелось разбираться в бинарной структуре данных записей, не стоит оно того). Например, у нас проблемная группа Administrators. Создаём группу Bdministrators. В эту группу добавляем нужных пользователей (самого администратора, например). Экспортируем из реестра обе группы по отдельности. Переносим бинарные данные из экспортированного файла от Bdministrators в Administrators, и импортируем его назад. Тем самым, у нас появились правильные администраторы (с правильным id), но неправильным именем. Ну, тут открываем в редакторе реестра бинарный редактор и меняем код байтика, отвечающий за B, на A. Всё, у нас правильные администраторы. Лишнюю группу удаляем, чтобы не мешалась. Повторяем тоже самое для других групп.
Результат — всё красиво и работает.
На этом пока всё. Я рассказал как чинить файлы, и что можно сделать с реестром. После этого, при желании винду можно восстановить почти из любого состояния, вопрос только целесообразности. А я буду ожидать очередного безумного сюрприза от очередной системы, но также буду надеяться, что он случится когда-нибудь попозже.
Сегодня чуть-чуть расскажу про то, что можно сделать, если винда пережила экзистенциальный кризис, но загружается и местами пытается работать.
В качестве примера буду приводить систему, с которой недавно боролся после того, как она сама себе испоганила диск. Точнее не она, заглючил RAID-контроллер и вместо обеспечения целостности запорол кучу файлов (похоже писал данные не в те блоки), потом он, конечно, отправил систему в синий экран, но это было уже потом.
Винда, с трудом но поднялась после всего этого, правда для этого пришлось починить несколько важных для загрузки файлов и собрать монстра из реестра (комбинация из встроенного бекапа в C:\Windows\System32\config\RegBack\ и основного реестра), но в общем-то фатальных проблем не было.
Правда при работе слегка глючила, не давала подключиться удалённо, плюс были ещё мелкие и не очень проблемы (некоторые выявились только спустя несколько месяцев).
Что можно с этим сделать, и как чинить?
Вариант 1. Апгрейд винды на саму себя из установочных файлов
Винда бережно сохраняет все настройки и восстанавливает их в новой системе. Но есть проблема, могут сохраниться ошибочные настройки, а часть данных не перенесётся, причём лучше уж поломанный сервис, который ты знаешь, что надо починить, чем рабочий, у которого потерялась какая-то хитрая настройка, и из-за этого он поведёт себя не так как надо.Так что этот способ не очень хорош, кроме того требует некоторого даунтайма системы (на установку и настройку сервисов снова). У меня был один такой системный сервис, который очень не хотелось трогать (и да, он разваливается при переустановке, можно поднять его из бекапа, и потом донастроить).
Так что я пробовал другие способы
Вариант 2. sfc /scannow
Способ, который рекомендуют на всех форумах, к сожалению помогает он плохо, т.е. ничего не лечит (ему неоткуда взять корректные файлы при серьёзных повреждениях), но зато создаёт логи в C:\Windows\Logs\CBS\CBS.log, с помощью которых можно узнать повреждённые файлы и физически заменить их с аналогичной системы (тут очень помогает Far, который достаточно вольно относится к отсутствию прав на файлы (т.е. если есть права выдать себе права, но в данный момент их нет, а приказ что-то сделать с файлом есть, фар решит эту проблему самостоятельно). Без фара можно ручками выдавать права на проблемные файлы, меняя владельца с TrustedInstaller на себя и раздавая права (если хочется красоты, следующий запуск sfc /scannow всё починит).Таким образом я починил большинство проблем и система жила, пока не потребовалось ещё кое-что настроить.
Но для начала
Вариант 3. dism
Утверждается, что свежая винда может себя починить через следующую команду:DISM.exe /Online /Cleanup-image /Restorehealth
DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess
Первый способ обещает починить файлы через Windows Update, второй использует локальное хранилище в случае невозможности подключиться.
Вкратце: способ мне не помог, хотя что-то делал и явных ошибок работы не выдавал. Тем не менее, он много каши не просит, поэтому стоит его попробовать.
Файлы были починены, но потом неожиданно начал стрелять реестр, причём совершенно непредсказуемо. Я подобных проблем ещё не встречал, гугл тоже даёт подозрительно мало вариантов. Поэтому, тут я расскажу только общие проблемы и возможные пути их решения, ибо если у вас будет подобное, оно будет подобным, а не точно таким.
Итак, на первый взгляд проблемы появились в том, что не ставились апдейты. Изучение ошибок и логов привело к парадоксальному результату: они не ставились, потому что валился Task Scheduler со статусом что-то типа Initialize::UserTable (за точность ошибки не ручаюсь, ибо по памяти). Т.е. совершенно невменяемая ошибка. Были перепробованы все средства, пока не оказалось, что проблема в том, что в управлении пользователями отсутствовали локальные пользователи, а при открытии групп вылезало две ошибки с чтением данных. Т.е. проблема не в этом, а в том что есть именно проблема с пользователями. При этом из консоли (net user, net localgroup) проблем явных не было.
Тут я полез уже в дебри и выяснил следующее:
Вся информация о пользователях хранится в ветке реестра SAM, которая в реестре замаплена на HKEY_LOCAL_MACHINE\SAM. Если вы откроете ветку сейчас, вы ничего там не увидите. Рекомендую добавить себе права.
Там всё внутри устроено оригинально и не так как в остальном реестре. В частности, есть группы пользователей (SAM\Domains\Account\Aliases) и сами локальные пользователи (SAM\Domains\Account\Users). Они идентифицируется неким id, а сопоставление имён и id идёт в отдельном разделе (SAM\Domains\Account\Users\Names\), где в качестве типа указан данный id. Т.е. не значение, а тип. который обычно DWORD, STRING, BINARY. Впрочем, это можно списать на особенности отображения и то, что этот раздел не предназначен для обычных глаз.
У пользователей есть бинарные параметры F и V, а у групп С, которые содержат описание объекта, SIDы, и кто кому принадлежит.
В моём случае, были повреждены разделы C (их тупо не было) у групп администраторов и пользователей, и был один повреждённый пользователь (хотя визуально он был в порядке.
Эти проблемы и вызывали странное поведение в управлении пользователями.
Если хочется тут что-то сделать, вначале делаем бекап, потом играемся как хотим. У нас есть возможность откатиться.
Эмпирическим путём проблемный пользователь был вычислен и уничтожен (удалением ветки реестра), пользователи вернулись в норму. Раздел C, был импортирован с соседнего компьютера и всё ожило (Планировщик, а вместе с ним и апдейты. То ли у них были проблемы с группами, то ли с пользователем). К сожалению, в управлении группами в этих группах появились неизвестные SIDы (неудивительно, с таким-то импортом), которые не удалялись, а также не добавлялись новые пользователи.
Наилучшим решением проблемы я посчитал следующее (очень не хотелось разбираться в бинарной структуре данных записей, не стоит оно того). Например, у нас проблемная группа Administrators. Создаём группу Bdministrators. В эту группу добавляем нужных пользователей (самого администратора, например). Экспортируем из реестра обе группы по отдельности. Переносим бинарные данные из экспортированного файла от Bdministrators в Administrators, и импортируем его назад. Тем самым, у нас появились правильные администраторы (с правильным id), но неправильным именем. Ну, тут открываем в редакторе реестра бинарный редактор и меняем код байтика, отвечающий за B, на A. Всё, у нас правильные администраторы. Лишнюю группу удаляем, чтобы не мешалась. Повторяем тоже самое для других групп.
Результат — всё красиво и работает.
На этом пока всё. Я рассказал как чинить файлы, и что можно сделать с реестром. После этого, при желании винду можно восстановить почти из любого состояния, вопрос только целесообразности. А я буду ожидать очередного безумного сюрприза от очередной системы, но также буду надеяться, что он случится когда-нибудь попозже.
Сообщения
Комментариев нет:
Отправить комментарий