Windows RE возможно ли восстановить?
 

Подскажите пожалуйста.
Можно ли починить работу Windows RE? Или только переустановка поможет?
Диск был перобразован MBR2GPT и все работало хорошо пока я не стал переносить Windows RE на специальный отдельный раздел, думал так правильнее. Перепробовал практически все доступные советы из инета. Ну Ни как теперь не активируется Windows RE.

Вам же команда /info показывает, что строка Windows RE location пустая. Там должен быть указан путь к каталогу со средой восстановления. Скорее всего, в ReAgent.xml неправильные данные содержатся. Удалите этот файл из каталога harddisk1\partition1\Recovery\WindowsRE и выполните команду /enable повторно для его пересоздания.

Да
Работает https://www.outsidethebox.ms/16446/#_Toc385802161

Цитата Avatar-Lion:
Вам же команда /info показывает, что строка Windows RE location пустая. Там должен быть указан путь к каталогу со средой восстановления. Скорее всего, в ReAgent.xml неправильные данные содержатся. Удалите этот файл из каталога harddisk1\partition1\Recovery\WindowsRE и выполните команду /enable повторно для его пересоздания. »


Спасибо за ответ! Тут кое что обнаружилось странное.
После преобразования диска MBR2GPT или не ясно как, но у меня два bootmanager для загрузки.
Так вот, под одним WindowsRE активировалась и работает, а под вторым bootmanager, WindowsRE не активируется и не работает. Поясните пожалуйста в чем может дело?


https://i.stack.imgur.com/AIPns.jpg
https://i.stack.imgur.com/CXA0M.jpg


Первый bootmanager (current)
https://i.stack.imgur.com/5v0hs.png
https://i.stack.imgur.com/cFYTm.png


Второй bootmanager (default)
https://i.stack.imgur.com/J4oxi.png
https://i.stack.imgur.com/gOyaV.png


Как такое могло получиться? И можно ли сделать один bootmanager (current)+(default) чтобы работал Windows RE?


PS для обновления 21H2 на 22H2 нужен был GPT диск, может обновление вызвало два bootmanager?

12sunflowers, Скачайте BootICE, запустите и перейдите в UEFI > Edit boot entries. Там должно быть две записи (ссылки) с заголовком "Windows Boot Manager". Покажите скриншот с каждой такой записи.

Avatar-Lion,
https://i.imgur.com/D0JLZx5.png
https://i.imgur.com/juyg12V.png
На втором варианте где файлы загрузки на С:\ работает WindowsRE, если загружаться с первого варианта, где загрузчик на отдельной партиции WindowsRE не работает, интересно почему?

Долго думал, что вам написать... Давайте проведем небольшой эксперимент. Загрузитесь с той записи, в которой WindowsRE не работает. Далее выполните следующие команды:
reagentc /disable
reagentc /setreimage /path C:\Recovery\WindowsRE /target C:\Windows
reagentc /enable
reagentc /info

Каков результат?

Результат и есть вопрос моей темы
Разницу которую я увидел между этими загрузчиками это первый рабочий identifier(current), а втрой неаерабочий identifier(default) в bcdedit

Понятно. Что ж... Тогда на ум приходит только следующее: убрать вообще каталог EFI с диска С:, чтобы не вводить систему в заблуждение, а со скрытого 100Мбайтного ESP-раздела выкинуть BCD-файл и сформировать его заново командой bootrec /rebuildbcd

А почему с С?

Боюсь поломать.

А не проще через BootICE удалить нерабочий bootmanager, там есть опция? Или забить на все это и выставить в биосе на первую загрузке рабочий bootmanager.

Странно все это, хотел разобаться. Мне кажется, что этот второй скытый загрузочный раздел 100мб и второй нерабочий bootmanager результат конвертации MBR2GPT

Потому что его вообще там быть не должно.

Ну так я ж не предлагаю начисто удалить. Просто перенести куда-нибудь в другое место. Ну и да, подразумевается, что у вас есть на всякий пожарный LiveCD и т.п.

BootICE показывает вам записи в менеджере загрузки материнской платы. К параметрам загрузки Windows и прочего это не относится.

