Как программно узнать, когда ОС полностью загрузилась

[Teranas]

Вы очень хорошо и понятно написали.
Но у меня возникает вопрос, я вот часто использую не %windir%\Explorer.EXE а свою оболочку, и знаю людей которые тоже используют стороннюю оболочку, ваш пример будет корректно работать?
Заранее спасибо всем оптимистам, да и пессимистам тоже.

[Vova_2581]

Ну, если в сторонней оболочке будут работать Shell_NotifyIcon и остальные функции... То, думаю, да. Попробуйте... Код рассчитан на стандартный Windows, а если у Вас, к примеру, Linux то понятно, что может и не работать.

[Хакер]

Хакер не ищет путей к решению проблемы, Хакер ищет причину, для «...НЕ получится... лузеры! Это я вам гарантирую!». Вот в чем вся загвоздка.

Так проблема не была обозначена. Нужно получить величину, которая даром никому не нужна. Если это формулировка проблемы, то её решение состоит в том, чтобы не искать эту величину.

А если я не прав, то не было ответа на ключевой вопрос: ради чего всё это? В каких дальнейших вычислениях будет участвовать искомая величина?

В текущем виде это выглядит так:

Я видел как взрослые дяди, используя хитроумный прибор, измерили какую-то величину. Что именно мерили я понятия не имею, но очень хочу получить прибор, который покажет такую же или близкую величину. Куда буду применять полученное значение — тоже не скажу.

[Хакер]

Код рассчитан на стандартный Windows, а если у Вас, к примеру, Linux то понятно, что может и не работать.

На лицо незнание того. что такое Linux. Это вообще кардинально другая ОС. Не может и не работать, а совершенно гарантированно не будет работать. Даже EXE-файл, который производит на свет VB6, для Linux не будет иметь никакого смысла.

А вот Windows без Explorer или с альтернативной оболочкой очень часто имеет смысл.

[Mikle]

На лицо незнание того. что такое Linux. Это вообще кардинально другая ОС. Не может и не работать, а совершенно гарантированно не будет работать. Даже EXE-файл, который производит на свет VB6, для Linux не будет иметь никакого смысла.

Обычно люди в таких случаях имеют ввиду работу в Линукс под Вайном.

[Vova_2581]

Хакер, Вы невнимательно читаете мои посты, я все написал...

Так проблема не была обозначена.

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

Нужно получить величину, которая даром никому не нужна.

Тогда зачем она нужна Glary и eventvwr??? Уже неверно! У Glary, к примеру, эта величина выступает большими буквами на пол формы, не заметили?

А если я не прав, то не было ответа на ключевой вопрос: ради чего всё это? В каких дальнейших вычислениях будет участвовать искомая величина?

Привожу пример ради чего: я собираюсь оптимизировать работу своей OC, например, улучшить скорость загрузки. Как я это буду измерять??? По Вашему, «на глазок» что ли??? Для этого я беру инструмент, предложенный глубоко почтенным и уважаемым(!) bon818 и начинаю проводить измерение до(!) оптимизации. Получаю, к примеру, время 1 мин 40 сек – это много. Начинаю оптимизацию: удаляю лишнее из автозагрузки, выключаю ненужные службы, чищу реестр, удаляю кукисы и лишние программы, еще что либо и т.д.. После этого провожу повторное измерение и получаю уже время 0 мин 35 сек. Вот Вам и практическое применение! Так что не говорите, что это никому не надо и мы лузеры. Это неправда!

[Хакер]

Тогда зачем она нужна Glary и eventvwr??? Уже неверно!

eventvwr нужен для просмотра событий — любых, разных. В том числе и из своего приложения, написанного на VB6, можно запульнуть в журнал свою запись о каком-то событии.
Что такое Glary я узнал только из этого топика.

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

Теперь самое интересное.
Если стоит задача замерить величину именно тем образом, каким её замеряет какая-то китайская утилита, совершенно непонятно, зачем тогда вообще писать заменитель китайской утилиты. Особенно зачем писать заменитель, если не знаешь как его писать.

Пользуйся Glary и оптимизируй свою систему.

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

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

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

Да и опять же, даже покомпонентно замерять «тупо какое-то время» не слишком продуктивно. Куда продуктивнее замерять время, которое было затрачено выполнением, из него долю времени, проведённую в режиме ядра, а также время, потраченное в ожидании завершения IO-запросов. Тогда можно проанализировать, за счёт чего именно тот или иной процесс срабатывает долго. За счёт IO или за счёт CPU. Если первое, то ускорение процесса возможно за счёт ускорения дисковой подсистемы (например, замены HDD на SDD, или контроллера дисков на более производительный, или режима IDE на режим AHCI). Если второе, то хоть заменяйся диски.

