Вызвать синий экран смерти с помощью управляемого кода

Клавиатура, вероятно, хороший вариант, но если вам нужно сделать это с помощью кода, продолжайте читать...

На самом деле вам не нужно ничего блевать, все, что вам нужно сделать, это найти функцию KeBugCheck(Ex) и вызвать ее.

http://msdn.microsoft.com/en-us/library/ms801640.aspx http://msdn.microsoft.com/en-us/library/ms801645.aspx

Для сбоев, инициированных вручную, вы хотите использовать 0xE2 (MANUALLY_INITIATED_CRASH) или 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) в качестве кода проверки ошибок. Они зарезервированы явно для этого использования.

Однако поиск функции может оказаться немного сложным. Windows DDK может помочь (проверьте Ntddk.h) - в данный момент у меня его нет, и я не могу найти решающую информацию прямо сейчас - я думаю, что он находится в ntoskrnl.exe или ntkrnlpa.exe, но я не уверен, и в настоящее время у меня нет инструментов для его проверки.

Возможно, вам будет проще просто написать простое приложение на C++ или что-то, что вызывает функцию, а затем просто запустить это.

Имейте в виду, я предполагаю, что Windows не блокирует вам доступ к функции из пользовательского пространства (.NET может иметь некоторые специальные положения). Я не проверял это сам.

Я не знаю, действительно ли это работает, и я уверен, что вам нужны права администратора, но вы можете установить ключ реестра CrashOnCtrlScroll, а затем использовать SendKeys для отправки CTRL+Scroll Lock+Scroll Lock.

Но я считаю, что это ДОЛЖНО исходить из драйвера клавиатуры, поэтому я думаю, что простой SendKeys недостаточно хорош, и вам нужно либо каким-то образом подключиться к драйверу клавиатуры (звучит очень грязно), либо проверить, что CrashDump имеет API, который может вызываться с помощью P/Invoke.

http://support.microsoft.com/kb/244139

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
Имя: CrashOnCtrlScroll
Тип данных: REG_DWORD
Значение: 1
Перезапустить

Я должен был бы сказать нет. Вам придется p/invoke и взаимодействовать с драйвером или другим кодом, который находится в пространстве ядра. Код .NET находится далеко в стороне от этой области, хотя и были разговоры об управляемых драйверах в будущих версиях Windows. Просто подождите еще несколько лет, и вы можете разбиться, как наши неуправляемые друзья.

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

Вы не можете запускать управляемый код в режиме ядра. Поэтому, если вы хотите получить BSOD, вам нужно использовать PInvoke. Но даже это достаточно сложно. Вам нужно сделать несколько действительно причудливых PInvokes, чтобы что-то в режиме ядра вызывало рвоту.

Но среди тысяч пользователей SO наверняка есть кто-то, кто это делал :-)

Вы можете использовать инструмент OSR Online, который вызывает сбой ядра. Я никогда не пробовал это сам, но я думаю, вы могли бы просто запустить его через стандартный класс .net Process:

http://www.osronline.com/article.cfm?article=153

Однажды мне удалось безответственно сгенерировать BSOD в Windows XP, используя System.Net.Sockets в .NET 1.1. Я мог бы повторять это довольно регулярно, но, к сожалению, это было пару лет назад, и я точно не помню, как я это запустил, и исходный код больше не у меня.

Попробуйте вводить видео в реальном времени с помощью directshow в DirectX8 или DirectX9, большинство обращений идет к видеодрайверам режима ядра. Я преуспел во многих синих экранах при запуске процедуры обратного вызова из источника видеозахвата в реальном времени, особенно если ваш обратный вызов занимает много времени, может остановить весь драйвер ядра.

Управляемый код может вызвать проверку ошибок, если у него есть доступ к неисправным драйверам ядра. Однако это будет драйвер ядра, который непосредственно вызывает BSOD (например, BSOD DirectShow uffe, BSOD сокета Теренса Льюиса или BSOD, наблюдаемые при использовании BitTorrent с определенными сетевыми адаптерами).

Прямой доступ в пользовательском режиме к привилегированным низкоуровневым ресурсам может вызвать ошибку (например, запись на Device\PhysicalMemory, если это не повредит ваш жесткий диск; Vista не разрешает доступ в пользовательском режиме к физической памяти).

Если вам просто нужен файл дампа, то предложение Мендельта по использованию WinDbg гораздо лучше, чем использование ошибки в драйвере ядра. К сожалению, команда .dump не поддерживается для локальной отладки ядра, поэтому вам потребуется второй ПК, подключенный через последовательный порт или 1394, или виртуальная машина, подключенная через виртуальный последовательный порт. LiveKd может быть вариантом для одного ПК, если вы необходимо, чтобы состояние дампа памяти было полностью самосогласованным.

Для этого не нужны никакие драйверы режима ядра, только SeDebugPrivilege. Вы можете сделать свой процесс критическим с помощью NtSetInformationProcess, или RtlSetProcessIsCritical и просто завершите свой процесс. Вы увидите тот же код проверки ошибок, что и при уничтожении csrss.exe, потому что вы установили тот же «критический» флаг для своего процесса.

К сожалению, я знаю, как это сделать, поскольку служба .NET на нашем сервере вызывала синий экран. (Примечание: Windows Server 2008 R2, а не XP/Vista).

Я с трудом мог поверить, что виновата программа .NET, но это было так. Кроме того, я только что воспроизвел BSOD на виртуальной машине.

Код нарушения вызывает ошибку 0x00000f4:

string name = string.Empty; // This is the cause of the problem, should check for IsNullOrWhiteSpace

foreach (Process process in Process.GetProcesses().Where(p => p.ProcessName.StartsWith(name, StringComparison.OrdinalIgnoreCase)))
{
    Check.Logging.Write("FindAndKillProcess THIS SHOULD BLUE SCREEN " + process.ProcessName);
    process.Kill();
    r = true;
}

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

РЕДАКТИРОВАТЬ: Уничтожение csrss.exe, по-видимому, вызывает синий экран. Согласно комментариям, это, вероятно, происходит в коде ядра.

Я обнаружил, что если вы запустите taskkill /F /IM svchost.exe от имени администратора, он попытается убить почти все хосты службы одновременно.