ОК, давайте расскажу как я это вижу. Вы установили Windows 10 в Legacy-режиме на MBR-диск, причем умудрились сделать так, что все файлы, необходимые для загрузки ОС, оказались на системном разделе. Далее вы конветируете диск из одной разметки в другую. Утилита по конвертации создает вам ESP-раздел и дублирует на него все, что нужно для загрузки ОС, т.е. то, что лежало на диске С:.

Дело в том, что изначально по стандарту UEFI прошивка мат.платы должна содержать FAT32-драйвер, чтобы менеджер загрузки мат.платы мог выполнить поиск .efi-приложений на внутренних накопителях и добавить ссылки (ярлыки) на них в список загрузки. Соответственно, ESP-раздел обычно имеет файловую систему FAT32, а Винда стоит отдельно на диске С: и там уже обычно NTFS используется. Но по всей видимости, производитель вашей материнки добавил NTFS-драйвер в состав прошивки. И получился казус: NTFS-раздел по идее не должен быть доступен для поиска .efi-приложений на нем, но - он доступен. И менеджер загрузки мат.платы нашел на нем .efi-приложение. Отсюда и два Windows Boot Manager'a у вас в загрузочном меню материнской платы.

Как следствие, мы имеем что-то вроде коллизии из двух конфигураций загрузки. По идее они должны быть полностью идентичны и независимы друг от друга. И по идее, каждый Windows Boot Manager относится к своей копии BCD-файла, где хранятся сведения о загрузке системы. Но вот как понять с каким из них взаимодействует Reagentc - этого я не знаю, не было у меня никогда такой ситуации на практике как у вас. Потому я и предложил устранить потенциальный конфликт, убрав всё загрузочное с диска С: и пересоздав BCD-файл на ESP-разделе, чтобы точно быть уверенным в том, что Reagentc взаимодействует с нужным BCD-файлом.

На всякий случай дам ссылку на свой же пост, где я вкратце объяснял человеку отличие между GPT и MBR, и прочим: http://forum.oszone.net/post-3006873-50.html - просто чтобы вы сами лучше понимали что у вас произошло благодаря этой конвертации...

Фуух. Сложновато, хотя с компами вожусь уже долго.
Спасибо, что Вы мне помогаете. Спросить не у кого, только гугл.

Да, ставил по старинке в Legacy режиме и на MBR, так как не думал, что в будущем из-за этого могут быть пролемы с обновлениями как в этот раз. Обычно я редко обновляюсь, решил обновиться и заело, пришло кумулятивное и обнова венды 22H2, и все это не ствится, оказывается из-за MBR, вот я и полез в трюки с MBR2GPT, чтобы все не переустанавливать.

Не понимаю как это получается. У меня со времен 7ки, все ставится на один диск(система), и загрузчик и среда восстановления(если она тогда была).

Если я все как Вы говорите удалю с С, то где уверенность, что загрузчик пропишется на этом 100мб разделе и при этом заработает среда восстановления?

Может сделать так - создать еще один раздел 500мб для среды восстановления перенести туда папку Recovery, потом не удаляя ничего с С сделать (где N скрытый 100мб раздел) и потом подключить Recovery?


а как bootrec /rebuildbcd узнает, что записывать загрузчик надо на этот 100мб раздел, а не опять на С?


Спасибо, довольно понятно и кратко изложено.

Лично я тоже впервые слышу об этом.

Если вы этим хотели сказать, что в ходе установки Windows 10 у вас никогда не создавались два дополнительных раздела (под загрузочные файлы и под среду восстановления), то так быть не должно, сами понимаете.

Еще раз: не удалить, а переместить или переименовать.

Да, это ключевой момент эксперимента. Если BCD-файл не будет создан, то значит, с ESP-разделом что-то не так. Ну и тогда понятно, почему не получается включить Windows RE.

Вы можете попробовать так сделать, конечно, тем более что это вроде как и было вашим изначальным планом. Просто как по мне, нет никакой разницы где будет лежать WinRE.wim, если не сохраняются нужные параметры в BCD-файле. Но повторюсь, попробовать можете, хуже точно не будет.

Честно говоря, не вижу в этом смысла, т.к. система в UEFI-режиме у вас и так загружается нормально при выборе первой записи в меню загрузки мат.платы. Но опять же, и вреда от данной процедуры я не вижу.