И, в общем, нормальным решением было бы логгирование всего процесса загрузки с помощью ETW (Event Tracing for Windows), и последующий анализ записанной ETW-сессии — либо вручную (привет Process Monitor, ранее FileMon), либо специально написанным собственным анализатором. А вовсе не посыл каких-то сообщений shell'у. Это детский сад.

Вот взять Process Monitor. Инструмент, который позволяет отслеживать, какой процесс что делает. Все обращения к файлам, к портам, к ресурсам, к сети, к реестру ото всех процессов. Сложно найти IT-специалиста, который бы не слышал про FileMon/ProcMon. А ведь вся крутость ProcMon-а лишь в том, что это удобный интерфейс для механизма отслеживания событий ETW, который впервые появился в Windows 2000. Это мощнейший встроенный в Windows инструментарий для отладки и замеров. Бери и пользуйся.

И вот если посмотреть в Process Monitor, то там есть такая опция:

procmon_boot_logging.png (10.96 Кб) Просмотров: 2364

Справка ProcMon-а так описывает эту опцию:

Boot Logging
Process Monitor can log activity from a point very early in the boot process during the initialization of boot-start device drivers. Configure Process Monitor to log the next boot by selecting Enable Boot Logging from the Options menu. Process Monitor's driver will log activity at the next boot into a file in the %Windir% directory and will continue logging through the shutdown or until you run Process Monitor again. Thus, if you don't run Process Monitor during a boot session you will capture a trace of the entire boot to shutdown cycle.

Process Monitor можно логгировать всю активность с самой-самой ранней стадии загрузки Windows. Не сам, конечно, а полагаясь на ETW (всё документированно).

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

Включаем и смотрим:

В моём случае в логе оказывается 2 миллиона событий. Каждое открытие каждого файла, каждое чтение/запись, каждый запуск каждого процесса, каждого потока. Каждое обращение к реестру. Подробнейший расклад с самого раннего момента работы ОС.

Бери и находи нужное, анализируй. Вот такая, к примеру, настройкая фильтрации, оставляет нам только строки с запусками новых процессов:

procmon_exe_map_filter.png (8.04 Кб) Просмотров: 2364

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

procmon_columns.png (19.67 Кб) Просмотров: 2364

procmon_load_chain.png (56.85 Кб) Просмотров: 2364

Откуда становится видно с посекундной детализацией (с точностью до десятимилионных долей секунды), в какой момент времени какие процессы запускались и кто кого запускал.

Что сначала запустилось ядро ntkrnlpa.exe, через 8 секунд ядро породило smss.exe (менеджен сессий), он запустил autochk.exe (проверку диска), затем pgdfgsvc.exe (дефрагментацию файла подкачки от Руссиновича), затем csrss.exe и winlogon.exe

winlogon.exe был запущен спустя 22 секунды от начала запуска ядра и в свою очередь запустил services.exe (через секунду), lsass.exe, а несколько позже — logonui.exe и userinit.exe

userinit.exe запустил explorer.exe, а explorer.exe запустил кучу всего остального.

До запуска userinit.exe видно, как services.exe запускает кучу служб (сервисов), хостя их в svchost.exe

Можно поставить другие параметры фильтрации и посмотреть, например, в деталях, работу autochk.exe — программы проверки дисков:

filters_for_autochk.png (7.92 Кб) Просмотров: 2363

procmon_autochk_work.png (74.72 Кб) Просмотров: 2364

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

Также в поле Duration видно (с точностью до десятимилионных долей секунд), сколько занимает каждая операция.

Можно весь этот огромный поток событий (в котором 2 миллиона записей) анализировать, фильтруя, группируя и суммируя записи. Огромный простор для деятельности.

И, собственно, можно не придумывать велосипед: можно выгрузить из ProcMon-а в XML или CSV и написать свой анализатор для этих файлов, который сам соберёт кучу статистики. Можно не использовать ProcMon и его драйвер, а написать что-то своё, работая напрямую с ETW.

Но главное, что вот оно — истинное направление. ETW. Работа с логом активности напрямую через ETW или анализ того, что захватывают готовые утилиты. Захватывается все действия во всех процессах.

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

[Хакер]

