С какого файла начинается загрузка windows 7 - Windowsa.top

ср, 05/31/2006 — 08:35 — admin

Файлы, необходимые для запуска системы

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

Файлы, необходимые для успешного запуска Windows 2000, перечислены в табл. 2.1.

Таблица 2.1. Файлы, необходимые для запуска Windows 2000

Файлы	Местоположение
NTLDR	Корневой каталог загрузочного диска
Boot.ini	Корневой каталог загрузочного диска
Bootsect.dos (только в системах с двойной загрузкой, где в качестве альтернативной операционной системы используются MS-DOS, Windows 3.1x или Windows 9 x, этот файл необходим для загрузки альтернативной ОС)	Корневой каталог загрузочного диска
Ntdetect.com	Корневой каталог загрузочного диска
Ntbootdd.sys (только для SCSI)	Корневой каталог загрузочного диска
Ntoskrnl.exe	%SystemfloofS6\System32
Hal.dll	%Systemfloof%\System32
Раздел реестра SYSTEM	%SysfemffoomSystem32\Config
Драйверы устройств	%Systemfloof%\System32\Drivers

Примечание

Для построения мультизагрузочной системы, где в качестве альтернативных ОС используются UNIX и Linux, можно скопировать загрузочный сектор раздела, в котором установлена эта операционная система, в файл в системном разделе NT/2000 и назвать этот файл, например, c:\bootsect.lnx или c:\bootsect.bsd (по аналогии с c:\bootsect.dos), а затем отредактировать файл boot.ini, добавив в раздел [operating systems] строки типа

С:\BOOTSECT.LNX=»Linux»

С:\BOOTSECT.BSD=»FreeBSD»

Версия для печати

Источник

Вы тут: Главная → Windows → Этапы загрузки Windows под микроскопом Windows Performance Toolkit

Составить полное представление о загрузке Windows можно с помощью набора Windows Performance Toolkit. Утилиты командной строки xbootmgr и xperf позволяют создать подробный отчет о запуске системы и представить его в графическом и текстовом виде для всестороннего анализа загрузки.

Эта статья продолжает серию материалов о загрузке Windows. Вы уже знаете, как получить подробный отчет о загрузке и устранить основные системные проблемы, а также ускорить загрузку системы, не прилагая особых усилий. Вы также познакомились со способом диагностики загрузки с помощью журнала событий. Я уверен, что после изучения этих статей и применения полученных знаний на практике ваша система стала загружаться быстрее.

Однако эти простые способы не позволяют выявить скрытые факторы или проблемы, замедляющие загрузку Windows. Теперь настало время познакомиться поближе со всеми этапами загрузки Windows и провести их детальный анализ с помощью Windows Performance Toolkit (WPT).

[+] Сегодня в программе

Загрузка и установка WPT

С выходом каждой новой Windows обновляются средства для анализа производительности Windows, поэтому я рекомендую использовать Windows Performance Analyzer (WPA) из Windows ADK для диагностики загрузки всех поддерживаемых ОС Windows. Краткое руководство по работе с WPA включено в статью об изучении автозагрузки Windows. Изложенные далее сведения об этапах загрузки применимы ко всем поддерживаемым ОС Windows.

Посмотреть устаревшие инструкции по установке WPT для Windows 7

Подготовка к работе

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

Прежде чем выполнить первую команду, создайте точку восстановления системы и убедитесь, что у вас есть под рукой установочный диск / флэшка или диск восстановления. Предупреждение вовсе не дежурное, ибо случаи неадекватного поведения WPT были отмечены у нас на форуме, да и сам я их видел.
Включите автоматический вход в систему, чтобы задержка на ввод пароля не влияла на измерения.
Убедитесь, что на разделе есть несколько гигабайт свободного пространства, поскольку при анализе могут создаваться файлы большого размера.

Все команды выполняйте в командной строке, запущенной от имени администратора. Там же можно добавить в меню пункт для ее запуска в нужной папке – пригодится.

Сбор данных

Все логи загрузки лучше хранить в одной папке, допустим, C:\Trace. Откройте командную строку с полными правами и введите:

md c:\Trace

Здесь и далее я буду использовать пути применительно к этой папке и стандартной установке WPT в 32-разрядной Windows 7. При необходимости изменяйте пути на свои.

Закройте все программы и сохраните все документы. Процесс сбора данных о загрузке системы запускается одной командой:

xbootmgr -trace boot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\Trace

Аналогичные команды можно использовать для диагностики

гибернации:

xbootmgr -trace hibernate -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\Trace

сна:

xbootmgr -trace standby -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\Trace

выключения:

xbootmgr -trace shutdown -noPrepReboot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\Trace

Примечание. Если при выполнении команд вы видите сообщение «xbootmgr не является внутренней или внешней командой», установка была неудачной. Вы найдете решение в этой теме форума.

Вернемся к загрузке, однако. Компьютер будет перезагружен. Если после входа в систему вы увидите запрос UAC от xbootmgr, разрешите утилите продолжить работу. Через две минуты вы увидите примерно такое окно.

Когда оно исчезнет, в папке C:\Trace должно быть три файла, как показано на рисунке ниже.

Если вы вместо файла boot_BASE+CSWITCH+DRIVERS+POWER_1.etl видите там два других файла с расширением ETL, это может означать, что утилита еще работает, над их объединением в один – подождите несколько минут. При отсутствии изменений выполните в командной строке

xperf –stop

и перезагрузите систему. После чего попробуйте заново запустить сбор данных.

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

xbootmgr -remove

Анализируемые файлы и первый взгляд на этапы загрузки

Для анализа используются два файла: ETL и создаваемый из него XML.

ETL

Я думаю, что вы уже успели дважды щелкнуть файл boot_BASE+CSWITCH+DRIVERS+POWER_1.etl и полюбоваться красивыми графиками и диаграммами. В левой панели графики можно отображать и скрывать, а также переходить к ним двойным щелчком мыши.

В WPA из ADK для Windows 10 сводку этапов загрузки можно получить так. Из меню Profiles — Apply — Browse Catalog выберите FullBoot.Boot.wpaprofile. При этом автоматически открывается несколько вкладок с подборками сведений. Для отображения информации на отдельной вкладке из левой панели выберите Regions of interest — FullBoot. Получите такую диаграмму и таблицу.

В ADK для Windows 7 базовый график Boot Phases был доступен сразу

XML

Для удаленной диагностики по почте или в форуме можно создать текстовый отчет в виде XML-файла. Выполните команды:

cd c:\trace
xperf /tti -i boot_BASE+CSWITCH+DRIVERS+POWER_1.etl -o summary_boot.xml -a boot

Первая переходит в папку с логами, а вторая — создает требуемый XML-файл. Для его просмотра отлично подойдет Internet Explorer!

