Реально ли устроить мониторинг загрузки ОС из-под другой ОС?
 

Попал мне в руки очередной ноутбук с убитой ОС (черный экран смерти). И возник у меня вопрос: а как в таких случаях можно включить мониторинг запуска системы? Чтобы понять на каком именно этапе все останавливается. Пока что в голову пришло только следующее: снять образ с HDD и разлить потом этот образ на виртуальную машину. По идее, виртуальные машины обходятся драйверами из состава Windows 7, так что загрузиться она должна. И в тот момент, когда дело дойдет до черного экрана - поставить виртуальную машину на паузу и сделать дамп памяти. Можно ли потом будет его чем-то открыть и посмотреть какой файл не найден \ поврежден? Просто удручает сама ситуация, что при наличии черного экрана смерти вернуть систему к жизни удается редко, т.к. абсолютно никаких (!) инструментов для отслеживания хода загрузки поврежденной системы Майкрософт не предусмотрела.

Если получится создать дамп, подкрепите, попробуем посмотреть.

Сделал Snapshot в VMware, потом конвертировал в dmp-формат. Дамп почему-то весит 2Гб (по объёму памяти виртуальной машины), хотя я сильно сомневаюсь, что там вся память забита. В общем, сжал по максимуму через WinRAR, получилось ~200Мб. http://178.173.19.2:1987/Additional/...Virtual-PC.rar - посмотрите. Если что-нибудь удастся полезное узнать, то сообщите, пожалуйста.

P.S. Если что, перед снятием образа с реального компьютера был chkdsk сделан, sfc /scannow тоже сделан - всё пучком, ошибок нет, но ОС не грузится.

Avatar-Lion,

Неполадки с железом.
Учитывая, что дамп, как не крути указывает на \SystemRoot\system32\DRIVERS\intelppm.sys
То скорее всего неисправность процессора.

Если учесть, что процессор качественный - Intel(R) Core(TM) i7 CPU 970 @ 3.20GHz,
но разогнанный:
Остается зайти в BIOS, сбросить настройки по умолчанию,
перезагрузиться в BIOS и определить разогнан процессор или этот эффект дает неисправность.

Заодно просмотрите температуры и вольтаж.

ruslan..., Э-э... Вы, видимо, не прочитали то, что я выше писал... Дамп снят с виртуальной машины. Виртуальная машина развернута на моей рабочей станции (полный конфиг см. в профиле у меня, но i7-970 там действительно есть). Но на исходном ноутбуке (откуда снимался образ дохлой Винды) вообще другой процессор (тоже Intel, но какой-то мобильный Pentium, если ничего не путаю). Так что да, вполне возможно, что после переноса дохлой системы (с клиентского ноутбука) на виртуальную машину (работающую на моем компе) что-то не дозагрузилось или не доустановилось. Я ведь только IDE-драйвер включил в реестре, дабы избежать стоп-кода 7В при старте дохлой ОС на виртуалке. Все прочие драйвера грузятся так же, как они грузились на ноуте. Сейчас на всякий случай скопировал intelppm.sys на ноут с другого компа, но ОС по-прежнему не грузится...

Avatar-Lion,

Ну что же, другого ничего я в дампе не увидел. Возможно кто-то еще, что-то скажет.
Это не поможет. Если дамп объективен, то проблема железная.

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

Кстати, в похожей теме у человека были дампы с самого lsass.exe. У меня ничего похожего нет. Почему у него система делала дампы? Можно ли это как-то принудительно включить, чтобы узнать на каком именно файле загрузка прекращается?

Дамп указывает действительно на железные проблемы с сноской на intelppm.sys .
Но легко сказать: "Замените процессор".
Поэтому я копнул глубже, здесь видимо сказался процесс создания дампа, раз указал на Ваш процессор.
Petya V4sechkin же сказал: " Вам невероятно, сказочно повезло найти эти дампы :) "

Поищите, возможно где-то в системе создаются эти дампы.

ruslan..., Я поиск по всему харду запускал по .dmp - ничего, только всякий хлам от браузера и Аваста. А вообще, кстати, по какому принципу система (возьмем за основу обычную здоровую Винду) может создать дамп для конкретного файла? Что для этого надо сделать?

На клиентском ноутбуке пришлось переустановить Windows, т.к. третий день уже пошёл, а это не есть хорошо. Но зато осталась дохлая Винда на виртуальной машине... В общем, я включил в реестре возможность для ручного вызова BSOD, загрузился и после появления курсора на черном экране подождал примерно полминуты. Виртуальная машина стоит на SSD, поэтому этого времени ей точно должно было хватить для того, чтобы в память загрузилось всё, что только могло загрузиться. Затем нажал Ctrl + 2 x Scroll Lock. Получил BSOD со стоп-кодом E2, который таки записал мне memory.dmp: http://178.173.19.2:1987/Additional/MEMORY-BSOD-E2.rar

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

Avatar-Lion,

Дамп указывает на \SystemRoot\system32\drivers\i8042prt.sys
Если не ошибаюсь порт PS/2, клавиатура или мышь.
Но с помощью i8042prt, вы наверное вызвали ошибку.
Если учесть это, то в глаза мне бросается только это:
Копните в сторону USB драйверов \SystemRoot\system32\DRIVERS\USBPORT.SYS