На MBR-дисках он ориентируется на метку активного раздела, на GPT-дисках - на уникальный идентификатор раздела c12a7328-f81f-11d2-ba4b-00a0c93ec93b, который жёстко закреплен на ESP-разделом. Но это я всё по старой памяти пишу, возможно, тут я в чем-то ошибаюсь.

Можете, кстати, глянуть какой ID у вашего раздела через команду Detail Partition (перед этим, естественно, сначала нужно выбрать ESP-раздел в DiskPart > Select Disk > Select Partition).

да, отдельная партиция на 100 мб имеет id c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Если провести эксперимент то какой порядок действий? Это все можно делать только загрузившись с Win iso диска выбрать консоль?

Вроде получилось! И Recovery заработал на этом 100мб bootmanager

Но вопрос появился. Когда я делал bootrec /rebuildbcd

Почему на 7ке написало - The requested system device cannot be found? Изза того что она на MBR?


PS теперь один bootmanager

PPS Нестрашно 7ка грузится из CSM режима через вызов bootmenu во время старта пк

Поясните что именно вы сделали. Вы же несколько вариантов своих дальнейших действий расписали и мне теперь надо понять что к чему у вас теперь.

Под system device обычно подразумевается раздел, на котором должен быть сохранен BCD-файл, т.е. обычно это тот самый раздел на 100Мбайт. У вас же команда отрабатывается корректно и находится ОС, но сохранить результат своей работы у bootrec не получается, например, не назначена буква для раздела, куда он пытается запихнуть свежесозданный BCD-файл.

1. На С переименовал папку EFI
2. Создал раздел 500мб и дал ему букву К
3. Скопировал с С папку Recovery на К
4. Гружусь с флешки с Windows 10 iso в Recovery консоль под CSM(иначе не грузится моя easy2boot флешка)
5. Делаю bootrec /rebuildbcd
6. Гружусь в Вин10
7. Удачно активирую Recovery на К
8. Well Done!


То есть bootrec /rebuildbcd правильно все распознал с 10кой, загрузочный раздел на 100мб - c12a7328-f81f-11d2-ba4b-00a0c93ec93b


Это вопрос по 7ке на отдельном MBR диске.


Почему при вызове bootrec /rebuildbcd хоть под UEFI хоть под CSM. Когда находит 7ку и я хоть отказываюсь ее добавлять в загрузчик, хоть соглашаюсь вижу


Под CSM
The requested system device cannot be found


Под UEFI
The system cannot find the path specified

Про 7ку, это не критично, просто интересно почему такое пишет, из-за того что она на отдельном MBR разделе, а я все это делаю на GPT? Видимо, естественно, нет совместимости между GPT и MBR вот я вижу эти ошибки после 7ки.


UPD1
да, это из-за не совместимости MBR<>GPT
проделал bootrec /rebuildbcd из Windows 7 Recovery, 7ку удачно добавляет, а на 10ку ругается таким же сообщением, что не находит устройство.

Это значит, что нужный раздел был найден, но на нём отсутствует или повреждена структура файлов и папок, необходимых для функционирования диспетчера загрузки Windows.

Вероятно, да. Однозначный ответ дать вам не могу, т.к. сама Майкрософт про bootrec не пишет ничего конкретного, т.е. из данной статьи непонятно умеет ли консольная утилита bootrec создавать BCD-файлы на ESP-разделах или же она умеет работать только с так называемыми System Reserved разделами на MBR-дисках. Вероятно, более универсальным способом является использование консольной утилиты BCDBoot. По крайне мере, у нее в списке команд четко указаны команды для создания файлов загрузки и для материнских плат под управлением BIOS, и для материнских плат под управлением UEFI.

Однако в общем и целом ситуация у вас, конечно, нестандартная. Во-первых, у Windows 7 отсутствует тот самый раздел System Reserved на 100Мбайт, где должны храниться файлы ее загрузки. По крайне мере, на ваших скриншотах я его не нашел. Во-вторых, всё на тех же скриншотах я заметил два раздела с меткой Active. В связи с чем возникает резонный вопрос: а куда вообще будут в таком случае пытаться записывать результаты своей работы все эти консольные утилиты? Причем у вас еще и сам по себе накопитель с Windows 7 идет после какого-то другого диска, что тоже может вносить коррективы. Вы если вдруг не знали, то при установке Windows тот самый раздел System Reserved по умолчанию создается на первом (то есть нулевом) накопителе. Что, кстати, регулярно приводило к казусам, когда люди собирали компьютеры и подключали диски как попало, совершенно не задумываясь зачем пронумерованы SATA-порты на материнских платах. Ну и как следствие, раздел System Reserved оказывался на одном харде, а сама Windows на другом.