Анализ загрузки с помощью Windows Performance Tools

Увеличить рисунок

Сложите узлы, как показано на рисунке, чтобы лучше видеть общую картину. В узле timing указано время в миллисекундах, и там можно увидеть длительность двух больших, условно говоря, частей загрузки (выделены зеленым):

bootDoneViaExplorer – время загрузки операционной системы вплоть до появления рабочего стола, в данном примере 37 секунд
bootDoneViaPostBoot – полное время загрузки системы, рабочего стола и всех программ в автозагрузке, в данном примере 64 секунды (из этой цифры следует вычесть 10 секунд, в течение которых определяется полное бездействие системы)

Время первой части складывается из основных этапов загрузки операционной системы (обведены синим), вплоть до начала загрузки рабочего стола. В уже знакомом вам событии 100 журнала Diagnostics-Performance длительность этого этапа записывается в параметре MainPathBootTime.

Разница между этими двумя частями – это время от начала загрузки рабочего стола, до его полной готовности. В событии 100 журнала Diagnostics-Performance — это BootPostBootTime.

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

На рисунке ниже представлены три основных этапа загрузки, причем главный из них состоит из четырех фаз.

Увеличить рисунок

Давайте рассмотрим все этапы подробно.

Этап OSLoader

Этап OSLoader следует сразу после инициализации BIOS. Визуально он начинается после заставки и диагностических экранов BIOS, а заканчивается примерно с появлением экрана «Загрузка Windows».

На этапе OSLoader:

загрузчик Windows (winload.exe) загружает основные системные драйверы, которые необходимы для считывания минимально необходимого набора данных с диска
затем загрузчик инициализирует систему до момента, с которого становится возможной загрузка ядра
когда ядро начинает загружаться, winload.exe помещает в оперативную память системный раздел реестра и дополнительные драйверы, помеченные в качестве BOOT_START

Длительность этапа отражает значение параметра osLoaderDuration в узле timing XML-файла. Обычно, она в находится в пределах 2-3 секунд.

Этап MainPathBoot

Визуально этап MainPathBoot начинается с экрана «Загрузка Windows» и завершается при появлении рабочего стола. Если не настроен автоматический вход в систему, длительность этого этапа увеличивается за счет времени, которое требуется для ввода пароля.

Во время этапа MainPathBoot происходит основная работа по загрузке операционной системы:

инициализируется ядро
происходит определение устройств Plug and Play (PnP)
запускаются службы
выполняется вход в систему
инициализируется Explorer, т.е. система готовится к загрузке рабочего стола

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

Фаза PreSMSS

Визуально фаза PreSMSS начинается примерно с экрана «Загрузка Windows», но ее окончание невозможно определить на глаз.

Фаза PreSMSS (в графическом представлении WPT она обозначена как Pre Session Init) начинается с инициализации ядра. Во время нее:

ядро инициализирует структуры данных и компоненты, а затем запускает диспетчер PnP
диспетчер PnP в свою очередь инициализирует драйверы BOOT_START, которые были загружены с помощью winload.exe на этапе OSLoader
когда диспетчер PnP обнаруживает устройство, он загружает необходимый драйвер и выполняет его инициализацию

Диагностика

Если фаза занимает много времени, ищите в XML-файле в узле <PNP> драйвер, который долго загружается. Диагностику в графическом режиме я покажу на примере следующей фазы.

Фаза SMSSInit

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

Фаза SMSSInit (в графическом представлении WPT она обозначена как Session Init) начинается с того, что ядро передает контроль диспетчеру сессий (smss.exe). Во время этой фазы система:

инициализирует реестр
загружает и запускает устройства и вторую волну драйверов, которые не помечены как BOOT_START
запускает процессы подсистемы

Фаза завершается с передачей контроля процессу winlogon.exe.

Диагностика

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

Сократив время запуска драйвера видеокарты, можно уменьшить длительность загрузки системы. Таким образом, если фаза SMSSInit затягивается, обновите драйвер видеокарты.

Более точную диагностику можно провести с помощью summary_boot.xml, где в узле PNP есть длительность запуска каждого драйвера. Впрочем, в Windows 10 он иногда отсутствует, и я не знаю, от чего это зависит и как это форсировать.

⚠ Показанного ниже графика Driver Delays в WPT больше нет, но во времена Windows 7 его можно было анализировать примерно так:

На графике Boot Phases выделите фазу Session Init и выберите из контекстного меню команду Clone Selection. Выбранный период будет выделен на всех активных графиках.
На графике Driver Delays щелкните правой кнопкой мыши и выберите из меню команду Set Delay Threshold. Она позволяет отфильтровать драйверы по времени задержки. Введите, например 2000, чтобы отобразить драйверы, загружавшиеся дольше двух секунд.

Увеличить рисунок

Вы увидите все драйверы, загружавшиеся в фазе Session Init дольше заданного времени. У меня вся фаза занимает 6 секунд, и двухсекундная задержка драйверов является нормальной. Но если у вас проблемы в этой фазе, с помощью фильтра вы сразу увидите, какой драйвер их вызывает.

Фаза WinLogonInit

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

Фаза WinLogonInit начинается сразу после запуска winlogon.exe. Во время этой фазы:

отображается экран приветствия
диспетчер управления службами запускает сервисы
происходит запуск сценариев групповой политики

Фаза завершается запуском оболочки Windows — процесса explorer.exe.

Диагностика

Во время фазы WinLogonInit выполняется множество параллельных операций. На многих системах она характеризуется нагрузкой на процессор и большим количеством операций ввода-вывода (I/O). Длительность фазы во многом зависит от поведения служб.

Чтобы обеспечить плавную загрузку системы, службы могут объявлять зависимости или использовать порядковые группы загрузки. Windows обрабатывает группы загрузки в последовательном порядке. Поэтому задержка даже одной службы в ранней группе может затягивать загрузку следующей группы служб и тормозить весь процесс загрузки.

Для выявления проблемной службы удобнее всего использовать графические возможности WPT. Откройте ETL-файл двойным щелчком мыши и прокрутите отчеты вниз до графика запуска служб.

Увеличить рисунок

Зачастую проблема вызвана не системными, а сторонними службами. На рисунке хорошо видно, что среди автоматически стартующих служб дольше всего загружаются три:

Apache 2.2
MySQL
TeamViewer

При этом Apache блокирует загрузку следующей группы служб (очевидно, в ее отсутствие это сделала бы служба TeamViewer). Поскольку ни одна из этих служб не является системной, проблему легко решить. Можно в оснастке «Службы» изменить тип ее запуска на отложенный и посмотреть, будет ли она быстрее запускаться на более позднем этапе. Если это не дает эффекта, можно вовсе отключить службу и запускать ее вручную при необходимости. Во второй волне служб, имеющих отложенный тип запуска, видна задержка WSearch, отвечающей за поиск Windows, но я не стал ее трогать пока.