Кстати говоря, ProcMon и временнУю диаграмму в духе диаграмм Ганта для дерева процессов может отображать, из которой видно, кто кого запускал и когда на временной оси:

procmon_gantt.png (26.74 Кб) Просмотров: 2349

[Vova_2581]

Если цель написать свою утилиту для бенчмарков...
Если стоит задача замерить величину именно тем образом, каким её замеряет какая-то китайская утилита...
Если хочется всё-таки написать заменитель...

Хакер, да нет у меня таких задач. Я писал, что тема стала развиваться в сторону получения времени загрузки (условно) и я не стал этому препятствовать. Glary я привел просто, как пример и не более того. Мне нужно только то, что я написал в теме топика и ответ я уже получил (условный!). Конечно же я понимаю, что система не монолитна, что некоторые службы продолжают загружаться после появления рабочего стола и прочее, прочее, прочее, что Вы написали... Мне достаточно чтобы программный код сообщил мне, что рабочий стол появился, и пользователь уже может работать и все! Больше ничего не нужно. Ладно, давайте прекратим споры, я уже получил свой «флаг в руки».

[Teranas]

Так никто и не спорит, все высказывают своё мнение по этой весьма интересной теме.
Кстати интересно было увидеть, что кто-то ещё пользуется bred2.

[ALX_2002]

Ну вот коллеги и случилось то, чего я ждал ) Пришёл Хакер и разъяснил, что куда и как.

Хакер, большое спасибо за пояснение !
Пока встречно возник вопрос. В WMI есть класс Win32_process
У него есть важные нам (как мне кажется) атрибуты: Name, ProcessId, CreationDate, KernelModeTime, UserModeTime

Т.е можно получить дату старта процессов System, smss.exe и т.п. с точностью до микросекунд.

Правильно ли я понимаю, что используя эти данные мы можем вычислить значение BootTime, которое Windows вычисляет и пишет в журнал событием с кодом 100 ?

Или этой информации недостаточно ?

Если это возможно, подскажи пожалуйста, как производится этот расчёт. Здесь вроде бы человек расписывает как это делается, но я не смог до конца разобраться. Можешь "на пальцах" объяснить алгоритм ? )

[Хакер]

Хакер, да нет у меня таких задач.

Тогда вновь непонятно, какова задача.

Мне достаточно чтобы программный код сообщил мне, что рабочий стол появился, и пользователь уже может работать и все! Больше ничего не нужно.

Тогда может быть нужно было смотреть на WaitForInputIdle?

Я ведь неоднократно спрашивал, что нужно: поймать момент готовности рабочего стола, который ещё только предстоит, или же пост-фактум (т.е. возможно, что и через неделю после) вычислить временную разницу между моментом старта ОС и каким-то произвольным моментом в череде событий загрузки.

Кстати интересно было увидеть, что кто-то ещё пользуется bred2.

А в чём с ни проблема? Он быстрее, чем Notepad++, стартует мгновенно (в отличие от последнего), но в отличие от стандартного Блокнота не давится, если ему подсунуть мегабайтный бинарный файл на вход.

Пока встречно возник вопрос. В WMI есть класс Win32_process
У него есть важные нам (как мне кажется) атрибуты: Name, ProcessId, CreationDate, KernelModeTime, UserModeTime

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

А вот ETW позволяет. Более того, возможность узнать времена запусков процессов была лишь малой долей того, что можно получить через ProcMon и ETW. Куда важнее, как мне кажется, то, что можно собрать интегральную статистику по времязатратам на IO-запросы, поступившие ото всех процессов. Можно, например, найти момент, когда в системе висело максимальное число уже начатых, но ещё не выполненных IO-запросов. Подтвердить гипотезу, что выполнение этой пачки параллельных запросов оказалось более медленным, чем если бы они поступали по очереди. Затем выяснить, кем эти IO-запросы были порождены, и понять, какие меры предпринять, чтобы запросы порождались по очереди, а не одновременно. Что. по идее, должно улучить производительность.

Т.е. ковыряние «записи с чёрного ящика» (которую даёт ETW) лучше, чем работа со снимком текущего состояния (который даёт WMI).

Правильно ли я понимаю, что используя эти данные мы можем вычислить значение BootTime, которое Windows вычисляет и пишет в журнал событием с кодом 100 ?

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

Что касается WMI вообще, есть подозрение, что для процесса System корректное значение CreationDate возвращаться не будет.