Это я вам все к тому рассказываю, что у вас, с одной стороны, очень сложная структура дисков, а с другой - все эти средства восстановления загрузки не дают достаточной обратной связи, да и в целом Майкрософт не предполагает наличия двух систем на одном ПК. Т.е. технически это возможно, конечно, но опять же, предполагается в таком случае, что диспетчер загрузки Windows сидит на скрытом разделе System Reserved (ну или на ESP-разделе, если это GPT, а не MBR), который, в свою очередь, располагается на первом (нулевом) накопителе компьютера. И все прочие системы добавляются в BCD-файл по мере необходимости. А у вас, как мы видим, ситуация, мягко говоря, отличается: мало того, что режимы загрузки у двух систем разные, так еще и у Windows 7 нет своего раздела для хранения загрузочных файлов. И где там что у вас по факту лежит - одному богу известно.

Плюс всё это для меня присыпано этакой пылью времён. Windows 10 получилась объективно хорошей системой, а UEFI заменил BIOS еще в 2012 году примерно. За прошедшие десять лет почти все ПК перешли на Win10. Я вот не помню уже когда вообще ставил последний раз Windows 7, не говоря уж о восстановлении ее загрузки посредством возни с BCD-файлами. А уж Windows RE, две системы на одном ПК и прочее - это всё тем более давно уже в прошлом, я много лет уже не ставлю такие эксперименты, да и в массе своей такое по понятным причинам не встречается. Сейчас же все просто: UEFI, GPT, Win10.

P.S. Хотел это всё еще вчера написать, но время было уже позднее, поэтому пишу только сейчас. Да и на свежую голову проще мысли излагать, сами понимаете. :)

Добрый вечер! Фуух. Как то устал) Вот и сижу на компом обычно вечером и ночью.

Спасибо Вам Большое за помощь и спокойное пояснение! Без Вас бы не разобрался :)

Да, у меня тоже возник вопрос о 7ке. Если бы не последние обновление для 10ки(KBKB5023696 и 22H2)которые как выяснилось требуют для удачной установки GPT диск, то и не лез в эти дебри с загрузчиками, работало и ладно.

Предыдущая 7ка стояла 10лет без переустановок. В 2020 перешел на новую платформу АМД. Ну и по привычке и еще из-за ретроностальгии накатил 7ку(которую тоже нужно было патчить для поддержки юсб) Но теперь мне интересно как так получилось, что 7ка не имеет отдельной загрузочной партиции? Нулевым диском на момент установки 7ки в 2020 был ssd на котором сейчас 10ка, но 7ку я ставил на старый hdd(как видно на скриншоте) Уже не помню но она не хотела ставится и я переключал шлейфы каналов sata для установки. 7ка удачно поставилась и работает нормально с 2020, а вот с 10ку с 2020г я несколько раз переустанавливал(не нравилось и все как она работала для некоторых игр, теперь уже вроде лучше) Так вот, может как Вы говорите - по стандарту загрузочная партиция от 7ки могла попасть на нулевой тогда ssd диск с 10кой и когда я переустанавливал 10ку я его перезаписал? Да, еще я тогда помню мучался для "идеала" делал что бы hdd с 7кой имел дуалбут(7 и 10) и ssd c 10кой тоже дуалбут(10 и 7) на всякий случай, сейчас я отказался от дуалбутов вообще, и я тогда мог "накрутить" с загрузчиками. Но как то все работало, до этих последних обнов для 10ки.

Вот на этом моменте надо было вам тогда остановиться и исследовать возникшую проблему более детально.

Поздно истину искать. ))) Сейчас мы концов уже точно не найдём.

На самом деле ничего плохого в этом нет, особенно если вы часто перезагружаетесь из одной системы в другую. Заходить каждый раз в Boot Menu материнской платы с целью выбора диска для загрузки нужной ОС - это не так удобно, как взаимодействовать с диспетчером загрузки Windows. Но это так... Просто мысли вслух.