Чтобы увидеть время запуска каждой службы, щелкните точку начала запуска и растяните диапазон до ее конца. Для изменения масштаба графика крутите колесо мыши, удерживая нажатой клавишу CTRL.

Отключение трех вышеперечисленных служб позволило сократить общее время загрузки почти на 40 секунд! Обратите внимание, что группа автоматического запуска служб теперь стартовала намного быстрее (смотреть нужно относительно шкалы времени, т.к. масштаб графиков разный).

Wsearch все равно запускается дольше других служб, но уже всего 8 секунд вместо 30, что не дает мне достаточно оснований к ней придираться.

Если задержку вызывает антивирусная программа, отложенный запуск службы может понизить уровень защиты, а ручной запуск или отключение службы могут нарушить работу программы. В этом случае можно лишь посоветовать обновить антивирус до последней версии. Если это не дает эффекта, вам придется сделать выбор между любимой программой и длительностью загрузки.

Фаза ExplorerInit

Визуально фаза ExplorerInit начинается перед загрузкой рабочего стола, но ее окончание определить на глаз невозможно.

В фазе ExplorerInit:

сначала запускается процесс explorer.exe
затем система создает процесс диспетчера окон рабочего стола (DWM)
DWM инициализирует рабочий стол и отображает его

Инциализация DWM и рабочего стола происходит на переднем плане, но в это же время в фоне диспетчер управления службами (SCM) запускает службы, а диспетчер памяти кеширует данные. Поэтому на многих системах эта фаза сопровождается нагрузкой на процессор, и нередко задержки при загрузке на этом этапе можно отнести на счет слабости аппаратных ресурсов.

Диагностика

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

Этап PostBoot

Этап PostBoot начинается после появления рабочего стола и завершается после того, как будет определено бездействие системы.

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

Средства WPT определяют бездействие системы по следующему алгоритму. Каждые 100 мс проверяется наличие активности в системе. Если бездействие системы составляет не менее 80% (за исключением низкоприоритетных процессов и дисковой активности), считается, что в этом интервале система бездействует. Проверка продолжается до тех пор, пока не наберется 10 секунд бездействия. Поэтому, определяя общее время загрузки системы, вычитайте из значения bootDoneViaPostBoot 10000 мс, т.е. 10 секунд.

Диагностика

На этапе PostBoot запускаются приложения, находящиеся в автозагрузке. Чтобы сократить длительность этого этапа, нужно навести там порядок. В графическом представлении WPT используйте график Process Lifetimes, чтобы увидеть все процессы, которые запускаются или продолжают запуск на данном этапе.

Безусловно, диагностика загрузки с помощью WPT требует навыка, и с наскоку разобраться в этом вопросе непросто. Но от вас и не требуется профессиональных знаний, поскольку текстовый отчет в XML файле вкупе с полным графическим представлением всех этапов загрузки позволяет быстро определить причину задержек при запуске Windows. Мне будет очень интересно узнать, полезна ли эта статья, помогла ли она выявить и устранить задержки с помощью WPT, а также насколько ускорилась загрузка системы в результате.

Источник

Время на прочтение5 мин

Количество просмотров170K

А вы никогда не задумывались над тем, что же происходит с операционной системой в тот момент, когда она рисует свой логотип и говорит «Starting Windows»? И вообще, почему она долго загружается? Ведь при старте системы уж точно не решаются никакие задачи, сложные с вычислительной точки зрения!

Что тогда подразумевает под собой загрузка операционной системы? По большей части это проецирование в память исполняемых модулей и инициализация служебных структур данных. Структуры данных живут в памяти, поэтому операции с ними по идее должны быть быстрыми. Все наталкивает на мысль о том, что время съедается именно процессом загрузки исполняемых модулей в память.

Давайте интереса ради разберемся, какие модули, в каком количестве и в каком порядке загружаются при старте ОС. Чтобы выяснить это, можно, например, получить лог загрузки системы. Подопытная ОС в моем случае — Windows 7 Enterprise x64. Логировать процесс загрузки будем при помощи отладчика ядра. Существует несколько вариантов отладчиков ядра, лично я предпочитаю WinDbg. Также нам понадобятся некоторые вспомогательные средства для волшебного превращения лога в нечто более приятное глазу.

Mining and crafting

Настройка отладки хорошо гуглится, поэтому описывать подробно этот процесс я не буду. Поскольку нас интересует все происходящее с момента старта системы, нам нужно отметить пункт «Cycle Initial Break», с помощью чего отладчик остановится, как только в отлаживаемой системе будет загружена подсистема отладки ядра. Дублирование вывода в файл можно осуществить при помощи команд «.logopen» и «.logclose», это просто. Другая полезная команда — «.cls». Она очищает экран команд, и да, только экран команд.

Интересующая нас функция — «MiCreateImageFileMap». Это внутренняя функция менеджера памяти, проецирующая исполняемый файл в память. Проецирование в память происходит при создании секции, например, при запуске исполняемого файла. Однако учтите, что если исполняемый файл проецируется в память, это не гарантия того, что будет выполнен его код! Эта функция просто создает проекцию, чаще всего «про запас», чтобы, если кто-то надумает запустить модуль на исполнение, можно было сэкономить время его загрузки. На эту функцию поставим логирующую точку останова.

Если у вас достаточно маны, вводите следующую команду:

bu nt!MiCreateImageFileMap "dt nt!_EPROCESS -d ImageFileName @$proc; dt nt!_FILE_OBJECT -d FileName @rcx; g"

Магическая строчка буквально означает следующее:

bu (Set Unresolved Breakpoint) — установить неразрешенную точку останова. Не то чтобы кто-то или что-то не разрешал, просто для ее установки необходимо определиться, по какому адресу ее ставить. Дело в том, что заранее не известно, по какому адресу она должна располагаться. При загрузке любого модуля проверяется присутствие в нем необходимой функции, и если такая функция найдена, точка останова устанавливается автоматически. Такой способ установки незаменим при включенном ASLR — рандомизации адресного пространства, поскольку модули будут загружаться каждый раз по разным адресам, и точка останова, установленная по фиксированному адресу, с большой вероятностью окажется не у дел.
nt!MiCreateImageFileMap — символ, на котором нужно останавливаться. В WinDbg принята запись в форме ‘module_name!function_name’. В данном случае nt является предопределенным псевдонимом для ntoskrnl.exe.
далее следует часть WinDbg-скрипта, которая будет выполняться каждый раз при остановке на этой функции. «dt nt!_EPROCESS -d ImageFileName @$proc» по-русски означает «отобразить поле ImageFileName структуры _EPROCESS из модуля nt при условии ее отображения по адресу, определенному в псевдорегистре «текущий процесс»». Следующая после разделителя «;» команда означает примерно то же самое, только адрес структуры берется из регистра rcx, в котором в Microsoft x64 ABI передается первый параметр функции. «g» означает «go», т.е. продолжить исполнение.

