WPTx64 — что это за программа и нужна ли она? (Windows Performance Toolkit)
Приветствую друзья! Иногда можно посмотреть список установленного софта на ПК и удивиться наличию неизвестных программ. Откуда они? Ответ прост — при установке софта часто вместе с ним ставятся и дополнительные компоненты. Особенно это касается тяжелого софта, например Microsoft Office, ПО Adobe.
WPTx64 — что это такое?
Набор средств для оценки производительности Windows.
Данный компонент необходим для работы софта SOLIDWORKS (подробности здесь).
Позволяет анализировать проблемы производительности, включая время запуска приложений, проблемы загрузки, использование ресурсов приложениями и другое.
Возможно компонент имеет отношение к таким встроенным инструментам Windows как Системный монитор и Монитор ресурсов.
WPTx64 является частью пакета SDK и комплекта средств оценки и развертывания Windows. Инфа взята с офф сайта, как понимаю — это часть операционки, поэтому удалять не стоит.
Инструмент Windows Software Development Kit, при помощи которого и можно установить данный компонент:
Или просто в Program Files, без x86. Полное название установщика может быть таким — WPTx64-x86_en-us.
WPTx64 — можно ли удалить?
Важно: при установленном ПО SOLIDWORKS удалять WPTx64 не рекомендуется!
С одной стороны это системный компонент, который нужен для оценки производительности, для определения проблем. Но возможно без него можно обойтись. Чтобы не гадать — перед удалением нужно сделать страховку в виде точки восстановления:
в состав комплекта средств для развертывания и оценки WindowsWindows набор средств производительности входят средства мониторинга производительности, создающие подробные профили производительности Windows операционных систем и приложений. в этой документации обсуждаются Windowsная запись производительности (звч) и анализатор производительности Windows (WPA).
Windows компонентов набор средств производительности
набор средств производительности Windows состоит из двух независимых средств: Windows средства записи производительности (звч) и анализатора производительности (WPA) Windows. Кроме того, поддерживается предыдущее средство командной строки XPerf. Однако Ксперфвиев больше не поддерживается. Все записи должны быть открыты и проанализированы с помощью WPA.
ниже приведены требования к системе для запуска Windows набор средств производительности.
средство записи производительности Windows (звч): Windows 8 или более поздней версии.
средство записи производительности Windows
Основные процедуры и подробное пошаговое руководство см. в быстрое Началое по ЗВЧ. Полную документацию по пользовательскому интерфейсу ЗВЧ см. в разделе функции ЗВЧ. Справочные сведения о параметрах командной строки см. в разделе параметры Command-Line ЗВЧ. Пошаговые инструкции см. в разделах Практическое руководство по ЗВЧ. Дополнительные сведения о ключевых сценариях см. в статье сценарии ЗВЧ. Полный справочный материал, включая XML-ссылку профиля записи и устаревший Справочник по XPerf, см. в справочнике по ЗВЧ.
Windows Performance Analyzer
WPA — это мощное средство анализа, объединяющее очень гибкий интерфейс с обширными возможностями построения диаграмм и таблицами данных, которые могут быть сведены и иметь возможности полнотекстового поиска. WPA предоставляет окно проблем для изучения основной причины любого обнаруженного.
Основные процедуры и подробное пошаговое руководство см. в Краткое руководство по началу работы WPA. Полную документацию по пользовательскому интерфейсу ЗВЧ см. в разделе функции WPA. Пошаговые инструкции см. в разделах Практическое руководство по WPA. Дополнительные сведения о ключевых сценариях см. в статье сценарии WPA.
Одним из богатейших источников информации является провайдер ядра (kernel provider), который генерирует события в моменты запуска процессов и потоков, загрузки DLL, распределения блоков памяти, сетевых операций ввода/вывода и при выполнении трассировки стека. В таблице ниже приводится перечень некоторых наиболее интересных событий, сообщаемых ETW-провайдерами ядра и CLR. Механизм ETW можно использовать для исследования общего поведения системы, например, чтобы выяснить, какой из процессов потребляет большую часть вычислительной мощности CPU, проанализировать узкие места в операциях ввода/вывода, получить статистику, касающуюся работы сборщика мусора и использования памяти управляемыми процессами, и во многих других случаях, обсуждаемых далее.
События ETW несут в себе точное время их возникновения, могут содержать дополнительную пользовательскую информацию, а также состояние стека на момент их появления. Информация о состоянии стека может использоваться для выявления источников различных проблем. Например, провайдер CLR может посылать события в начале и в конце каждого цикла сборки мусора. Эти события в комплексе с информацией о состоянии стека вызовов можно использовать для выявления частей программы чаще других вызывающих сборку мусора.
Неполный список событий ETW в ядре Windows и CLR
Провайдер
Флаг/ключевое слово
Описание
События
Ядро
PROC_THREAD
Запуск и завершение процессов и потоков
Загрузка и выгрузка образов (библиотек DLL, драйверов, выполняемых файлов)
Дисковые операции чтения и записи
Ошибки обращения к страницам диска (которые были вытеснены из кеша в оперативной памяти)
Статистика и информация о работе механизма сборки мусора
Конфликт между потоками выполнения при попытке приобрести разделяемую блокировку
Начало конфликта (поток переведен в режим ожидания), конец конфликта
Информация о состоянии динамического компилятора (Just in Time, JIT)
Успешная попытка встраивания метода, неудачная попытка встраивания метода
Windows Performance Toolkit (WPT)
— это комплект утилит для управления сеансами ETW, сохранения событий ETW в файлах журналов и их обработки для последующего отображения на экране. Может генерировать графики и диаграммы событий ETW, сводные таблицы, включающие информацию о состоянии стека, и файлы CSV для автоматизированной обработки.
В 64-разрядной версии Windows для поддержки возможности трассировки стека необходимо изменить настройки в реестре, запрещающие выгрузку страниц с кодом из оперативной памяти в файл подкачки (для самого ядра Windows и для всех драйверов). Это может увеличить потребление оперативной памяти системой на несколько мегабайт. Чтобы изменить настройки, найдите в реестре ключ HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management, установите параметр DisablePagingExecutive типа DWORD в значение 0x1 и перезагрузите систему.
Для перехвата и анализа событий ETW используются инструменты XPerf.exe и XPerfView.exe. Оба должны запускаться с привилегиями администратора. Утилита XPerf.exe имеет несколько ключей командной строки, с помощью которых можно указать, какие провайдеры должны включаться, размеры используемых буферов, имя файла для сохранения информации о событиях и множество других параметров. Утилита XPerfView.exe анализирует исходную информацию и генерирует графические отчеты на основе информации в файле журнала.
Захват и анализ событий ядра с помощью XPerf
Создайте системную переменную окружения _NT_SYMBOL_PATH со значением, включающим путь к общедоступному серверу символов и локальному кешу символов, например: srv*C:\Temp\Symbols*http://msdl.microsoft.com/download/symbols.
Запустите с правами администратора командную строку и перейдите в каталог установки WPT (например, C:\Program Files\Windows Kits\8.1\Windows Performance Toolkit).
Щелкните правой кнопкой мыши на графике нагрузки на процессор и выберите пункт контекстного меню Load Symbols (Загрузить символы). Щелкните правой кнопкой мыши на графике еще раз и выберите пункт контекстного меню Simple Summary Table (Простая сводная таблица). В результате должна появиться таблица со списком методов во всех процессах, проявлявших активность в процессе сбора информации. (Загрузка символов с сервера Microsoft в первый раз может занять продолжительное время.)
Инструмент WPT способен на большее, чем было показано в этом эксперименте. Вам следует заняться самостоятельными исследованиями пользовательского интерфейса и попробовать принять и проанализировать другие группы событий ядра или даже события от собственных провайдеров ETW. (Создание собственных провайдеров рассматривается далее.)
Инструмент WPT может пригодиться в самых ситуациях, поможет вникнуть в поведение системы и отдельных процессов. Ниже представлено несколько скриншотов и описаний примеров подобных ситуаций:
WPT может перехватывать все события дисковых операций ввода/вывода в системе и выводить информацию с привязкой к карте физического диска. Это дает возможность выявить наиболее дорогостоящие операции ввода/вывода, в частности операции, требующие значительных перемещений головок жесткого диска.
WPT может отображать сводные графики событий разных типов, чтобы проще было выявить корреляцию, например, между операциями ввода/вывода, использованием памяти, нагрузкой на процессор и другими характеристиками.
Если запустить XPerf с провайдером CLR ETW для сбора событий с ключевым словом GCKeyword (0x00000001) и уровнем детализации verbose (0x5), эта утилита послушно будет перехватывать все события, генерируемые провайдером. Сохранив всю полученную информацию в файл CSV или открыв ее с помощью XPerfView, мы сможем (хотя и с трудом) идентифицировать события механизма сборки мусора в нашем приложении.
На рисунке ниже показан пример отчета, созданного утилитой XPerfView, где время между событиями GC /start и GC /stop соответствует протяженности одного цикла работы механизма сборки мусора:
PerfMonitor
— это открытый инструмент командной строки, созданный командой разработчиков BCL в Microsoft, и доступный на сайте CodePlex. На момент написания этих строк самой последней была версия PerfMonitor 2.01. Главное преимущество PerfMonitor перед WPT заключается в полной поддержке событий CLR и способности выводить информацию о них не только в табличном виде. PerfMonitor способен анализировать события, генерируемые сборщиком мусора и JIT-компилятором, выполнять трассировку управляемого стека и определять нагрузку на процессор, оказываемую различными частями приложения.
Для опытных пользователей в состав PerfMonitor включена библиотека с именем TraceEvent, обеспечивающая программный доступ к событиям CLR ETW и позволяющая автоматизировать анализ событий. Библиотеку TraceEvent можно использовать в собственных приложениях мониторинга для автоматического исследования и регистрации событий, протекающих в ходе эксплуатации системы.
Чтобы произвести запуск PerfMonitor с целью выполнить приложение и сгенерировать отчет, нужно использовать следующую команду (в процессе чтения этой статьи вы можете сами поэкспериментировать с инструментом, запуская с его помощью приложение JackCompiler.exe из папки с исходниками):
Различные HTML-файлы отчетов, сгенерированные инструментом PerfMonitor, содержат уже обработанную информацию, но вы всегда можете открыть исходные ETL-файлы с помощью XPerfView или любого другого инструмента, способного читать двоичные файлы журналов с событиями ETW. Сводный отчет для примера выше включает следующую информацию (при выполнении эксперимента на вашем компьютере фактические значения могут отличаться):
На рисунке ниже представлен пример отчета восходящего анализа, где видно, что тремя наиболее активно используемыми методами являются System.String.Concat(), JackCompiler.Tokenizer.Advance() и System.Linq.Enumerable.Contains():
На рисунке ниже представлен пример отчета нисходящего анализа, где видно, что 84.2% процессорного времени было потрачено методом JackCompiler.Parser.Parse(), который вызывает методы ParseClass(), ParseSubDecls(), ParseSubDecl(), ParseSubBody() и так далее:
Детальный отчет для механизма сборки мусора содержит таблицу со статистической информацией о его работе (счетчики, времена) для каждого цикла, а также информация об отдельных событиях, включая продолжительность пауз, объем освобожденной памяти и многое другое. Некоторые из этих сведений пригодятся нам позже, при обсуждении внутреннего устройства сборщика мусора и его влияния на производительность. На следующем рисунке показано несколько строк из отчета об отдельных событиях сборщика мусора:
В ходе сбора информации от нескольких провайдеров ETW могут получаться очень большие файлы журналов. Например, в режиме по умолчанию PertMonitor генерирует примерно 5 Мбайт данных в секунду. Если оставить инструмент работать на несколько дней, он наверняка исчерпает дисковое пространство даже на очень большом жестком диске. К счастью, оба инструмента, XPerf и PerfMonitor, поддерживают циклический режим журналирования, когда в журнале сохраняется только последние N Мбайт данных. В PerfMonitor максимальный размер файла журнала можно указать (в мегабайтах) с помощью ключа /Circular, при этом все старые файлы будут автоматически удаляться при превышении указанного порогового значения.
PerfView
— бесплатный инструмент, разрабатываемый в корпорации Microsoft, объединяющий в себе функции сбора информации от провайдеров ETW и ее анализа, по аналогии с PerfMonitor, а также средства анализа динамической памяти, которые будут обсуждаться в следующей статье, во время знакомства с такими инструментами, как CLR Profiler и ANTS Memory Profiler. Загрузить PerfView можно по адресу: PerfView. Обратите внимание, что инструмент PerfView должен запускаться с привилегиями администратора, потому что требует доступа к инфраструктуре ETW.
В панели со списком файлов (слева) можно видеть дамп динамической памяти и файл с информацией ETW. Ссылки в центральной области окна ведут к разным командам, поддерживаемым инструментом.
Для нужд анализа распределения динамической памяти, который мы вскоре выполним, в исходниках к этой статье включено приложение MemoryLeak.exe. Это приложение будет запускаться с помощью инструмента PerfView, который сгенерирует отчеты со всей информацией, доступной в PerfMonitor, и не только, включая:
простой список событий ETW, полученных от разных провайдеров (например, с информацией о конфликтах в CLR, дисковых операциях ввода/вывода, TCP-пакетах и ошибках чтения страниц);
сгруппированные участки стека вызовов, где приложение провело больше всего времени, с возможностью настройки фильтров и пороговых значений;
участки стека вызовов, соответствующие операциям загрузки образов (сборок), дисковым операциям ввода/вывода и операциям выделения памяти (для каждых 100 Кбайт);
статистика сборщика мусора, включая продолжительность каждого цикла сборки мусора и объем освобожденной памяти.
Кроме того, с помощью PerfView можно сохранять срезы динамической памяти текущего выполняющегося процесса или импортировать их из файла. После импортирования, с помощью PerfView можно найти типы объектов, занимающих наибольший объем памяти и выявить цепочки ссылок, ответственные за удержание этих объектов в памяти.
На рисунке ниже изображен пример анализа ссылок на объекты класса Schedule, которые занимают в динамической памяти 31 Мбайт. PerfView благополучно обнаружил, что ссылки на объекты Schedule хранятся в экземплярах класса Employee, а экземпляры Employee удерживаются в памяти очередью объектов, готовых к завершению.
Собственные провайдеры ETW
Как и при использовании счетчиков производительности, у вас может появиться желание внедрить в свое приложение поддержку возможности сбора и передачи информации, предлагаемой инфраструктурой ETW.
Ниже приводится пример реализации провайдера ETW в управляемом приложении:
Для получения информации из такого приложения можно использовать инструмент PerfMonitor. Запустить с его помощью приложение, произвести сбор
Ускорение загрузки Windows 7 с помощью Windows Performance Toolkit
Один из способов увеличения скорости загрузки ПК, оптимизация и дефрагментация файлов используемых при старте системы.
Так как я не любитель программ от разных производителей, обещающих 1000% прирост скорости ПК, а так же попутно «почистить реестр», используем программу предоставленную компанией Microsoft — Windows Performance Toolkit.
В отличии от разных поделок «все в одном», после использования данной утилиты от Microsoft, ни один ПК не пострадал(за много лет использования). 🙂
Вообще Windows Performance Toolkit, это профайлер — т.е продукт предназначенный для динамического анализа активности программ.
Т.е. оптимизация, это всего лишь часть его функции, в целом он нужен для поиска «узких мест» системы. И если вас интересует подробный анализ загрузки вашего ПК, то с Windows Performance Toolkit стоит ознакомиться более подробно и не в рамках этой статьи.
Оптимизируем процесс загрузки.
Скачиваем веб инсталлятор по ссылке с официального сайта Microsoft — перейти
Либо с данного сайта — скачать
Запускаем файл winsdk_web.exe
В появившемся окне нажимаем Next
Принимаем лицензионное соглашение выставлением пункта I Agree и нажатием кнопки Next Если есть желание можем изменить путь установки пакета, если нет — нажимаем кнопку Next Нам нужен всего один пункт, поэтому снимаем галочки с других пунктов и оставляем только Windows Performance Toolkit, нажимаем Next Все готово к началу загрузки с веб узла Microsoft, нажимаем Next Ожидаем окончания процесса закачки и появления следующего окна Installation Complete, снимаем галочку — View the Windows SDK Release Notes и нажимаем Finish.
Внимание: Если у вас выдало сообщение об ошибке — Installation Failed — решение проблемы в этой статье.
Запускаем командную строку или меню Выполнить (Сочетание клавиш Windows + R).
Нажимаем ОК
Система предупреждает о перезагрузке, соглашаемся.
После перезагрузки у нас появляется окно Delaying for system preparation (run 1 of 6)
Цифра 1 означает первый проход оптимизации из шести, после каждого прохода, система будет перезагружен автоматически.
Так же Windows Performance Toolkit ожидает 120 секунд, ожидая загрузки программ, запускаемых при старте системы.
После шестой перезагрузки, даже без секундомера можно заметить уменьшение времени требуемого для загрузки Windows 7.
Составить полное представление о загрузке 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.
Поскольку набор Windows Performance Toolkit 4.7 для Windows 7 и Vista недоступен для отдельной загрузки, этому вопросу придется уделить чуть больше внимания, чем обычно. Самый простой и экономичный с точки зрения трафика способ – это скачать его с помощью веб-установщика Windows 7 SDK. Пройдя все приветственные окна установщика, вы увидите страницу с выбором компонентов.
Здесь нужно снять все флажки кроме одного, показанного на рисунке и продолжить установку.
Решения некоторых проблем с установкой SDK вы найдете здесь.
Вы, наверное, обратили внимание, что WPT присутствует в двух узлах. Если вам нужны пакеты MSI, их можно скачать, отметив флажок в узле Redistributable Packages. После установки вы найдете пакеты для различных архитектур в папке Program Files\Microsoft SDKs\Windows\v7.1\Redist. Если вы выбрали только этот вариант (вместо рекомендуемого выше), запустите установку двойным щелчком по MSI-пакету.
Подготовка к работе
Следуя трем простым правилам, вы застрахуете себя от возможных проблем, обеспечите правильную работу всех команд и точно измерите длительность загрузки.
Все команды выполняйте в командной строке, запущенной от имени администратора. Там же можно добавить в меню пункт для ее запуска в нужной папке – пригодится.
Сбор данных
Все логи загрузки лучше хранить в одной папке, допустим, C:\Trace. Откройте командную строку с полными правами и введите:
Здесь и далее я буду использовать пути применительно к этой папке и стандартной установке WPT в 32-разрядной Windows 7. При необходимости изменяйте пути на свои.
Закройте все программы и сохраните все документы. Процесс сбора данных о загрузке системы запускается одной командой:
Аналогичные команды можно использовать для диагностики
гибернации:
выключения:
Примечание. Если при выполнении команд вы видите сообщение «xbootmgr не является внутренней или внешней командой», установка была неудачной. Вы найдете решение в этой теме форума.
Вернемся к загрузке, однако. Компьютер будет перезагружен. Если после входа в систему вы увидите запрос UAC от xbootmgr, разрешите утилите продолжить работу. Через две минуты вы увидите примерно такое окно.
Когда оно исчезнет, в папке C:\Trace должно быть три файла, как показано на рисунке ниже.
Если вы вместо файла boot_BASE+CSWITCH+DRIVERS+POWER_1.etl видите там два других файла с расширением ETL, это может означать, что утилита еще работает, над их объединением в один – подождите несколько минут. При отсутствии изменений выполните в командной строке
и перезагрузите систему. После чего попробуйте заново запустить сбор данных.
Примечание. Если в результате сбоя у вас продолжают записываться отчеты после каждой перезагрузки, выполните:
Анализируемые файлы и первый взгляд на этапы загрузки
Для анализа используются два файла: ETL и создаваемый из него XML.
Я думаю, что вы уже успели дважды щелкнуть файл boot_BASE+CSWITCH+DRIVERS+POWER_1.etl и полюбоваться красивыми графиками и диаграммами. В левой панели графики можно отображать и скрывать, а также переходить к ним двойным щелчком мыши.
В WPA из ADK для Windows 10 сводку этапов загрузки можно получить так. Из меню Profiles — Apply — Browse Catalog выберите FullBoot.Boot.wpaprofile. При этом автоматически открывается несколько вкладок с подборками сведений. Для отображения информации на отдельной вкладке из левой панели выберите Regions of interest — FullBoot. Получите такую диаграмму и таблицу.
График Boot Phases отражает длительность основных этапов загрузки, которые мы будем рассматривать подробнее дальше. На нем видно, что последний этап, Post Boot занял 26 секунд (Duration), а общее время загрузки составило 64 секунды (End Time).
Для определения длительности основных этапов загрузки можно выделять их мышью, как показано в нижней части рисунка. Можно также щелкнуть на графике правой кнопкой мыши и выбрать из меню пункт Summary Table, чтобы получить отчет в табличном режиме (верхняя часть рисунка).
Для удаленной диагностики по почте или в форуме можно создать текстовый отчет в виде XML-файла. Выполните команды:
Первая переходит в папку с логами, а вторая — создает требуемый XML-файл. Для его просмотра отлично подойдет Internet Explorer!
Сложите узлы, как показано на рисунке, чтобы лучше видеть общую картину. В узле timing указано время в миллисекундах, и там можно увидеть длительность двух больших, условно говоря, частей загрузки (выделены зеленым):
Время первой части складывается из основных этапов загрузки операционной системы (обведены синим), вплоть до начала загрузки рабочего стола. В уже знакомом вам событии 100 журнала Diagnostics-Performance длительность этого этапа записывается в параметре MainPathBootTime.
Разница между этими двумя частями – это время от начала загрузки рабочего стола, до его полной готовности. В событии 100 журнала Diagnostics-Performance — это BootPostBootTime.
Этапы загрузки Windows и их диагностика
Для анализа загрузки нужно представлять, не только в какой последовательности эти этапы идут, но и что происходит на каждом из них. К сожалению, официальная документация по этому вопросу существует только на английском и достаточно сложна технически. Далее я предлагаю вам выдержки из этого документа в своем изложении, с дополнениями и в сопровождении собственных примеров диагностики.
На рисунке ниже представлены три основных этапа загрузки, причем главный из них состоит из четырех фаз.
Давайте рассмотрим все этапы подробно.
Этап OSLoader
Этап OSLoader следует сразу после инициализации BIOS. Визуально он начинается после заставки и диагностических экранов BIOS, а заканчивается примерно с появлением экрана «Загрузка Windows».
Длительность этапа отражает значение параметра osLoaderDuration в узле timing XML-файла. Обычно, она в находится в пределах 2-3 секунд.
Этап MainPathBoot
Визуально этап MainPathBoot начинается с экрана «Загрузка Windows» и завершается при появлении рабочего стола. Если не настроен автоматический вход в систему, длительность этого этапа увеличивается за счет времени, которое требуется для ввода пароля.
Во время этапа MainPathBoot происходит основная работа по загрузке операционной системы:
Этап состоит из четырех фаз, каждая из которых обладает собственными характеристиками и может по-своему влиять на длительность загрузки системы.
Фаза PreSMSS
Визуально фаза PreSMSS начинается примерно с экрана «Загрузка Windows», но ее окончание невозможно определить на глаз.
Фаза PreSMSS (в графическом представлении WPT она обозначена как Pre Session Init) начинается с инициализации ядра. Во время нее:
Если фаза занимает много времени, ищите в XML-файле в узле
драйвер, который долго загружается. Диагностику в графическом режиме я покажу на примере следующей фазы.
Фаза SMSSInit
Визуально начало фазы SMSSInit невозможно определить. Ее частью является пустой экран, который отображается между заставкой и экраном входа в систему, чье появление сигнализирует о завершении фазы.
Фаза SMSSInit (в графическом представлении WPT она обозначена как Session Init) начинается с того, что ядро передает контроль диспетчеру сессий (smss.exe). Во время этой фазы система:
Фаза завершается с передачей контроля процессу winlogon.exe.
Наиболее распространенной причиной задержек в этой фазе являются драйвер видеокарты. Он инициализируется сначала во время системной сессии, а затем во время пользовательской. При этом инициализация во время пользовательской сессии занимает меньше времени, потому что в течение системной параллельно выполняется запуск других задач.
Сократив время запуска драйвера видеокарты, можно уменьшить длительность загрузки системы. Таким образом, если фаза SMSSInit затягивается, обновите драйвер видеокарты.
Более точную диагностику можно провести с помощью summary_boot.xml, где в узле PNP есть длительность запуска каждого драйвера. Впрочем, в Windows 10 он иногда отсутствует, и я не знаю, от чего это зависит и как это форсировать.
⚠ Показанного ниже графика Driver Delays в WPT больше нет, но во времена Windows 7 его можно было анализировать примерно так:
Вы увидите все драйверы, загружавшиеся в фазе Session Init дольше заданного времени. У меня вся фаза занимает 6 секунд, и двухсекундная задержка драйверов является нормальной. Но если у вас проблемы в этой фазе, с помощью фильтра вы сразу увидите, какой драйвер их вызывает.
Фаза WinLogonInit
Визуально фаза WinLogonInit начинается перед появлением экрана приветствия, а завершается перед появлением рабочего стола.
Фаза WinLogonInit начинается сразу после запуска winlogon.exe. Во время этой фазы:
Фаза завершается запуском оболочки Windows — процесса explorer.exe.
Во время фазы WinLogonInit выполняется множество параллельных операций. На многих системах она характеризуется нагрузкой на процессор и большим количеством операций ввода-вывода (I/O). Длительность фазы во многом зависит от поведения служб.
Чтобы обеспечить плавную загрузку системы, службы могут объявлять зависимости или использовать порядковые группы загрузки. Windows обрабатывает группы загрузки в последовательном порядке. Поэтому задержка даже одной службы в ранней группе может затягивать загрузку следующей группы служб и тормозить весь процесс загрузки.
Для выявления проблемной службы удобнее всего использовать графические возможности WPT. Откройте ETL-файл двойным щелчком мыши и прокрутите отчеты вниз до графика запуска служб.
Зачастую проблема вызвана не системными, а сторонними службами. На рисунке хорошо видно, что среди автоматически стартующих служб дольше всего загружаются три:
При этом Apache блокирует загрузку следующей группы служб (очевидно, в ее отсутствие это сделала бы служба TeamViewer). Поскольку ни одна из этих служб не является системной, проблему легко решить. Можно в оснастке «Службы» изменить тип ее запуска на отложенный и посмотреть, будет ли она быстрее запускаться на более позднем этапе. Если это не дает эффекта, можно вовсе отключить службу и запускать ее вручную при необходимости. Во второй волне служб, имеющих отложенный тип запуска, видна задержка WSearch, отвечающей за поиск Windows, но я не стал ее трогать пока.
Чтобы увидеть время запуска каждой службы, щелкните точку начала запуска и растяните диапазон до ее конца. Для изменения масштаба графика крутите колесо мыши, удерживая нажатой клавишу CTRL.
Отключение трех вышеперечисленных служб позволило сократить общее время загрузки почти на 40 секунд! Обратите внимание, что группа автоматического запуска служб теперь стартовала намного быстрее (смотреть нужно относительно шкалы времени, т.к. масштаб графиков разный).
Wsearch все равно запускается дольше других служб, но уже всего 8 секунд вместо 30, что не дает мне достаточно оснований к ней придираться.
Если задержку вызывает антивирусная программа, отложенный запуск службы может понизить уровень защиты, а ручной запуск или отключение службы могут нарушить работу программы. В этом случае можно лишь посоветовать обновить антивирус до последней версии. Если это не дает эффекта, вам придется сделать выбор между любимой программой и длительностью загрузки.
Фаза ExplorerInit
Визуально фаза ExplorerInit начинается перед загрузкой рабочего стола, но ее окончание определить на глаз невозможно.
В фазе ExplorerInit:
Инциализация DWM и рабочего стола происходит на переднем плане, но в это же время в фоне диспетчер управления службами (SCM) запускает службы, а диспетчер памяти кеширует данные. Поэтому на многих системах эта фаза сопровождается нагрузкой на процессор, и нередко задержки при загрузке на этом этапе можно отнести на счет слабости аппаратных ресурсов.
В течение фазы ExplorerInit ресурсы процессора могут потреблять программы, работающие в качестве служб (например, защитные программы или серверы приложений). Они запускаются либо в этой фазе, либо продолжают свою загрузку, будучи запущенными в более ранних фазах. С другой стороны, некоторые службы (например, с отложенным запуском) могут быть еще не запущены на момент окончания фазы ExplorerInit.
Этап PostBoot
Этап PostBoot начинается после появления рабочего стола и завершается после того, как будет определено бездействие системы.
На этапе PostBoot рабочий стол уже загружен, и с ним можно взаимодействовать. Но при этом параллельно в фоне выполняется различная активность. Например, продолжается запуск служб и программ автозагрузки, что может сопровождаться появлением их значков в области уведомлений.
Средства WPT определяют бездействие системы по следующему алгоритму. Каждые 100 мс проверяется наличие активности в системе. Если бездействие системы составляет не менее 80% (за исключением низкоприоритетных процессов и дисковой активности), считается, что в этом интервале система бездействует. Проверка продолжается до тех пор, пока не наберется 10 секунд бездействия. Поэтому, определяя общее время загрузки системы, вычитайте из значения bootDoneViaPostBoot 10000 мс, т.е. 10 секунд.
На этапе PostBoot запускаются приложения, находящиеся в автозагрузке. Чтобы сократить длительность этого этапа, нужно навести там порядок. В графическом представлении WPT используйте график Process Lifetimes, чтобы увидеть все процессы, которые запускаются или продолжают запуск на данном этапе.
Безусловно, диагностика загрузки с помощью WPT требует навыка, и с наскоку разобраться в этом вопросе непросто. Но от вас и не требуется профессиональных знаний, поскольку текстовый отчет в XML файле вкупе с полным графическим представлением всех этапов загрузки позволяет быстро определить причину задержек при запуске Windows. Мне будет очень интересно узнать, полезна ли эта статья, помогла ли она выявить и устранить задержки с помощью WPT, а также насколько ускорилась загрузка системы в результате.
Наиболее распространенной причиной задержек в этой фазе являются драйвер видеокарты. Он инициализируется сначала во время системной сессии, а затем во время пользовательской. При этом инициализация во время пользовательской сессии занимает меньше времени, потому что в течение системной параллельно выполняется запуск других задач.