Если это возможно, подскажи пожалуйста, как производится этот расчёт. Здесь вроде бы человек расписывает как это делается, но я не смог до конца разобраться. Можешь "на пальцах" объяснить алгоритм ? )

Надо читать и изучать. Меня никогда не заботил вопрос измерения времени загрузки. Но в статье, если бегло посмотреть, говорится про некие 10 секунд после загрузки. Тогда схема с расчётом временной разницы через CreationDate уже не даст то, что отображается в журнале событий.

[ALX_2002]

Хакер,

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

А вот ETW позволяет.

Понял. Значит на WMI полагаться не вариант... А жаль...

Что касается WMI вообще, есть подозрение, что для процесса System корректное значение CreationDate возвращаться не будет.

Хм. Проверил на простом коде. Сравнил со значением из Process Explorer. Совпадает.

Код: Выделить всё

Option Explicit
Dim objSWbemObject
For Each objSWbemObject In CreateObject("WbemScripting.SWbemLocator").ConnectServer.ExecQuery("SELECT ProcessId, Name, CreationDate FROM Win32_Process WHERE Name = 'System'")
   With CreateObject("WbemScripting.SWbemDateTime")
      .Value = objSWbemObject.CreationDate
      MsgBox .GetVarDate
   End With
Next


И для Sytem Idle Process c PID 0 тоже верно возращает по запросу

Код: Выделить всё

SELECT CreationDate FROM Win32_Process WHERE ProcessId = 0

Но в статье, если бегло посмотреть, говорится про некие 10 секунд после загрузки. Тогда схема с расчётом временной разницы через CreationDate уже не даст то, что отображается в журнале событий.

Вот тут не до конца понял почему. Потому что за 10 секунд часть процессов уже выгрузится и до них через WMI уже будет не достучаться или в чём-то ещё причина ?

[Teranas]

А в чём с ни проблема? Он быстрее, чем Notepad++

Не, ты не правильно понял, bred2 штука классная, я сам пользовался долго, но со временем его стало маловато и я перешёл на AkelPad. А Notepad++ конечно грузево, только для программных кусков.

[Хакер]

Понял. Значит на WMI полагаться не вариант... А жаль...

В зависимости от цели.

Хм. Проверил на простом коде. Сравнил со значением из Process Explorer. Совпадает.

У меня приведённый код останавливается с ошибкой Type mismatch. Потому что свойство objSWbemObject.CreationDate вместо корректной даты возвращает Null.

creation_time_for_system_process_wmi.png (18.74 Кб) Просмотров: 2318

И Process Explorer тоже ничего не показывает именно для процесса System.

creation_time_for_system_process_procexp.png (21.64 Кб) Просмотров: 2318

Так что чуда не произошло, а ожидание оправдалось — то, что Process Explorer не смог получить через NT API, не может выдать и WMI.

А вот таймстампы, полученные через ETW — валидные.

[ALX_2002]

А у меня под Win 10 напротив дата нормально определяется. Более того даже без повышения прав, не смотря на включенный UAC.

TXVo3Ut.png (67.94 Кб) Просмотров: 2285

И скрипт отображает нормально:

VL4ixRm.png (2.85 Кб) Просмотров: 2285

Странно, что на XP так происходит. Я скорее ожидал ограничений со стороны 10-ки.

А есть примерчик кода по работе с ETW ?

[Хакер]

А есть примерчик кода по работе с ETW ?

Ну в MSDN наверняка есть.

Картинки с imgur.com не загружаются. Зачем он нужен, если есть прекрасный механизм вложений на форуме?

Странно, что на XP так происходит. Я скорее ожидал ограничений со стороны 10-ки.

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

[Teranas]

На семёрке показывает

[ALX_2002]

Ну в MSDN наверняка есть.

Пока не обнаружил подходящего

Картинки с imgur.com не загружаются. Зачем он нужен, если есть прекрасный механизм вложений на форуме?

1) Удобнее, потому что позволяет копипастить изображение из буфера обмена
2) Не на всех форумах приветствуется вставка изображений за счёт вложений. Так как отъедает место.
3) У меня прекрасно изображения грузятся ) Но если надо - переделаю

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

Ну вот на 10-ке это как-то решено. И судя по ответу Teranas-а, на семёрке тоже.

[Vova_2581]

P.S.
Еще одна маленькая новость из детского сада, просто к слову добавить... Решил сравнить показания Glary и кода от bon818. На удивление почти совпадает...

BootTimeComp.jpg (146.17 Кб) Просмотров: 2248