Отладка зависает, где Ctrl Alt Delete не будет работать

6281
Josh

Мой компьютер недавно застыл на ровном месте, пока я просматривал Интернет. Ctrl-Alt-Delete не работал, поэтому мне пришлось прибегнуть к отключению питания и перезагрузке.

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

Я читал, что вы можете вызвать системный сбой, но после получения дампа памяти ядра, что я мог сделать в windbg, чтобы выяснить, почему он завис?
Будет ли это работать, если я не могу использовать Ctrl-Alt-Delete? Есть ли другие варианты, чтобы выяснить это?

1
Это не сработало бы, потому что вы должны установить значение реестра, а затем перезагрузиться. Таким образом, вы должны были сделать это изменение еще до того, как зависание произойдет. Der Hochstapler 11 лет назад 0
Если ядро ​​заблокировано, вы мало что можете сделать. Вы действительно получили дамп памяти. Это актуальная проблема, с которой вы сталкиваетесь в настоящее время? Ramhound 11 лет назад 0
@OliverSalzburg Я знаю. Интересно, в следующий раз что-нибудь подобное случится. Josh 11 лет назад 0

3 ответа на вопрос

1
Der Hochstapler

When your system freezes there is nothing you can do to analyze the situation. Usually, you won't even be able to do any post-mortem analysis, because no information about the hang is recorded.

The method described in the article you linked is intended to be used by driver developers that have to cause a crash for testing purposes. It would not have helped you in your situation, primarily because you didn't have the registry key set when it happened. If you had it set, you could have caused a crash and would have a memory dump for post-mortem analysis.

What could I do with it?

Probably nothing. When you collected such a dump through a regular crash, it would usually contain easily obtainable information regarding who or what caused the crash. You can get that information by loading the dump into windbg and executing:

!analyze -v

However, if you had enabled the registry option to cause a crash, windbg would indicate that the keyboard driver caused the bug check.

You could check the other processes and threads that were recorded in the dump to find what actually caused the hang. But you should really know what you're doing and/or looking for.

So, what should I do?

The problem with random hangs is that they're random. As long as they appear random, there's nothing you can do. You can observe the behavior long enough until it doesn't appear random anymore.

Once you realize that the problem happens due to a certain pattern, you can start troubleshooting the issue.

0
0xC0000022L

Once you forced a dump file to be generated - which may not even work depending on the problem you encounter - you can use WinDbg to look for possible causes. The first thing to do in such a case would be:

!analyze -hang -v

... but the specifics are determined by the outcome of this and it requires a lot of experience to analyze this kind of stuff. You may not even have all data available to you to track this down to the very end (after all you don't have all symbols).

-2
gronostaj

Memdumps may help you diagnose a problem which caused that memdump to be made. Forcing one won't help you.

Most BSODs are caused by device drivers, try updating those.

Это не правда Принудительный дамп все равно покажет блокировки. Это та самая причина, по которой эта функция была введена в драйвер клавиатуры на первом этапе. 0xC0000022L 11 лет назад 0

Похожие вопросы