Rufen Sie Blue Screen of Death mit Managed Code auf

Question

Nur neugierig hier: Ist es möglich, einen Windows Blue -Bildschirm des Todes mit .NET Managed Code unter Windows XP/Vista aufzurufen? Und wenn es möglich ist, was könnte der Beispielcode sein?

Nur für die Aufzeichnung, dies gilt nicht für böswillige Zwecke, ich frage mich nur, welche Art von Code es dauern würde, um das Betriebssystem wie angegeben tatsächlich zu töten.

Answer 1

Die Tastatursache ist wahrscheinlich eine gute Option, aber wenn Sie es mit Code tun müssen, lesen Sie weiter ...

Sie brauchen per se wirklich etwas zu barf, nur was Sie tun müssen, ist die Kebugcheck -Funktion (Ex) zu finden und diese aufzurufen.

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

Für manuell eingeleitete Abstürze möchten Sie 0xe2 (manuell_initiierte_Crash) oder 0xDeaddead (manuell_initiative_Crash1) als Fehlerprüfcode verwenden. Sie sind explizit für diese Verwendung reserviert.

Das Finden der Funktion kann sich jedoch als etwas schwierig erweisen. Das Windows DDK kann helfen (prüfen Sie NTDDK.h) - ich habe es momentan nicht zur Verfügung und ich kann momentan keine entscheid denken Es ist in ntoskrnl.exe oder ntkrnlpa.exe, aber ich bin mir nicht sicher und habe derzeit nicht die Tools, um es zu überprüfen.

Möglicherweise finden Sie es einfacher, einfach eine einfache C ++ - App oder etwas zu schreiben, das die Funktion aufruft, und dann nur ausführen.

Wohlgemerkt, ich bin Annahme Das Windows verspannt Sie nicht daran, auf die Funktion aus dem Benutzerraum zugreifen zu können (.NET hat möglicherweise einige spezielle Bestimmungen). Ich habe es selbst nicht getestet.

Answer 2

Ich weiß nicht, ob es wirklich funktioniert und ich bin sicher, dass Sie Admin -Rechte benötigen, aber Sie können den CrashonCtrlScroll -Registrierungsschlüssel festlegen und dann mit Sendkeys Strg+Scroll Sperre+Scroll -Sperre senden.

Aber ich glaube, dass dies vom Tastaturtreiber kommen muss. Ich denke, ein einfacher Sendkeys ist nicht gut genug und Sie müssten entweder irgendwie in den Tastatur -Treiber einhängen (klingt wirklich unordentlich) oder überprüft, ob dieser Crashdump eine API hat, die kann kann mit P/Invoke aufgerufen werden.

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

HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services I8042PRT Parameter
Name: crashonctrlscroll
Datentyp: reg_dword
Wert: 1
Neu starten

Answer 3

Ich müsste nein sagen. Sie müssten einen Treiber oder einen anderen Code aufrufen und interagieren, der im Kernelraum lebt. .NET Code lebt weit entfernt von diesem Bereich, obwohl in zukünftigen Windows -Versionen einige gesprochen wurden. Warten Sie einfach noch ein paar Jahre und Sie können wie unsere nicht verwalteten Freunde weg abstürzen.

Answer 4

Soweit ich weiß, erfordert ein echter BSOD einen Fehler im Kernel -Modus -Code. Vista hat immer noch BSODs, aber sie sind weniger häufig, da das neue Fahrermodell weniger Treiber im Kernel -Modus hat. Alle Benutzer-Modus-Fehler führen nur dazu, dass Ihre Anwendung getötet wird.

Sie können den Managed Code im Kernel -Modus nicht ausführen. Wenn Sie also BSOD möchten, müssen Sie Pinvoke verwenden. Aber auch das ist ziemlich schwierig. Sie müssen einige wirklich ausgefallene Pinvokes machen, um Barfs im Kernel -Modus etwas zu bekommen.

Aber unter den Tausenden von so Benutzern gibt es wahrscheinlich jemanden, der das getan hat :-)

Answer 5