Небольшая рекомендация по использованию логирующих точек останова: старайтесь не использовать расширения отладчика (команды, начинающиеся с «!»), поскольку в таком случае логирование будет выполняться на порядок медленнее.

Поехали! Отжимаем тормоз точки останова и ждем. Я ждал, пока не прогрузится рабочий стол, т.е. я залогинился. Полученный «урожай» немного редактируется, обрезается все лишнее для удобства дальнейшей обработки и скармливается дружище питону. Не будем заострять внимание на парсинге лога. Отметим только, что граф укладывался в форму спирали Архимеда с дальнейшей коррекцией вручную, поскольку происходило наложение узлов друг на друга. В полученном графе учитывается порядок загрузки библиотек. К сожалению, пришлось пожертвовать учетом порядка загрузки исполняемых файлов относительно библиотек в угоду удобочитаемости графа.

Карта звездного неба

Условно выделим несколько групп загрузки.

Начинается работа OC в модуле ntoskrnl.exe, являющимся ядром ОС. А если еще конкретнее — с функции KiSystemStartup(). Вместе с загружаемыми системными компонентами она формирует фундамент ОС: разделение режимов работы, базовые сервисы для пользовательских приложений и т.п. В эту же группу входят драйверы, отмеченные для загрузки во время старта системы. В двух словах, в этой ракушке зарождается ОС Windows.

Следующий узел — менеджер сессий (session manager). Его представляет первый после системного процесс, стартующий в Windows — smss.exe. Процесс примечателен тем, что является родным (native) процессом Windows, то есть он не использует подсистему Win32, которая в общем-то еще не загружена. Этот процесс использует только нативные сервисы операционной системы посредством ntdll.dll, представляющей собой интерфейс режима пользователя для сервисов ОС. Также этот процесс является доверенным компонентом операционной системы и обладает исключительными правами, например, он может создавать маркеры безопасности (security tokens). Но главное его предназначение — создание сеансов и инициализация подсистем, как графической, так и различных исполняемых (Windows, POSIX). Эта ракушка воздает каждому по потребностям.

Группа входа в систему (logon) состоит из нескольких процессов. В целом они отвечают за инициализацию сеансов. Это включает в себя отображение экрана приветствия, создание рабочих столов, запуск процессов автозагрузки и инициализацию подсистемы безопасности и т.п. Этот веник отметает всех посторонних.

Самой массивной оказалась группа сервисов. Во многом она обязана своим объемом службе SuperFetch. Эта та самая, про которую говорят, что она по выходным заранее прогружает офисный пакет, а в начале рабочей недели — Steam с игрушками. Superfetch прогружает огромное количество модулей при старте системы, чтобы потом «все быстрее работало». Да и кроме него в системе хватает сервисных приложений и автозапускающихся драйверов. Думаю, все видели оснастку «Службы и приложения». Эта звезда жизни заводит в системе все, что нужно и не очень.

Последним отмечу любимый всеми explorer.exe. Примечательно, что к моменту его запуска все используемые им модули уже загружены в память. В скриншот также попал некий vcredist_x64.exe — бедолага лежал на рабочем столе подопытной виртуальной машины и был прогружен в память проводником.

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

Лично я держу получившуюся картинку под боком. По ней хорошо прослеживаются зависимости, например, драйверов. Также в паре с утилитой Sysinternals Autoruns можно увидеть, на каком этапе загрузки подтягиваются те или иные модули.

Граф загрузки был построен для ОС Windows 7 Enterprise x64, установленной на виртуальной машине VMware. Ниже приведены векторное изображение графа и непосредственно файл в формате gml, с которым можно поиграться в любом редакторе графов.
Граф в формате GML
Векторное изображение графа

Внимание! Бонус!
Граф загрузки для чистой ОС Windows 8 Enterprise x64 на живой машине
Граф в формате GML
Векторное изображение графа

Ингредиенты:
WinDbg @ msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Python @ www.python.org
NetworkX @ networkx.lanl.gov
yEd Graph Editor @ www.yworks.com/en/products_yed_about.html
Руки @ Плечи

Источник

Вчера вечером мне по определенным причинам потребовалось поправить загрузчик Windows 7. И если в Windows XP я просто мог открыть TotalCom и быстренько блокнотом поправить файл boot.ini, то сейчас для этого Microsoft предлагает нам встроенную утилиту BCDEDIT. Но «заморачиваться» с ней вчера вечером у меня не было ни времени ни желанья, поэтому я решил найти для себя более легкий альтернативный вариант, ну а сегодня на работе поглубже вдался в теорию…

Существовавший еще с времен Windows NT, загрузчик операционной системы NTLDR, начиная с Windows Vista, заменен новым диспетчером загрузки BOOTMGR. Вызвано это тем, что старый добрый NTLDR уже не годился для выполнения загрузки системы на компьютерах, использующих спецификацию Extensible Firmware Interface (EFI), призванной заменить базовую систему ввода-вывода BIOS. Модель EFI является новым поколением реализации интерфейса между оборудованием компьютера и операционными системами, и в недалеком будущем полностью заменит просуществовавшую несколько десятилетий модель BIOS. Новый диспетчер загрузки ориентирован на использование специального хранилища конфигурации, приложений и данных спецификации EFI, а также обеспечивает поддержку загрузки операционных систем для предыдущего поколения компьютеров на базе BIOS.

Данная статья не касается особенностей использования BOOTMGR в системах с EFI , и в основном, рассматривает принципы использования диспетчера загрузки на стандартном компьютерном оборудовании, не использующем новый интерфейс.

Механизм загрузки операционной системы Windows 7.
Процесс загрузки любой операционной системы начинается всегда одинаково — после проверки оборудования, управление получает подпрограмма BIOS, (Basic Input/Output System), считывающая с устройства загрузки первый сектор, являющийся главной загрузочной записью MBR ( Master Boot Record ). Стандартно MBR располагается в первом секторе загрузочного диска и занимает 512 байт (стандартная длина сектора). Это не обязательное условие — MBR может занимать более одного сектора, что зависит от конкретной разновидности загрузчика. Хотя запись MBR не является строго зависимой от платформы загружаемой ОС, она отличается, например, для файловых систем DOS, Windows и Linux.

Структура MBR включает в себя 2 основных элемента — программный код первичного загрузчика и таблицу разделов. Обязательным признаком наличия записи MBR является специальный код (сигнатура) в двух последних байтах — 55AA. Наличие сигнатуры проверяется подпрограммой BIOS в первую очередь, и при ее отсутствии, диск считается не загрузочным. Многие программы работы с жесткими дисками позволяют просматривать и редактировать данные выбранных секторов. Так, например, выглядит запись MBR, просматриваемая с помощью бесплатной версии Victoria for Widows