Повторюсь, концов мы сейчас уже не найдём. Могу лишь дать совет на будущее: на время установки Windows физически отключайте все прочие накопители, вне зависимости от их содержимого.

Кстати да, что там за обновления такие, которые в ультимативном порядке потребовали наличия GPT-разметки? Если это действительно какая-то новая задумка Майкрософта по принудительному переводу своих систем на UEFI-загрузку, то лучше о таком знать заранее.

У меня отключены автообновления. Решил обновиться раз в полгода. Все установилось хорошо кроме KB5023696 и 22H2 Тоесть по Вендой они загружаются, устанавливаются, далее перезагружаюсь как просит для дальнейшей установки, идет установка к 90% выходит сообщение, что обновления установить невозможно и откатыват их. Я много перепробовал и Windows10Upgrade9252.exe тулзу официальную и MediaCreationTool22H2.exe и windows10.0-kb5023696-x64_84833717ac6fdecea30cc3d235479a65a68069b0.msu Ничего не получалось пока гугл вывел меня на GPT, после конвертации диска MBR2GPT все установилось с первого раза без проблем.


https://answers.microsoft.com/en-us/...3-9ba5d59c9c21

Вот и мне так кажется, это совпадает с приходом 11ки там где GPT обязателен

Хотя может я и вру и не до конца разобрался. И все это из-за неправильной организации дисков 10ки было и не было просто Microsoft Reserved Partition (MSR)? :)

Тут говорится о Microsoft Reserved Partition (MSR) которой у меня не было до конвертации
https://www.kapilarya.com/fix-window...-uefi-firmware

Вспомнил как я вышел на GPT
В логе C:\$WINDOWS.~BT\Sources\Panther\setuperr.log после MediaCreationTool22H2.exe я нашел
что вывело меня на GPT и Microsoft Reserved Partition (MSR)

Можно еще вопрос?
Если в будущем собирусь сделать такой перенос загрузчика и рековери на отдельные диски в 7ке, то какой алгоритм действий будет?

Для загрузчика
1. создать партицию на 100мб ntfs назначить букву N и сделать ее активной
2. загрузиться в рековери
3. bcdboot C:\Windows /s N:
4. bootsect /nt60 N: /mbr

Для рековери
1. создать партицию на 500мб ntfs назначить букву M(допустим)
2.

12sunflowers, Примерно так, да. Хотя bootsect можно пропустить, полагаю. Система ведь уже загружается с этого диска, а значит, исполняемый код в MBR-зоне корректный.

bootsect /nt60 N: /mbr
Так mbr тоже можно/нужно перенести на диск где будет загрузчик?

Проще всего выяснить всё это через BootICE. Выбираем в нем нужный диск и по очереди проверяем кнопки Process MBR и Process PBR. В первой опции в строке статуса должно стоять Windows NT 6.x MBR, а во второй - BOOTMGR.

Если вы вдруг не знали: когда разметка накопителя создается силами Windows (т.е. в ходе установки системы, или через управление дисками, или через DiskPart, что суть есть одно и то же), то система всегда исходит из предположения, что с этого накопителя будут загружать Винду. Поэтому в MBR-зоне по умолчанию будет содержаться исполняемый код для загрузки систем на базе ядра NT, который, в свою очередь будет ссылаться на файл BOOTMGR. Поэтому все USB \ HDD \ SSD накопители, которые вы размечаете средствами Windows, по умолчанию являются загрузочными. Единственное что препятствует загрузке с них (и слава богу, как говорится) - это отсутствие метки активного раздела. Поэтому, кстати, в случае необходимости сделать установочную флэшку с Виндой проще простого: присваиваем разделу на ней метку активного - и всё, больше делать ничего не надо, просто копируем на нее содержимое ISO'шника.

И еще по поводу вашей команды bcdboot C:\Windows /s N:. Я бы предложил добавить ключ /f BIOS, чтобы конкретизировать список необходимых для загрузки файлов.

Так и есть.
Мне не ясно MBR идет одна на весь диск или под каждый раздел?
Если на весь диск, то почему тут bootsect /nt60 N: /mbr указывает буку раздела?

Одна на весь диск, естественно. Что касается буквы раздела, то, вероятно, это нужно для того, чтобы конкретизировать на какой накопитель нужно записать исполняемый код в MBR-зону.