Как собрать информацию о зависании Windows 7, которая может включать код драйвера и пользовательского режима?

Я испытываю сбой в приложении, который приводит к сбою Windows 7, но не в традиционном сбое «синего экрана смерти», который происходит, когда драйверы устройств или другие процессы в пространстве ядра приводят к сбою всей системы, а, скорее, я вижу блокировка всех процессов пользовательского пространства.

Вот состояние машины:

(1) Движение мыши Windows по-прежнему реагирует, и слой композиции Aero по-прежнему работает (некоторые эффекты наведения мыши в проводнике все еще работают), но не работает процесс win32, а GDI и сеанс пользователя кажутся замороженными. (2) Ctrl+Alt+Delete не вызывает диспетчер задач. (3) Нет аварийных дампов и синего экрана смерти.

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

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


person Warren P    schedule 19.04.2011    source источник
comment
DWM - это процесс Win32;)   -  person 0xC0000022L    schedule 21.04.2011
comment
Действительно? Странно тогда, что все процессы Win32 GDI кажутся заблокированными внутри ядра, на уровне пользователя, который не является критическим процессом, и все же аэроэффекты DWM при наведении мыши все еще работают (на самом деле они работали на несколько секунд дольше, а затем что-то заблокировало их). , слишком).   -  person Warren P    schedule 21.04.2011
comment
все это звучит довольно загадочно. Но спорно пытаться угадать без дополнительных деталей из дампа.   -  person 0xC0000022L    schedule 21.04.2011


Ответы (1)


Загрузите WinDbg и подключитесь к рассматриваемой машине с помощью Firewire или последовательного кабеля (USB также работает при некоторых обстоятельствах IIRC). Это позволит вам искать взаимоблокировки в работающей системе с удаленного компьютера.

Другая возможность — спровоцировать системный сбой (посмертный анализ). Вы должны убедиться, прежде чем установить настройки аварийного дампа на полный дамп. Это создаст аварийный дамп того же размера, что и объем оперативной памяти. Конечно, это может создать проблему при доставке дампа людям (например, через сеть). Также имейте в виду, что в дампе могут содержаться частные данные, в зависимости от обстоятельств.

Как спровоцировать аварийный дамп, я описал здесь, соответствующая часть приведена ниже. Если вы подключены через отладчик ядра, вы также можете спровоцировать создание дампа памяти.


Драйвер(ы) клавиатуры могут вызывать BSOD:

HKLM\CurrentControlSet\Services\kbdhid\Parameters

или (для старых клавиатур PS/2)

HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

И там установите REG_DWORD с именем CrashOnCtrlScroll на 1.

После следующей перезагрузки вы можете принудительно вызвать синий экран с помощью Ctrl+ScrollLk+ScrollLk. Код проверки ошибок в этом случае будет 0xE2 (MANUALLY_INITIATED_CRASH).

person 0xC0000022L    schedule 21.04.2011
comment
Ух ты. БОЛЬШОЙ совет о MANUALLY_INITIATED_CRASH. - person Warren P; 21.04.2011