Перед сигнатурой (по смещению 0x1BE относительно начала сектора) располагается таблица разделов (Partition Table), состоящая из 4-х элементов по 16 байт каждый, что определяет максимальное число (не более4-х) первичных разделов на одном жестком диске. Соответственно, размер таблицы разделов — 64 байта.

Каждый элемент таблицы описывает тип раздела (00h — раздел неопределенного типа, попросту — свободное место, 01h — 12 битный FAT, 05h — дополнительный раздел, 07h — NTFS и т.п.),признак активности (возможности загрузки) — код 80h, адрес начала, адрес конца, смещение относительно MBR и размер — количество блоков распределенное данному разделу.

В общем виде, структура главной загрузочной записи MBR, может быть представлена следующим образом:

— программный код и данные начального загрузчика. (446 байт.)
— таблица разделов диска (4 поля по 16 байт — 64 байта)
— сигнатура 55AA (2 байта)

После считывания в оперативную память компьютера, программный код начального загрузчика получает управление и выполняет поиск активного раздела (Active), — раздела, с которого может выполняться загрузка конкретной операционной системы. Такой раздел имеет свою загрузочную запись, называемую загрузочной записью раздела PBR ( Partition Boot Record ) . Содержимое загрузочной записи активного раздела зависит от загружаемой операционной системы и, обычно имеет размер более чем длина одного сектора.

В случае с загрузкой Windows 7 (а также Windows Vista / Server 2008 и последующих ОС семейства Windows) программный код загрузчика раздела выполняет подготовку и выполнение следующего этапа загрузки системы — считывание в оперативную память и передачу управления специальной программе — диспетчеру загрузки BOOTMGR .

Диспетчер загрузки bootmgr представляет собой файл небольшого размера, расположенный в корневом каталоге активного раздела. Основное его предназначение — обеспечение дальнейшей процедуры загрузки в соответствии с существующей конфигурацией, хранящейся в специальном хранилище — хранилище данных конфигурации ( BCD — Boot Configuratin Data ), представляющем собой файл с именем BCD, находящийся в каталоге BOOT активного раздела. Следующий этап загрузки операционной системы обеспечивается уже диспетчером bootmgr в соответствии с существующей конфигурацией. В общем случае, диспетчер загрузки может выполнить не только загрузку ядра установленной на данном компьютере Windows, но и другие, имеющиеся в конфигурации варианты — загрузку Windows NT/2000/XP, операционных систем семейства Linux, загрузку ОС из образов ( файлов wim ) , виртуальных дисков ( файлов VHD ) и т.п.

При стандартной установке операционной системы Windows 7 на новый жесткий диск, в качестве активного раздела используется, автоматически создаваемый при инсталляции в первой части диска, раздел небольшого размера ( около 100Мб). Данному разделу не присваивается буква, и в проводнике он не отображается. Это сделано с целью защиты загрузчика от небезопасных для него действий пользователя — удаления файлов конфигурации или самого диспетчера, сжатия файловой системы и т.п. Кроме того, при такой организации структуры диска, легко реализуется процедура восстановления активного раздела из ранее созданного образа без потери установленной системы и пользовательских данных.

При просмотре в Диспетчере логических дисков, активный раздел отображается под названием «Зарезервировано системой» :

Таким образом, для того, чтобы выполнилась загрузка Windows с диспетчером BOOTMGR, активный раздел, как минимум, должен содержать правильную загрузочную запись PBR, файл диспетчера bootmgr и конфигурационные данные в файле \BOOT\BCD, являющимся системным хранилищем конфигурации загрузки. В случае с загрузкой Windows, диспетчер bootmgrсчитывает из хранилища конфигурации данные, необходимые для загрузки ядра системы, и передает управление приложению, выполняющему следующий этап ( winload.exe ) .

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

Хранилище данных конфигурации загрузки (BCD Store).
Обычно файл bootmgr и каталог \Boot имеет атрибуты «скрытый» и «системный». Для получения доступа к активному разделу стандартными средствами, можно присвоить ему букву и включить отображение скрытых файлов, однако, нужно понимать, что любое неквалифицированное вмешательство в конфигурацию загрузки может привести к невозможности ее выполнения. При чем, неработоспособную конфигурацию загрузки можно получить даже без выполнения вышеперечисленных действий. Например, при неверном использовании стандартного редактора хранилища конфигурации — утилиты командной строки BCDEDIT. Поэтому, прежде чем вносить какие-либо изменения в конфигурацию загрузки, необходимо позаботиться о том, чтобы иметь возможность восстановления работоспособности системы в том случае, когда ее загрузка станет невозможной. Вопросам восстановления загрузки посвящен отдельный раздел статьи и, настоятельно рекомендую, прежде чем приступать к практическим действиям, внимательно ознакомиться с ним.

Программный код диспетчера загрузки , получив управление, выполняет поиск и обработку данных конфигурации загрузки (файл BCD в папке \BOOT\ активного раздела), в соответствии с которыми выполняется дальнейшие этапы загрузки ( отображение меню, выбор загружаемой ОС или средств диагностики, загрузка ядра и т.п. ). По своей структуре, файл \\boot\BCD является кустом реестра и отображается в редакторе реестра Windows как раздел HKEY_LOCAL_MACHINE\BCD0000000x

Таким образом, диспетчер загрузки bootmgr работает с данными хранилища конфигурации загрузки BCD как с обычным разделом реестра Windows. Поскольку, данный раздел реестра предназначен для использования загрузчиком BOOTMGR, при ручном просмотре c использованием редактором реестра, он имеет разрешение только на чтение, которое можно изменить с помощью контекстного меню, вызываемого правой кнопкой мышки. Естественно, на данный раздел реестра, как и на любой другой, распространяются все допустимые действия, выполняемые в редакторе — просмотр, изменение, удаление, импорт и экспорт.

Раздел конфигурации BCD содержит подраздел Description с параметрами описания и подраздел Objects с объектами конфигурации загрузки. Данные конфигурации загрузки можно условно разделить на 3 основных составляющих:

— хранилище BCD (Store)
— записи в хранилище (Entries)
— параметры записей (Entry Options)

Иерархически, хранилище конфигурации загрузки представляет собой совокупность объектов (Objects ), состоящих из отдельных элементов (Elements):

Каждый из объектов представляет собой упорядоченную структуру элементов, обрабатываемую диспетчером загрузки. Существует 3 типа объектов:

— приложения ( application objects)
— наследуемые объекты ( inheritable objects)
— устройства (device objects)