ruslan...,
Удалил USBPORT.SYS - ничего не изменилось. Кстати, у меня такой вопрос: раз нельзя отследить активность lsass.exe на дохлой системе, то как тогда узнать какие библиотеки загружает lsass.exe? Я пробовал на своей рабочей ОС через Process Explorer смотреть, но он показал, что с lsass.exe в памяти связаны лишь lsasrv.dll и ntdll.dll. Наверняка же lsass.exe куда больше должен компонентов грузить в память при старте. Как этот список загружаемых файлов тогда узнать можно? Помню, во времена Windows XP я пользовался утилиткой BootVis (или как-то так) для отслеживания времени загрузки ОС, но она не умела вроде смотреть кто и что грузит. Чем можно такой список на здоровой Windows 7 составить?

Avatar-Lion,

По моему мы зайдем далеко и не туда :)

У меня такое предложение.
Косвенно понятно, что дело в системных драйверах.
Попробуйте по - экспериментировать. Возможно и поможет. Терять-то уже по моему нечего.
Только запоминайте где проводили изменения на случай возврата.

Как поменять материнскую плату - без переустановки Windows 7

ruslan..., Почему не туда? Мне кажется, это логично: узнать какие файлы подгружает lsass.exe на типичном компьютере и скопировать их в дохлую ОС. Неужели и на здоровой системе это невозможно???

По поводу вашей ссылки: это тут не причем. Дохлая ОС на виртуальной машине грузится до курсора, а значит, драйвер на виртуальный SATA-контроллер работает нормально, иначе бы я получил стандартный стоп 7В. Или вы предлагаете вынести вообще все драйвера из system32\DRIVERS?

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

Не берусь утверждать и не знаю точно, может стоит в поисковиках поискать... чисто теоритически... возможно ли "ручками" прописать в реестре ранний запуск Procmon'а с его умением логгировать этап загрузки ОС. Тут конечно следует уточнить пишет ли Свой RAW он в памяти или же на диск и возможно ли его смаппить/считать в не оконченном виде. При удачном расскладе в Ваших руках окажутся и логи доступа к реестру/ФС.

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

NickM, Я про это сразу подумал. К сожалению, все известные мне методы запуска приложений происходят ПОСЛЕ входа в систему. А тут проблема вся в том, что именно ДО входа надо записать. Тем более что я Process Monitor не до такой степени знаю, чтобы всё автоматизировать. Я попробовал сейчас на здоровой системе включить отслеживание загрузки. Это надо его запустить, поставить галочку, затем комп перезапустить. После загрузки нужно его снова запустить, ответить на пару вопросов - и только тогда он сделает лог. Я понятия не имею какие ключи могут отвечать за автоматизацию таких действий. Если они вообще существуют...

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

Попробовал, кстати, заменить на дохлой Винде файлы lsasrv.dll, lsasrv.dll и ntdll.dll - Винда сдохла окончательно, свалившись при старте в специфический синий экран: STOP-код c0000145.

---
Запустил отслеживание загрузки на здоровой Винде. До того, как будет запущен userinit.exe, lsass.exe читает следующие библиотеки (Windows 7 "Ultimate" 32-bit, может, пригодится кому-нибудь):
C:\Windows\System32\sspisrv.dll
C:\Windows\System32\lsasrv.dll
C:\Windows\System32\samsrv.dll
C:\Windows\System32\cryptdll.dll
C:\Windows\System32\msasn1.dll
C:\Windows\System32\wevtapi.dll
C:\Windows\System32\rpcrt4.dll
C:\Windows\System32\cngaudit.dll
C:\Windows\System32\authz.dll
C:\Windows\System32\ncrypt.dll
C:\Windows\System32\bcrypt.dll
C:\Windows\System32\advapi32.dll
C:\Windows\System32\msprivs.dll
C:\Windows\System32\netjoin.dll
C:\Windows\System32\negoexts.dll
C:\Windows\System32\kerberos.dll
C:\Windows\System32\cryptsp.dll
C:\Windows\System32\ws2_32.dll
C:\Windows\System32\nsi.dll
C:\Windows\System32\mswsock.dll
C:\Windows\System32\wship6.dll
C:\Windows\System32\msv1_0.dll
C:\Windows\System32\netlogon.dll
C:\Windows\System32\dnsapi.dll
C:\Windows\System32\logoncli.dll
C:\Windows\System32\schannel.dll
C:\Windows\System32\crypt32.dll
C:\Windows\System32\wdigest.dll
C:\Windows\System32\rsaenh.dll
C:\Windows\System32\TSpkg.dll
C:\Windows\System32\pku2u.dll
C:\Windows\System32\bcryptprimitives.dll
C:\Windows\System32\efslsaext.dll
C:\Windows\System32\credssp.dll
C:\Windows\System32\scecli.dll

Список представлен не в алфавитном порядке, а именно в том виде, в каком он был указан в логе Process Monitor. Узнать бы еще что из этих файлов SFC считает нужными, дабы сразу исключить их из списка подозреваемых... Хотя согласно этой утилите они все защищены.

а случаем там сторонний крипторовайдер в системе не установлен?

NickM, Без понятия. Но ноутбук домашний, пользуется им пенсионерка, так что вряд ли.

Удалил все файлы из drivers - отказалась грузиться система после этого. Скопировал все файлы из списка выше - снова BSOD c0000145. Что ж... Тему можно закрывать. Видимо, придётся отложить изучение проблемы до появления средств мониторинга загрузки ОС.

А дампы в %windir%\minidump теперь, при BSOD -е, создаются ?

ruslan..., Нет, при таких BSOD'ах как этот дампы не создаются. В общем, удалил виртуальную машину с этой мертвой ОС. Хрен с ней. Времени суммарно два полных дня + два вечера дома потратил на эту мертвую систему. Всё-таки это серьёзный минус Майкрософту, что подобные косяки невозможно мониторить и исправлять.

Avatar-Lion, предположу, что как вариант, т.к. встречались случаи... удалять поочередно последние установленные обновления из WinRE