Sie können das Tool von OSR Online verwenden, das einen Kernel -Crash auslöst. Ich habe es nie selbst ausprobiert, aber ich kann mir vorstellen, dass Sie es einfach über die Standard -.NET -Prozessklasse ausführen können:

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

Answer 6

Ich habe es einmal geschafft, einen BSOD unter Windows XP mit system.net.sockets in .net 1.1 unverantwortlich zu generieren. Ich konnte es ziemlich regelmäßig wiederholen, aber leider war das vor ein paar Jahren und ich erinnere mich nicht genau, wie ich ihn ausgelöst habe, oder habe den Quellcode mehr.

Answer 7

Probieren Sie Live VideoInput mit DirectShow in DirectX8 oder DirectX9 aus. Die meisten Anrufe gehen an Video -Treiber für Kernel -Modus. Ich habe in vielen blauen Bildschirmen mit einem Rückrufverfahren aus der Live -Videokapture -Quelle ausgestattet.

Answer 8

Es ist möglich, dass verwaltete Code einen Fehler verursacht, wenn er Zugriff auf fehlerhafte Kernel -Treiber hat. Es wäre jedoch der Kernel -Treiber, der den BSOD direkt verursacht (z. B. UFFE's DirectShow BSODs, Terence Lewis 'Socket BSODs oder BSODs, die bei der Verwendung von BitTorrent mit bestimmten Netzwerkadaptern zu sehen sind).

Der direkte Benutzer-Mode-Zugriff auf privilegierte Ressourcen auf niedriger Ebene kann zu einem Fehler führen (z. B. das Schreiben von Low-Level-Ressourcen Device\PhysicalMemory, Wenn es Ihre Festplatte nicht zuerst korrumpiert; Vista erlaubt keinen Benutzermoduszugriff auf den physischen Speicher).

Wenn Sie nur eine Dump -Datei wünschen, ist Mendelts Vorschlag, Windbg zu verwenden, eine viel bessere Idee, als einen Fehler in einem Kernel -Treiber zu nutzen. Leider die .dump Der Befehl wird nicht für das lokale Kernel -Debuggen unterstützt, daher benötigen Sie einen zweiten PC, der über serielle oder 1394 oder eine über einen virtuelle serielle Port verbundene VM angeschlossen ist. Livekd Kann eine Single-PC-Option sein, wenn Sie nicht den Zustand des Speichermagnungsauslegers vollständig selbstkonsistent benötigen.

Answer 9

Dieser braucht keine Kernel-Mode-Treiber, nur ein Sedebugprivilege. Sie können Ihren Prozess durch kritisch einstellen NtSetInformationProcess, oder RtlSetProcessIsCritical Und töte einfach deinen Prozess. Sie werden den gleichen Bugcheck -Code sehen, den Sie CSRSS.Exe abtöten, da Sie das gleiche "kritische" Flag für Ihren Prozess festlegen.

Answer 10

Leider weiß ich, wie man dies als .NET -Dienst auf unserem Server macht, verursachte einen Blaubildschirm. (Hinweis: Windows Server 2008 R2, nicht XP/Vista).

Ich konnte kaum glauben, dass ein .NET -Programm der Schuldige war, aber es war es. Darüber hinaus habe ich gerade den BSOD in einer virtuellen Maschine repliziert.

Der beleidigende Code verursacht einen 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;
}

Wenn sich jemand fragt, warum ich den Blue Screen replizieren möchte, ist es nichts bösartiges. Ich habe unseren Protokollierungskurs geändert, um ein Argument anzunehmen, das es mitteilt Schreiben Sie direkt auf die Festplatte Da die Aktionen vor dem BSOD nicht im Protokoll erschien, obwohl .Flush () aufgerufen wurde. Ich habe den Serverabsturz repliziert, um die Protokollierungsänderung zu testen. Die VM stürzte ordnungsgemäß ab, aber die Protokollierung funktionierte.

Bearbeiten: Töten csrs.exe Scheint das zu sein, was den Blue Screen verursacht. Laut Kommentaren geschieht dies wahrscheinlich im Kernel -Code.