Если вернуться к отображаемой редактором реестра структуре хранилища конфигурации, то заметно, что каждый подраздел раздела Objects имеет имя, представляющее собой глобальный уникальный идентификатор — GUID . Идентификатор GUID формируется программным путем и однозначно является уникальным для той системы, где он создается. Алгоритм формирования GUID построен таким образом, что каждый новый генерируемый идентификатор никогда не совпадает с другим, существующим в данной системе. Обозначается GUID в виде групп из шестнадцатеричных цифр, разделяемых дефисами, и заключенными в фигурные скобки:

{d1f837a2-7e0f-11df-bc8b-f6edb78d41b5}

Некоторые объекты стандартных приложений конфигурации загрузки имеют предопределенные идентификаторы, связывающие некоторые из идентификаторов GUID с внутренними идентификаторами (псевдонимами) редактора bcdedit

Так например, псевдониму {ntldr} используемому в качестве параметра команды bcdedit всегда соответствует GUID, приведенный в таблице — {466f5a88-0af2-4f76-9038-095b170dc21c}.

Каждый из разделов подраздела Objects также состоит из двух подразделов — Descriptions с описанием типа объекта и Elements, определяющего набор элементов с параметрами объекта. В разделе Description имеется ключ Type типа REG_DWORD, значение разрядов 28-31 которого определяет тип объекта ( значение в старшей тетраде старшего байта ) :

0x1 — приложение
0x2 — наследуемый объект
0x3 — устройство.

Имена разделов реестра, связанных с элементами объекта, типы данных и значения параметров зависят от конкретной конфигурации загрузки, созданной для использования диспетчеромBootmgr. Если внимательно присмотреться к именам подразделов, то можно заметить, что имя подраздела связано с его содержимым, так например подраздел с именем 12000004 всегда содержит строковый параметр с текстовым описанием элемента :

[HKEY_LOCAL_MACHINE\BCD00000000\Objects\{b2721d73-1db4-4c62-bf78-c548a880142d}\Elements\12000004]
«Element»=»Диагностика памяти»

Или для элемента конфигурации диспетчера загрузки bootmgr :

[HKEY_LOCAL_MACHINE\BCD00000000\Objects\{9dea862c-5cdd-4e70-acc1-f32b344d4795}\Elements\12000004]
«Element»=»Windows Boot Manager»

