#windows-7 #device-driver #crash-dumps #nt-native-api
#windows-7 #драйвер устройства #аварийные дампы #nt-native-api
Вопрос:
Я испытываю сбой в приложении, которое приводит к сбою Windows 7, но не в традиционном «синем экране смерти», который происходит, когда драйверы устройств или другие процессы в пространстве ядра приводят к сбою всей системы, а скорее, я наблюдаю блокировку всех процессов в пространстве пользователя.
Вот состояние компьютера:
(1) Движение мыши Windows по-прежнему реагирует, и слой Aero composition по-прежнему работает (некоторые эффекты наведения курсора мыши в Explorer все еще работают), но ни один процесс win32 не работает, а GDI и пользовательский сеанс, похоже, заморожены. (2) Ctrl Alt Delete не вызывает диспетчер задач. (3) Аварийных дампов нет, и нет синего экрана смерти.
Кто-нибудь знает какой-либо способ собрать дополнительную информацию о сбое? Я знаю, что существуют проблемы на уровне драйвера, и я хотел бы собрать информацию, которую могли бы использовать пользователи уровня драйвера устройства. Когда вы получаете синий экран смерти, вы можете собрать файлы дампа памяти (DMP) и отправить их разработчикам, чтобы помочь. Что я ищу, так это способ отслеживать процессы и состояние системы, возможно, подключить отладчик ядра или что-то в этом роде. Я никогда не выполнял работу с отладчиком ядра, поэтому я ищу способ начать с этого.
Я могу легко воспроизвести сбой в win7 / 32-разрядной виртуальной машине, и у меня еще не установлены средства отладки ядра. Сначала мне интересно, кажется ли, что я выбрал стоящий подход (инструменты отладки ядра?) и если да, то я действительно не знаю, как использовать эти инструменты для сбора информации, которая могла бы помочь разработчикам режима ядра обнаружить проблему.
Комментарии:
1. DWM — это процесс Win32 😉
2. Действительно? Странно, что все процессы Win32 GDI кажутся заблокированными внутри ядра на уровне пользователя, что не является критичным, и все же эффекты DWM aero при наведении курсора мыши все еще работают (на самом деле они выполнялись на несколько секунд дольше, затем что-то заблокировало и их).).
3. все это звучит довольно загадочно. Но пытаться угадать без дополнительной информации из дампа спорно.
Ответ №1:
Загрузите WinDbg и подключитесь к соответствующему компьютеру с помощью Firewire или последовательного кабеля (USB также работает при некоторых обстоятельствах IIRC). Это позволило бы вам искать взаимоблокировки в запущенной системе с удаленного компьютера.
Другая возможность — спровоцировать сбой системы (посмертный анализ). Вы должны убедиться, что перед установкой параметров аварийного дампа установлен полный дамп. Это создаст аварийный дамп того же размера, что и объем вашей оперативной памяти. Конечно, это может создать проблему при передаче дампа пользователям (например, через сеть). Также имейте в виду, что личные данные могут содержаться в дампе, в зависимости от обстоятельств.
Как вызвать аварийный дамп — это то, что я описал здесь, соответствующая часть приведена ниже. Если вы подключены через отладчик ядра, вы также можете спровоцировать создание дампа памяти.
Можно указать, что драйвер (ы) клавиатуры вызывает BSOD:
HKLMCurrentControlSetServiceskbdhidParameters
или (для более старых клавиатур PS / 2)
HKLMSYSTEMCurrentControlSetServicesi8042prtParameters
И там установите REG_DWORD named CrashOnCtrlScroll в 1 .
После следующей перезагрузки вы можете принудительно отобразить синий экран с помощью Ctrl ScrollLk ScrollLk . Код проверки на ошибку в этом случае будет 0xE2 ( MANUALLY_INITIATED_CRASH ).
Комментарии:
1. Вау. ОТЛИЧНЫЙ совет о MANUALY_INITIATED_CRASH.