Скрытый секундомер системы, который засекает каждый этап медленной загрузки

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

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

Где живёт журнал производительности и как до него добраться

Скрытый секундомер прячется в журнале событий, в его специальном разделе, посвящённом диагностике производительности. Открывается журнал событий короткой командой через окно выполнения:

eventvwr.msc

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

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

Расшифровка кодов событий от сотни до сто десяти

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

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Diagnostics-Performance/Operational'; Id=100} -MaxEvents 1 | Format-List

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

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

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

Чтение конкретного события и что скрывается в его подробностях

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

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

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

Анализ всех загрузок сразу через командную строку

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

wevtutil qe Microsoft-Windows-Diagnostics-Performance/Operational

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

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Diagnostics-Performance/Operational'; Id=100} | Select-Object TimeCreated, @{N='BootTimeMs';E={$_.Properties[0].Value}} | Format-Table -AutoSize

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

Командный подход особенно полезен при работе с несколькими машинами или при необходимости собрать данные в отчёт. Выгрузить динамику времени загрузки в таблицу для отчёта позволяет PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Diagnostics-Performance/Operational'; Id=100} | Select-Object TimeCreated, @{N='BootMs';E={$_.Properties[0].Value}} | Export-Csv C:\Report\boot-times.csv -NoTypeInformation -Encoding UTF8

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

Связь динамики времени старта с конкретными изменениями

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

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

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

Ограничения метода и сопоставление с другими источниками

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

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

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

Стоит помнить и о том, что сам журнал имеет конечный объём и со временем перезаписывает старые события новыми. Глубина доступной истории ограничена, и очень давние загрузки в нём могут уже не сохраниться. Если нужно следить за динамикой долго, замеры разумно периодически выгружать и сохранять отдельно, накапливая собственную летопись времени загрузки за пределами того, что удерживает журнал. Для разовой диагностики это неважно, а вот для долгого наблюдения за деградацией старта такая внешняя летопись оказывается полезнее, чем оглядка на ограниченную память самого журнала.

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