С назначением прочих имен подразделов раздела [HKEY_LOCAL_MACHINE\BCD00000000\Objects\. . . \Elements\ и их содержанием можно разобраться по описанию библиотеки элементов BCD на странице msdn.microsoft.com

Вполне понятно, что работать с данными конфигурации BCD в среде редактора реестра практически невозможно, поэтому в Windows Vista и более поздних ОС семейства Windows появилась специальная утилита bcdedit.exe предназначенная для работы с хранилищами конфигурации загрузки ( BCD EDITor ).
Раздел реестра HKEY_LOCAL_MACHINE\BCD00000000 используется, существующим в данной системе диспетчером BOOTMGR, и является системным хранилищем конфигурации ( System BCD Store ). Упоминаемая выше команда для редактирования конфигурации загрузки BCDEDIT может использоваться не только для редактирования системного хранилища, но и любого другого, задаваемого параметром командной строки /store

bcdedit /store D:\BCDBackup\bcdsave — команда BCDEDIT выполняется для хранилища конфигурации загрузки в файле bcdsave каталога BCDBackup на диске D:. Если в командной строкеbcdedit не задан ключ /store — то ее действие выполняется по отношению к системному хранилищу (активной конфигурации, используемой для данной загрузки).

Как уже упоминалось выше, при выполнении команд BCDEDIT к некоторым из объектов хранилища можно применять псевдонимы , например {bootmgr}, (соответствует диспетчеру загрузки ) и {default} (соответствует используемому по умолчанию загрузчику Windows). Для отключения использования псевдонимов в командной строке bcdedit предусмотрен ключ /v:

bcdedit /v /enum all — отобразить все ( all) записи конфигурации загрузки в системном хранилище без использования псевдонимов.

Более подробное описание команды BCDEDIT — можно найти здесь.

Кроме утилиты командной строки BCDEDIT, для работы с конфигурацией загрузки, возможно использование средств инструментария управления Windows — Windows Management Instrumentation (WMI). Провайдер WMI предоставляет программный интерфейс для доступа к элементам конфигурации загрузки и позволяет решать те же задачи, что и редактор bcdedit . Описание элементов WMI для работы с BCD на английском языке — можно найти на страницах Microsoft MSDN

Пример сценария на языке Visual Basic, выполняющего экспорт системного хранилища конфигурации загрузки в файл C:\wmistore:

‘
‘Пример экспорта BCD Store в файл
‘
‘Подключение к WMI
set oLocator = CreateObject( «WbemScripting.SWbemLocator» )
set oRootWMI = oLocator.ConnectServer( «.», «root\wmi» )
oRootWMI.Security_.ImpersonationLevel = 3
‘ Создание объекта BCD
set oBCD = GetObject( «winmgmts:{impersonationlevel=Impersonate,(Backup,Restore)}!root/wmi:BcdStore»)
if Err.number <> 0 then
WScript.Echo «ERROR: Failed to connect to WMI BCD Object»
WScript.Quit(1)
end if

‘ Открытие системного хранилища конфигурации
if not oBCD.OpenStore( «», oBcdStore ) then
WScript.Echo «ERROR: Failed to open the system BCD store»
WScript.Quit(1)
end if
‘Экспорт системного хранилища в файл C:\wmistore
if not oBcdStore.ExportStore( «C:\WMISTORE» ) then
WScript.Echo «ERROR: Failed to export BCD Store»
end if

WScript.Echo «Finished Exporting System BCD»

При работе с системным хранилищем конфигурации, необходим запуск сценария от имени администратора. Это же требование относится и к использованию утилиты BCDEDIT.EXE . Выполнение экспорта системного хранилища конфигурации с помощью утилиты BCDEDIT выглядит немного проще:

bcdedit /export C:\Backup\bcb — выполнить экспорт в файл C:\backup\bcd

Для просмотра содержимого хранилища конфигурации можно воспользоваться командой:

bcdedit /enum all — отобразить все записи в BCD

bcdedit /enum all > C:\enum-all.txt — то же, что и в предыдущем случае, но с выводом результатов в текстовый файл enum-all.txt на диске C: .

Пример конфигурации для диспетчера загрузки:

Диспетчер загрузки Windows
———————
идентификатор {bootmgr}
device partition=Z:
description Windows Boot Manager
locale ru-ru
inherit {globalsettings}
default {current}
resumeobject {52d2064e-3939-11e2-aab2-005056c00008}
displayorder {current}
{d1f837a4-7e0f-11df-bc8b-f6edb78d41b5}
{52d2064c-3939-11e2-aab2-005056c00008}
{52d2064d-3939-11e2-aab2-005056c00008}
toolsdisplayorder {memdiag}
timeout 30

идентификатор — псевдоним или GUID конфигурации диспетчера bootmgr
device — устройство загрузки. Либо буква диска, если она присвоена активному разделу, либо ссылка на раздел без буквы — partition=\Device\HardDiskVolume1 (Volume2 . . . )
description — текстовое описание элемента, в данном случае — диспетчера bootmgr.
locale — используемая локализация (язык элемента)
inherit — наследуемые установки.
default — псевдоним или GUID конфигурации загрузки системы, выполняемой по умолчанию.
resumeobject — GUID конфигурации для приложения, выполняемого при выходе из спящего режима (гибернации). В документации называется приложением возобновления (Windows Resume Application ).
displayorder — задает порядок отображения пунктов меню загрузчика для нескольких операционных систем.
toolsdisplayorder — задает порядок отображения пунктов меню загрузчика для нескольких вариантов средств диагностики.
timeout — время ожидания выбора одного из пунктов меню.

Пример конфигурации элемента загрузки операционной системы Windows Vista и более поздних ОС семейства Windows:

Загрузка Windows
——————-
идентификатор {52d2064f-3939-11e2-aab2-005056c00008}
device partition=C:
path \windows\system32\winload.exe
description Windows 7
locale ru-ru
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
osdevice partition=C:
systemroot \windows
resumeobject {52d2064e-3939-11e2-aab2-005056c00008}
nx OptIn
detecthal Yes

идентификатор — псевдоним или GUID конфигурации для загрузки данной ОС Windows
device — буква, соответствующая логическому диску с установленной ОС Windows.
path — путь приложения загрузки ядра системы.
description — текстовое описание элемента, в данном случае — загружаемой ОС Windows.
osdevice — буква диска для данной ОС
systemroot — корневой каталог загружаемой ОС.
resumeobject — GUID конфигурации для приложения, выполняемого при выходе из спящего режима (гибернации).
nx — настройки безопасности, задающие использование режима предотвращения выполнения данных (Data Execution Prevention, DEP)
detecthal — определение конфигурации оборудования и создание уровня программного доступа к нему.
Большинство параметров элементов конфигурации загрузки можно изменить с помощью утилиты bcdedit.exe с параметром /set:

bcdedit.exe /set {current} nx AlwaysOff — отключить функцию DEP для текущей системы, независимо от наличия аппаратной поддержки DEP.
bcdedit.exe /set {6efb52bf-1766-41db-a6b3-0ee5eff72bd7} nx OptIn — включить функцию DEP для системы с указанным GUID

Примеры изменения конфигурации загрузки можно найти на странице с описанием утилиты командной строки BCDEDIT упоминаемой выше.

Очевидно, что стандартные средства конфигурирования загрузки Windows 7 (а также Windows Vista, Windows Server2008, Windows не очень удобны и, кроме того, не имеют защиты от создания неработоспособной конфигурации для диспетчера загрузки <b<bootmgr< b=»»>. Один неверный параметр сценария WMI, или ошибка в командной строке bcdedit может легко сделать невозможной загрузку ядра системы. Именно поэтому, довольно большой популярностью пользуются программные продукты сторонних производителей с графическим интерфейсом пользователя, позволяющие в несколько щелчков мышью, выполнить наиболее востребованные действия по редактированию конфигурации загрузки. Одной из таких программ является бесплатная для частного некоммерческого использования программа EasyBCD разработанная компанией NeoSmart Technologies. Скачать последнюю версию EasyBCD можно на странице загрузки

Именно этой утилитой я и воспользовался вчера, поправил все что мне было необходимо за 5 сек.

EasyBCD позволяет довольно просто создавать элементы конфигурации загрузки для диспетчера bootmgr, необходимые при выполнении загрузки старых версий Windows, загрузки операционных систем семейства Unix/BSD/Linux, загрузки Windows PE, образов и виртуальных дисков. Имеется возможность сохранения текущей конфигурации загрузки, и ее восстановления из ранее сделанной копии. В целом, программа объединяет в себе возможности нескольких стандартных утилит командной строки Windows для работы с загрузочными данными (bcdboot.exe , bcdedit.exe , bootsect.exe ) . Кроме всего прочего, EasyBCD может использоваться не только в среде ОС Windows ориентированных на загрузку с помощью диспетчера bootmgr, но и в среде Windows XP и даже Windows PE с поддержкой .NET версии 2.0 и выше.

Программа очень проста в использовании и имеет поддержку нескольких языков, включая русский. В качестве примера приведу последовательность действий при создании конфигурации для загрузки ERD Commander из ISO-образа:

— нажимаем кнопку «Добавить запись»

— В правой нижней части окна, обозначенной как «Съемный внешний носитель» выбираем вкладку «ISO»

— Заполняем поле «Имя» — ERD Commander

— Выбираем путь к файлу ISO-образа ERD Commander. Хотя данное окно программы EasyBCD названо «Съемный внешний носитель», файл ISO-образа может быть на любом диске, в том числе и не съемном, например — на системном — C:\ISO\erdc.iso.

— Выбрать режим — «Load from Memory». Поскольку для загрузки из ISO образов, программа EasyBCD использует универсальный загрузчик GRUB, лучше выбирать загрузку из памяти, иначе, загрузка непосредственно с диска не будет выполнена, если файл образа фрагментирован. Это — особенность загрузчика GRUB .

— Нажать кнопку «Добавить»

— Нажать кнопку «Редактировать меню загрузки» в панели инструментов.

— Убедиться в наличии изменений загрузочного меню, при необходимости изменить порядок отображения пунктов или время ожидания и нажать кнопку «Сохранить.»

Важной особенностью программы является то, что кроме редактирования записей конфигурации, имеется возможность создания файлов, содержащих информацию загрузочных секторов для загрузки сторонних операционных систем (Linux / Unix Mac OS, BSD ), что невозможно сделать стандартными средствами Windows. Правда, при использовании ранних версий EasyBCD, некоторые из созданных конфигураций для приложений загрузочных секторов , работали некорректно. В качестве альтернативы EasyBCD, в подобных случаях можно воспользоваться менее функциональной, и не имеющей поддержки русского языка, программой Visual BCD Editor (VBCDE) . Основное окно программы VBCDE оформлено в стиле проводника Windows, а данные BCD отображаются в виде, наиболее соответствующем структуре хранилища.

Страница загрузки Visual BCD Editor

Кроме вышеперечисленных программ, для создания и редактирования данных конфигурации загрузки, можно воспользоваться довольно продвинутой программой BCDTool.exe, не требующей инсталляции и работающей в среде любой версии Windows, в том числе и в среде средств восстановления системы на базе Windows PE ( ERD Commander, MSDaRT, прочие LiveCD ). При весьма скромных размерах, утилита BCDTool имеет поддержку русского языка и позволяет выполнить практически любые операции с данными хранилища BCD:

— редактировать существующее хранилище BCD и/или создавать новое пустое

— создавать отдельные пункты меню конфигурации загрузки и изменять их параметры.

— выполнять экспорт хранилища BCD в файл и импорт из файла в хранилище.

— создавать и редактировать отдельные элементы конфигурации для обеспечения загрузки Windows /XP/2000/Vista/7/8, а также для загрузки Real-Mode (Grub, Linux, DOS ) и загрузки с RAM-диска ( WinPE )

При всех прочих достоинствах данной программы, главным является возможность ее выполнения без установки в среде конкретной операционной системы, что делает ее наиболее подходящим средством , применяемом в комплектах переносимых программ дисков аварийного восстановления системы для устранения проблем с загрузкой Windows. Скачать утилитуBCDTool ver 1.1215 приблизительно 960кб

Устранение проблем с загрузкой Windows 7.
В свете изложенного выше, процесс загрузки на примере Windows 7 можно представить в виде цепочки из последовательно выполняемых этапов:

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

Следующий важный момент — для устранения проблем потребуется загрузка в какой-либо другой системе с компакт-диска, флешки, съемного USB-диска, или по сети. В крайнем случае, перенос диска с проблемной системой на другой компьютер. Самый простой вариант — создать диск аварийного восстановления стандартными средствами Windows 7:

— Перейти в Панель управления
— Выбрать «Архивация и восстановления»
— «Создать диск восстановления системы».

Вставить в привод чистый компакт диск и нажать кнопку «Создать диск»

Созданный диск восстановления системы содержит нужные для загрузки загрузочные записи, файл диспетчера загрузки bootmgr, каталоги BOOT и SOURCES . Диспетчер загрузки bootmgrиспользует конфигурацию из файла \BOOT\bcd с режимом загрузки из образа электронного диска, создаваемого в оперативной памяти. Для создания электронного диска используется файл\BOOT\boot.sdi, а в качестве загружаемого образа используется содержимое файла \SOURCES\boot.wim. Имея представление о механизме загрузки системы с использованием диспетчераbootmgr можно без особых усилий сделать загрузочную флэшку восстановления системы, скопировав на нее файлы и каталоги созданного компакт-диска, и создав необходимую конфигурацию загрузки. Например, следующим образом:

1. Создать загрузочные записи MBR и PBR. Используя командную строку, выполнить :

bootsect /nt60 D: /mbr /force — для флешки, которой присвоена буква D:

2. Сделать активный раздел. Поскольку команда bootsect только записывает необходимый для загрузки диспетчера bootmgr программный код загрузочных секторов, но не меняет флаг активного раздела, нужно его установить, например, с помощью стандартной утилиты для работы с дисками и разделами DISKPART.

— запустить DISKPART.

— в строке приглашения ввести команду для отображения списка дисков:

list disk

— выбрать в качестве текущего диска флешку:

select disk 3 — если флешка отображалась в списке дисков как «Диск 3»

— выбрать раздел на флешке:

select partition 1 — выбрать раздел 1

— сделать текущий раздел флешки активным :

active

Завершить работу с DISKPART командой exit

3. Скопировать содержимое компакт-диска восстановления системы на флешку.

Если флешка уже имела активный раздел ( отображалась в диспетчере логических дисков с признаком «Активный»), то в использовании DISKPART нет необходимости.

Если копирование содержимого компакт — диска на флешку выполнено «один-в-один», с сохранением путей и имен, то изменение конфигурации загрузки для диспетчера не требуется.

Рассмотренный выше пример создания загрузочной флешки можно считать демонстрацией случая, когда загрузка не выполняется при отсутствии признака активности раздела — если его нет, то загрузочная запись раздела PBR не получит управления, и далее, по цепочке, не будет загружен диспетчер bootmgr . Похожий случай наблюдается при установке Windows XP, после того, как на компьютере была установлена Windows Vista / Windows 7. При установке XP, выполняется изменение загрузочных записей для обеспечения загрузки ntldr , а не диспетчера bootmgr . Старый загрузчик, естественно, не поддерживает загрузку новых версий Windows, и после подобной установки, возможна загрузка только установленной системы, или других систем, загрузка которых возможна с использованием ntldr . Для того, чтобы вернуть возможность загрузки Windows 7, сохранив возможность загрузки установленной Windows XP, необходимо восстановить цепочку для загрузки bootmgr и изменить данные в хранилище конфигурации загрузки так, чтобы имелась возможность выбора любой из установленных операционных систем Windows :

— Для восстановления загрузочных записей, можно воспользоваться той же командой bootsect , что использовалась в предыдущем примере, что позволит восстановить передачу управления диспетчеру загрузки bootmgr вместо ntldr.

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

bcdboot C:\WINDOWS — скопировать в системный раздел файлы и каталоги, необходимые для загрузки Windows 7, из каталога C:\WINDOWS, и создать новую конфигурацию BCD

— Для добавления возможности загрузки Windows XP, необходимо создать нужную для загрузки ntldr, запись в хранилище конфигурации BCD, добавить в меню пункт для выбора данной ОС, определить порядок отображения пунктов, и систему, загружаемую по умолчанию. При установке предыдущей версии Windows ( WinXP ), необходимые загрузчику ntldr файлы уже имеются на диске ( boot.ini, ntdetect.com, bootfont.bin).

Пример создания конфигурации загрузки Windows XP с помощью команды bcdedit:

bcdedit /create {ntldr} /d «Microsoft Windows XP» — создать объект для загрузки Windows XP

bcdedit /set {ntldr} device partition=C: — указать устройство загрузки (активный раздел)

bcdedit /set {ntldr} path \ntldr — указать путь к загрузчику ntldr

bcdedit /displayorder {ntldr} /addlast — добавить в конец меню выбора вариантов загрузки новый пункт.

Если команда bcdedit выполняется в среде операционной системы, для которой не определено местонахождение хранилища конфигурации загрузки, или расположение системного хранилища отличается от того, которое будет использоваться диспетчером bootmgr при загрузке с жесткого диска, то необходимо указывать полный путь к файлу bcd в параметре /store :

bcdedit /store D:\BOOT\bcd /create {ntldr} /d «Microsoft Windows XP» — создать объект для загрузки Windows XP в хранилище конфигурации D:\BOOT\bcd

Если создание конфигурации загрузки для Windows XP выполняется с помощью EasyBCD, то файл загрузчика ntldr размещается в подкаталоге \NST активного раздела.

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

BOOTMGR is missing

При повреждении содержимого файла :

Invalid or unsupported executable format

Всем хорошей работы!!!

11.12.2013 —

Опубликовал: |
ms windows 7 desktop

Sorry, the comment form is closed at this time.

Источник