Вы тут: Главная → Windows → Диагностика медленной загрузки Windows с помощью журнала событий
Сегодня в моем блоге авторский дебют участника конференции OSZone в серию материалов об ускорении загрузки Windows и ее диагностике.
Иногда мы замечаем, что операционная система стала загружаться дольше обычного. Если это эпизодический случай, повода для беспокойства нет. Но когда данное явление приобретает систематический характер или прогрессирует, тут уже стоит задуматься о причинах такого «странного» поведения системы. В этой статье мы рассмотрим один из способов диагностики причин длительной загрузки Windows, используя ее штатное средство – журнал «Просмотр событий». Быстрый доступ к этому инструменту обеспечивает нажатие сочетания клавиш Win+R и последующий ввод команды: eventvwr.msc /s.
На этой странице:
- Фильтруем журнал событий
- Узнаем продолжительность загрузки
- Диагностируем медленную загрузку
Фильтруем журнал событий
В разделе «Microsoft Windows» имеется подкатегория «Diagnostics-Performance», а в ней — операционный журнал, в котором есть категория задачи «Контроль производительности при загрузке» (рис. 1).
Увеличить рисунок
Рисунок 1
Коды событий (Event ID ) в этой категории варьируются от 100 до 110. Просмотрев все события с кодом 100, можно выяснить, сколько времени требуется Windows на загрузку, начиная с самого первого запуска после установки. А проанализировав события в диапазоне от 101 до 110, можно узнать, в каких случаях загрузка замедлялась и почему.
Можно, конечно, просматривать журнал «Diagnostics-Performance» вручную (например, отсортировать по возрастанию столбец «Код события»), но гораздо удобнее создать собственное настраиваемое представление. Это фильтр, который можно сохранить и использовать в дальнейшем для облегчения работы.
Для этого:
- Выберите опцию «Создать настраиваемое представление» из меню «Действие».
- В открывшемся диалоговом окне оставьте значение «Любое время» в поле «Дата» и отметьте флажками все опции в поле «Уровень события». Выберите опцию «По журналу», если она еще не выбрана, и раскройте список. В дереве разделов найдите категорию «Журналы приложений и служб — Microsoft — Windows – «Diagnostics-Performance» и поставьте флажок «Работает» (рис. 2).
- В поле «Включение или исключение кодов событий» введите 100 и нажмите «OK» – (рис. 3). События с кодом 100 показывают, сколько времени уходит на загрузку системы.
- В диалоговом окне «Сохранить фильтр в настраиваемое представление», введите подходящее имя (например, «Boot Time» — Время загрузки) и нажмите «OK» — (см. рисунок 4).
- Далее нам нужно точно таким же образом создать еще одно настраиваемое представление, но в поле «Включение или исключение кодов событий» ввести на этот раз значения 101-110 и сохранить фильтр, например с именем «Замедление загрузки».
Увеличить рисунок
Рисунок 2
Рисунок 3
Рисунок 4
Узнаем продолжительность загрузки
Чтобы выяснить, сколько Windows требуется времени на загрузку на вашем компьютере, выберите в левой части окна, созданный ранее фильтр Boot Time (Время загрузки) в разделе «Настраиваемые представления» и отсортируйте столбец «Дата и время» по возрастанию. Так вы сможете посмотреть, как изменялась продолжительность загрузки системы со дня ее установки (рис. 5).
Увеличить рисунок
Рисунок 5
Из рисунка видно, что длительность самой первой загрузки моей Windows (дата ее установки) по состоянию на 15 марта 2010 года составила 44 498 миллисекунд — или, если разделить на 1000, примерно 45 секунд. Для первого запуска этот показатель нормальный, поскольку после установки система выполняет целый ряд задач: устанавливает драйверы, инициализирует программы в автозагрузке, настраивает профиль пользователя и так далее.
По состоянию на 30 января 2011 года время загрузки возросло, и составило 115652 ms, т.е. почти 2 минуты. Это много.
Настраиваемое представление «Время загрузки» предоставляет информацию обо всех случаях загрузки системы за время ее существования. Иногда загрузка затягивается по вполне объяснимым причинам — из-за установки обновлений, драйверов или программного обеспечения.
На вкладке «Подробности» процесс загрузки описывается во всех деталях, однако для анализа продолжительности загрузки достаточно будет только трех параметров на вкладке «Подробности» (рис 6).
Увеличить рисунок
Рисунок 6
Рассмотрим суть значений этих параметров подробнее.
- Параметр «MainPathBootTime » обозначает временной интервал между возникновением на экране анимированного логотипа Windows и появлением рабочего стола. В этот момент систему уже можно использовать, но в фоновом режиме продолжается загрузка низкоприоритетных задач.
- Параметр «BootPostBootTime » указывает, через какой промежуток времени после появления рабочего стола системой можно начинать пользоваться в полном объеме.
- Параметр «BootTime » — это та же самая величина, что и на вкладке «Общие» обозначена как «Время загрузки». Она представляет собой сумму параметров «MainPathBootTime» и «BootPostBootTime».
И наконец, мы подошли к самому важному и интересному.
Диагностируем медленную загрузку
Чтобы выяснить причину замедления загрузки Windows, выделите фильтр «Замедление загрузки» в левой части окна в разделе «Настраиваемые представления» и отсортируйте столбец «Код события» (Event ID) по возрастающей. Каждый код соответствует определенному событию, увеличивающему продолжительность загрузки.
Всего существует десять кодов событий такого рода, мы же в этой статье рассмотрим только некоторые из них.
- Код события 101. Событие 101 возникает, когда приложение загружается дольше обычного. Это часто связано с установкой обновлений. Если замедление загрузки наблюдается эпизодически, ничего страшного в этом нет. Но если какое-то приложение всякий раз загружается слишком долго или время замедления оказывается ненормально большим, тут нужно уже задуматься.
- Код события 102. Событие 102 свидетельствует о замедлении инициализации драйвера. Это, опять же, может быть вызвано обновлением, но если ситуация возникает регулярно или замедление оказывается серьезным, стоит установить более свежую версию драйвера. Если таковой не имеется, попробуйте удалить и переустановить драйвер.
- Код события 103. Событие 103 возникает при замедлении загрузки служб. Иногда это случается, но если это происходит регулярно, попробуйте изменить тип запуска службы на «Автоматически отложенный запуск» или «Вручную» в консоли «Службы».
- Код события 106. Событие 106 свидетельствует о том, что выполнение фоновой операции по оптимизации затянулось. Поскольку оптимизация — операция продолжительная, ничего страшного в этом нет.
- Код события 109. Событие 109 возникает при замедлении инициализации устройства. Если это явление редкое, беспокоиться не стоит. Но если инициализация затягивается всякий раз, не забывайте регулярно делать резервное копирование и будьте готовы к замене проблемного устройства.
У меня, например, обнаружились два события. Одно с кодом ID 108 :
Увеличить рисунок
Рисунок 7
Другое с кодом 109:
Увеличить рисунок
Рисунок 8
Столь маленькое время задержки на рисунках 7 и 8 не трагично, они приведены тут лишь для наглядности.
Проведенный таким образом анализ и элементарные навыки пользования поиском в сети Интернет, позволят вам составить представление о причинах увеличения времени загрузки операционной системы.
Для определения драйверов, программ и служб, из-за которых Windows загружается медленно, нужно включить логирование процесса запуска операционной системы. В этой статье мы рассмотрим, как создать лог загрузки Windows и проанализировать медленные процессы с помощью утилиты Process Monitor.
Системная утилита Process Monitor обычно используется для отслеживания в реальном времени активности запущенных процессов, обращений к файлам и реестру. Также ProcMon позволяет включить логирование всех процессов, которые выполняются при загрузке Windows, получить время выполнения каждого процесса и сохранить лог в файл для дальнейшего анализа.
- Скачайте и распакуйте архив с Process Monitor (http://download.sysinternals.com/files/ProcessMonitor.zip);
- Запустите procmon.exeс правами администратора;
- В меню Options выберите пункт Enable Boot Logging;
- Выберите опцию Generate thread profiling events -> Every second. В этом режиме драйвер procmon будет записывать состояние всех процессов каждую секунду.
- Сохраните изменения. ProcMon скопирует драйвер procmon23.sys в каталог
%SystemRoot%\System32\Drivers
и создаст отдельную службу (в ветке HKLM\SYSTEM\CurrentControlSet\Services). Эта служба будет запускаться после запуска Winload.exe и будет записывать в лог активность всех процесс, которые выполняются при загрузке Windows и входе пользователя;Чтобы отключить режим протоколирования загрузки, выполните команду:
procmon.exe /noconnect
- Перезагрузите компьютер и дождитесь появления рабочего стола;
- Драйвер procmon23.sys будет писать лог событий до тех пор, пока пользователь вручную не запустит утилиту Process Monitor. После этого режим протоколирования загрузки отключается;
- В окне Process Monitor соглашаемся с предложение сохранить собранные данные в файл bootlog.pml.
Примечание. Если не остановить работу Process Monitor, то временный файл журнала %windir%\procmon.pmb со временем может занять все свободное место на системном диске.
- В моем случае размер файла bootlog.pml около 500 Мб. Откройте этот файл в ProcMon;
- Щелкните по заголовку таблицы в окне ProcMon, выберите Select Columns и включите отображение столбца Duration;
- Теперь нужно изменить параметры фильтрации процессов в меню Filter;
- В качестве параметра фильтрации выберите Duration, условие more than и значение 5. Нажмите Add и ОК.
- В списке процессов останутся только те действия, на которых ушло больше 5секунд (5 секунд я выбрал для наглядности);
- Также для анализа процесса загрузки можно воспользоваться функцией в меню Tools -> Process Tree, позволяющей отобразить все процессы в виде графического дерева с информацией о начале, завершении и длительности процесса;
Проанализируйте список процессов при загрузке, соотнесите процессы со службами, программами и драйверами. Чаще всего в этом списке оказываются антивирусы и другое «тяжелое» ПО.
Например, в этом примере при загрузке компьютер был запущен процесс обновления браузера Edge, который занял почти 4 минуты.
Обновление Edge выполняется отдельным заданием планировщика MicrosoftEdgeUpdateTaskMachineCore, которое выполняется при входе каждого пользователя. Если эта проблема возникает часто, можно отложить выполнение задания, добавив задержку в его расписание.
Также вы можете получить информацию об использовании CPU, RAM и дисков процессами при загрузке. Для этого выберите в меню ProcMon опцию Process Activity Summary.
Здесь вы можете отсортировать процессы и найти наиболее прожорливые процессы, которые используют много процессорного времени или памяти при загрузке.
С помощью Network Summary можно отследить медленные сетевые обращения и процессы, которые загружают/отправляют по сети большие порции данных при загрузке Windows. Например, на скриншоте видно, что при запуске компьютеру пришлось получить около 0.5 Мб данных с контроллера домена.
Выполните анализ всех процессов, которые тормозят загрузку Windows (в первую очередь нужно анализировать дочерние процессы Winlogon.exe). На основании полученной информации нужно выполните оптимизацию системы: удалить/обновить проблемные программы или драйвера, отключить некоторые службы или изменить тип их запуска (отложенный запуск или ручной по запросу), убрать программы из автозагрузки и т.д.
Привет всем! Вчера один клиент попросил меня посмотреть его ноутбук, дело в том, что загружался он у него довольно долго, целых три минуты. Выяснение причины заняло столько же. Если вам интересно, как это у меня получилось, читайте оную небольшую статью.
Много статей и даже книг написано о том, как сократить время запуска операционной системы, советуют все одно и тоже — отключить программы из автозагрузки, затем показывают, где эта автозагрузка находится и как произвести отключение. Я считаю такой подход неправильным, ведь запуск OS может тормозить антивирусная программа, а её вы не отключите из автозагрузки, к тому же у современного пользователя установлено на компьютере несколько десятков программ и многие из них нужны ему в автозапуске. Поэтому, чтобы сделать старт Windows быстрее, нужно первым делом установить — из-за какого именно приложения долго загружается ОС. В дальнейшем уже нужно разбираться с этим приложением, часто помогает переустановка, а если это не поможет, то нужно поискать альтернативу в виде другой программы или какое-то другое решение.
Диагностику медленного старта Windows 10 можно произвести с помощью журнала событий, но способ этот долгий, к тому же не покажет вам виновную программу. Тоже самое я могу сказать о диагностическом пакете «CheckBootSpeed». Ещё можно воспользоваться мудрёным «Windows Performance Analyzer», но начинающие пользователи убегут с сайта, как только я начну о нём рассказывать. Также определить, какое именно приложение более всего тормозит запуск Windows 10 может программа Autoruns и ещё «Autorun Organizer», её нужно запустить и посмотреть общее время загрузки Win 10, затем отключать программы из автозагрузки по одной и так (часов через 12) вы поймёте, почему ваша Windows 10 долго грузится.
{banner_google1}
Друзья, не буду вас томить и покажу на примере ноутбука моего клиента самое простое (на мой взгляд) решение.
Запускаем Диспетчер задач Windows 10.
Подробнее.
Открывается Диспетчер задач, переходим на вкладку «Автозагрузка».
Видим столбцы «Издатель», «Состояние», «Влияние на запуск».
В нашем случае может помочь «Влияние на запуск», но согласитесь, определение «Высокое», это всё равно общее понятие. Хотелось бы знать влияние на запуск в секундах или миллисекундах и это осуществимо.
Щёлкаем правой кнопкой мыши на столбце «Издатель» или любом другом и в выпадающем меню отмечаем пункт «ЦП при запуске».
Появляется новый столбец «ЦП при запуске», отображающий время использования процессора каждым приложением, находящемся в автозагрузке Windows 10. Время показано в миллисекундах (1000 миллисекунд равняется 1-ой секунде). То есть, простыми словами можно сказать, что программа «Download Master» задержало загрузку операционной системы на 3 секунды. Acronis True Image 2017 имеет в автозапуске три сервиса и тормозит старт ОС на 0,5 секунды. А вот странное приложение «Chilschilchik» (оказавшееся вредоносной программой) задерживает запуск системы на целых 10 секунд! Также внимательный читатель может заметить вредоносный браузер «Амиго», чьё влияние на скорость загрузки OS целых 8 секунд.
Ещё при ближайшем рассмотрении ноутбука оказалось, что на нём установлено два антивируса: «Касперский» и «Аваст»! Как так получилось, мой приятель объяснить не смог.
После удаления программы «Download Master», вирусов «Chilschilchik», «Амиго» и одного антивируса, ноутбук стал загружаться за одну минуту, что является неплохим результатом для слабенького железа, из которого он собран.
Статьи, которые вам пригодятся:
- Почему тормозит ноутбук
- Измерение скорости загрузки Windows 10 бесплатной программой BootRacer
Have you ever seen that your computer starts booting slowly? Or it slowly restores its state from hibernation. Maybe you observe performance issues when shutdown or hibernate process? In this article, I will show you how you can use Event Log Explorer to find performance problems linked with the startup/shutdown/hibernate/resume processes.
Starting from Windows Vista, Microsoft provides a bunch of event logs for different system purposes. In Windows Event Viewer, these logs are located in a special branch: “Applications and Services Logs”. Windows records performance diagnostics events into Microsoft-Windows-Diagnostics-Performance/Operational event log. To open this log in Windows Event Viewer, open Applications and Services Logs branch, then open Microsoft, then open Windows, then select Diagnostics-Performance and click on Operational. In Event Log Explorer you can do it easier: open your computer in the tree, then open Microsoft-Windows folder and then click Microsoft-Windows-Diagnostics-Performance/Operational.
Now you can see a list of different diagnostic events. As you can see, events with the same event ID may have different types – Warning, Error and Critical. It looks like these event types depend on the duration of the startup/shutdown process. Another observation – theses events contain many important parameters internally, but you can’t see them in the event description (Windows Event Viewer doesn’t display them as well). The only way to display these parameters is to double click on the event to display event properties and switch to XML tab.
Compare:
Unfortunately, I didn’t find a detailed documentation about all these events, so I did some research. First, I got meaning of events in Microsoft-Windows-Diagnostics-Performance:
| Event ID | Event Description |
| Boot Performance Monitoring | |
| 100 | Windows has started up |
| 101 | This application took longer than usual to start up, resulting in a performance degradation in the system startup process |
| 102 | This driver took longer to initialize, resulting in a performance degradation in the system start up process |
| 103 | This startup service took longer than expected to startup, resulting in a performance degradation in the system start up process |
| 104 | Core system took longer to initialize, resulting in a performance degradation in the system start up process |
| 105 | Foreground optimizations (prefetching) took longer to complete, resulting in a performance degradation in the system start up process |
| 106 | Background optimizations (prefetching) took longer to complete, resulting in a performance degradation in the system start up process |
| 107 | Application of machine policy caused a slow down in the system start up process |
| 108 | Application of user policy caused a slow down in the system start up process |
| 109 | This device took longer to initialize, resulting in a performance degradation in the system start up process |
| 110 | Session manager initialization caused a slow down in the startup process |
| Shutdown Performance Monitoring | |
| 200 | Windows has shutdown |
| 201 | This application caused a delay in the system shutdown process |
| 202 | This device caused a delay in the system shutdown process |
| 203 | This service caused a delay in the system shutdown process |
| Standby Performance Monitoring | |
| 300 | Windows has resumed from standby |
| 301 | This application caused a delay during standby |
| 302 | This driver caused a delay during standby while servicing a device |
| 303 | This service caused a delay during hybrid-sleep |
| 304 | Creation of the hiber-file was slower than expected |
| 305 | Persisting disk caches was slower than expected |
| 306 | Preparing the video subsystem for sleep was slower than expected |
| 307 | Preparing Winlogon for sleep was slower than expected |
| 308 | Preparing system memory for sleep was slower than expected |
| 309 | Preparing core system for sleep was slower than expected |
| 310 | Preparing system worker threads for sleep was slower than expected |
| 350 | Bios initialization time was greater than 250ms (logo requirement) during system resume |
| 351 | This driver responded slower than expected to the resume request while servicing this device |
| 352 | Reading the hiber-file was slower than expected |
| System Performance Monitoring | |
| 400 | Information about the system performance monitoring event |
| 401 | This process is using up processor time and is impacting the performance of Windows |
| 402 | This process is doing excessive disk activities and is impacting the performance of Windows |
| 403 | This driver is using up too many resources and is impacting the performance of Windows |
| 404 | This driver is waiting longer than expected on a device |
| 405 | This file is fragmented and is impacting the performance of Windows |
| 406 | Disk IO to this file is taking longer than expected |
| 407 | This process is using up too much system memory |
| 408 | Many processes are using too much system memory |
| Desktop Window Manager Monitoring | |
| 500 | The Desktop Window Manager is experiencing heavy resource contention |
| 501 | The Desktop Window Manager is experiencing heavy resource contention |
Since we research boot/shutdown/standby/resume performance, we should pay attention to 1xx, 2xx and 3xx events. We can see that events 100, 200 and 300 are basic events followed by 1xx, 2xx and 3xx which give extra information about the problem.
E.g. I can see two events
Event 100 : Windows has started up: Boot Duration : 34857ms IsDegradation : 0 Incident Time (UTC) : 18.11.2015 23:58:10
Event 102: This driver took longer to initialize, resulting in a performance degradation in the system start up process: File Name : mssmbios Friendly Name : System Management BIOS Driver Version : 6.1.7600.16385 (win7_rtm.090713-1255) Total Time : 1027ms Degradation Time : 1026ms Incident Time (UTC) : 18.11.2015 23:58:10
So we can see that System Management BIOS Driver caused the delay in the system boot up.
Unfortunately sometimes events 100, 200 and 300 occur alone without followed events. In this case it is impossible to detect the reason of the delay using Diagnostics-Performance event log.
You should pay attention to parameters of Event 100 (Microsoft-Windows-Diagnostics-Performance):
System ... EventData BootTsVersion 2 BootStartTime 2015-11-18T20:58:10.671600300Z BootEndTime 2015-11-18T20:58:10.671600300Z SystemBootInstance 89 UserBootInstance 84 BootTime 34857 MainPathBootTime 12657 BootKernelInitTime 21 BootDriverInitTime 3101 BootDevicesInitTime 18 BootPrefetchInitTime 0 BootPrefetchBytes 0 BootAutoChkTime 0 BootSmssInitTime 5084 BootCriticalServicesInitTime 436 BootUserProfileProcessingTime 2683 BootMachineProfileProcessingTime 0 BootExplorerInitTime 848 BootNumStartupApps 24 BootPostBootTime 22200 BootIsRebootAfterInstall false BootRootCauseStepImprovementBits 0 BootRootCauseGradualImprovementBits 0 BootRootCauseStepDegradationBits 4 BootRootCauseGradualDegradationBits 0 BootIsDegradation False BootIsStepDegradation false BootIsGradualDegradation false BootImprovementDelta 0 BootDegradationDelta 0 BootIsRootCauseIdentified true OSLoaderDuration 735 BootPNPInitStartTimeMS 21 BootPNPInitDuration 1342 OtherKernelInitDuration 332 SystemPNPInitStartTimeMS 1665 SystemPNPInitDuration 1776 SessionInitStartTimeMS 3451 Session0InitDuration 2088 Session1InitDuration 339 SessionInitOtherDuration 2656 WinLogonStartTimeMS 8536 OtherLogonInitActivityDuration 587 UserLogonWaitDuration 3551
Most of parameters are self-descriptive.
Pay attention that BootTime= MainPathBootTime + BootPostBootTime
MainPathBootTime is the time (in milliseconds) from when the Windows Logo first appears on screen and until your desktop or logon prompt is presented.
BootPostBootTime is the time (in milliseconds) from the logon screen or desktop showing up and until the system become actually usable (the system has reached 80% idle).
In many cases (but not in my sample), the problem with long boot time is linked with Windows Prefetcher – you will see that BootPrefetchInitTime is set to a large value, e.g. 60000 or more. In this case you can play with Superfetch service and Superfetch caching parameters (registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters). If you have just changed your HDD or SSD, you should re-run the assessment in Performance Information and Tools applet (or just run Winsat command as winsat.exe diskformal) to make Windows use the best prefetch strategy.
Now you have some background information about Diagnostics-Performance events. In the next part I will show how Event Log Explorer helps to detect boot performance issues.
В «Просмотре событий» Windows 7 появилась новая категория — «Журналы приложений и служб» (Applications and Services Logs), включающая массу подкатегорий, посвященных ключевым компонентам системы. В большинстве этих подкатегорий содержатся журналы операций (Operational), фиксирующие события, которые можно использовать для анализа и диагностики проблем. Другие типы журналов — административные (Admin), аналитические (Analytic) и отладочные (Debug), но рассказ о них выходит за пределы данной статьи.
В разделе «Microsoft | Windows» имеется подкатегория «Diagnostics-Performance», а в ней — операционный журнал, в котором есть категория задачи «Контроль производительности при загрузке» (Task Category: Boot Performance Monitoring). Коды событий (Event ID) в этой категории варьируются от 100 до 110. Просмотрев все события с кодом 100, можно выяснить, сколько времени требуется Windows 7 на загрузку, начиная с самого первого запуска после установки. А проанализировав события в диапазоне от 101 до 110, можно узнать, в каких случаях загрузка замедлялась и почему.
Запуск средства «Просмотр событий»
Запустить средство «Просмотр событий» можно из раздела Панели управления «Система и безопасность | Администрирование» (Control Panel | System and Security | Administrative Tools). Но куда проще ввести в строке поиска меню «Пуск» (Start) ключевое слово «событий» («event» для англоязычного интерфейса, без кавычек) и нажать [Enter], когда в списке результатов появится «Просмотр событий».
Создание настраиваемого представления
Можно, конечно, просматривать журнал «Diagnostics-Performance» вручную, но гораздо удобнее создать настраиваемое представление — по сути фильтр, который можно сохранить и использовать в дальнейшем. Для этого выберите опцию «Создать настраиваемое представление» (Create Custom View) из меню «Действие» (Action).
В открывшемся диалоговом окне оставьте значение «Любое время» (Any Time) в поле «Дата» (Logged) и отметьте флажками все опции в поле «Уровень события» (Event level). Выберите опцию «По журналу» (By Log), если она еще не выбрана, и разверните выпадающее меню. В дереве разделов найдите категорию «Журналы приложений и служб | Microsoft | Windows | Diagnostics-Performance» и поставьте флажок «Работает» (Operational), как показано на рис. A.
Рисунок A. В разделе «Diagnostics-Performance» поставьте флажок «Работает».
В поле «Включение или исключение кодов событий» (Includes/Excludes Event IDs) введите 100 (рис. B) и нажмите «OK».
Рисунок B. События с кодом 100 показывают, сколько времени уходит на загрузку системы.
В диалоговом окне «Сохранить фильтр в настраиваемое представление» (Save Filter to Custom View, рис. C) введите подходящее имя (например, «Длительность загрузки») и нажмите «OK».
Рисунок C. Чтобы сохранить фильтр как настраиваемое представление, присвойте ему подходящее имя — например, «Длительность загрузки».
Теперь точно таким же образом создайте еще одно настраиваемое представление, но в поле «Включение или исключение кодов событий» введите 101-110 и сохраните фильтр с именем «Замедление загрузки».
Как узнать продолжительность загрузки
Чтобы выяснить, сколько Windows 7 требуется времени на загрузку на вашем компьютере, выберите созданный ранее фильтр «Длительность загрузки» в разделе «Настраиваемые представления» (Custom Views) и отсортируйте столбец «Дата и время» (Date and Time) по возрастанию. Так вы сможете посмотреть, как изменялась продолжительность загрузки системы со дня ее установки. На рис. D я скрыл дерево консоли и панель действий, чтобы сконцентрироваться на событиях.
Рисунок D. Отсортировав столбец «Дата и время» по возрастанию, вы сможете посмотреть, как изменялась продолжительность загрузки системы со дня ее установки.
Как видите, длительность самой первой загрузки системы на моем компьютере в октябре 2009 года составила 67 479 миллисекунд — или, если разделить на 1000, около 67 секунд. Для первого запуска это нормально — ведь после установки система выполняет целый ряд задач: устанавливает драйверы, инициализирует программы в автозагрузке, создает кэш SuperFetch. К декабрю 2009 года средняя продолжительность загрузки стабилизировалась на уровне около 37 секунд.
Настраиваемое представление « Длительность загрузки» предоставляет информацию обо всех случаях загрузки системы за время ее существования. Иногда загрузка затягивается по вполне объяснимым причинам — из-за установки обновлений, драйверов или программного обеспечения.
На вкладке «Подробности» (Details) процесс загрузки описывается во всех деталях (рис. E). Подробнее об этапах запуска системы можно почитать в
официальной статье Microsoft, но для анализа продолжительности загрузки достаточно будет всего трех параметров на вкладке «Подробности».
Рисунок E. На вкладке «Подробности» процесс загрузки описывается в мельчайших деталях.
Оцените статью: Голосов