Invoquer un écran bleu de la mort à l'aide d'un code géré

Question

Juste curieux de savoir: est-il possible d’invoquer un écran bleu de la mort Windows à l’aide de code géré .net sous Windows XP / Vista? Et si cela est possible, quel pourrait être l'exemple de code?

Juste pour mémoire, ce n’est pas pour des fins malveillantes, je me demande simplement quel type de code il faudrait pour tuer réellement le système d’exploitation tel que spécifié.

Answer 1

Le clavier est probablement une bonne option, mais si vous devez le faire par code, continuez à lire ...

Vous n'avez vraiment besoin de rien, vous devez simplement trouver la fonction KeBugCheck (Ex) et l'invoquer.

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

Pour les collisions déclenchées manuellement, vous souhaitez utiliser 0xE2 (MANUALLY_INITIATED_CRASH) ou 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) comme code de contrôle de bogue. Ils sont explicitement réservés pour cet usage.

Cependant, trouver la fonction peut s’avérer un peu délicat. Le DDK Windows peut vous aider (vérifiez Ntddk.h). Je ne l’ai pas disponible pour le moment et je ne trouve pas les informations décisives pour le moment. Je pense qu’il se trouve dans ntoskrnl.exe. ou ntkrnlpa.exe, mais je ne suis pas sûr et ne dispose pas actuellement des outils pour le vérifier.

Il vous sera peut-être plus facile d'écrire une application C ++ simple ou quelque chose qui appelle la fonction, puis de l'exécuter.

Remarquez que je présume que Windows ne vous empêche pas d'accéder à la fonction à partir de l'espace utilisateur (.NET peut comporter des dispositions spéciales). Je ne l'ai pas testé moi-même.

Answer 2

Je ne sais pas si cela fonctionne vraiment et je suis sûr que vous avez besoin des droits d'administrateur, mais vous pouvez définir la clé de registre CrashOnCtrlScroll, puis utiliser un SendKeys pour envoyer CTRL + Verrouillage défilement + Verrouillage défilement.

Mais je crois que cela DOIT provenir du pilote de clavier, donc je suppose qu’un simple SendKeys n’est pas assez bon et que vous auriez besoin d’une manière ou d’une autre de connecter le pilote de clavier (semble vraiment désordonné) ou de vérifier que CrashDump a une API pouvant être appelée avec P / Invoke.

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

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Paramètres

Nom: CrashOnCtrlScroll
Type de données: REG_DWORD
Valeur: 1
Redémarrer

Answer 3

Je devrais dire non. Vous devez p / invoke et interagir avec un pilote ou un autre code résidant dans l’espace noyau. Le code .NET est très éloigné de ce domaine, bien que l’on ait parlé de pilotes gérés dans les futures versions de Windows. Attendez quelques années et vous pourrez vous évader, tout comme nos amis non gérés.

Answer 4

Pour autant que je sache, un vrai BSOD nécessite une défaillance du code en mode noyau. Vista a toujours des BSOD, mais ils sont moins fréquents car le nouveau modèle de pilote comporte moins de pilotes en mode noyau. Toute défaillance en mode utilisateur entraînera simplement la mort de votre application.

Vous ne pouvez pas exécuter de code managé en mode noyau. Donc, si vous voulez BSOD, vous devez utiliser PInvoke. Mais même c'est assez difficile. Vous devez faire des PInvokes vraiment fantaisistes pour obtenir quelque chose en mode noyau à utiliser.

Mais parmi les milliers d'utilisateurs de SO, il y a probablement quelqu'un qui a fait cela: -)

Answer 5

Vous pouvez utiliser l'outil OSR Online qui déclenche un crash du noyau. Je ne l'ai jamais essayé moi-même, mais j'imagine que vous pourriez l'exécuter via la classe de processus .net standard:

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

Answer 6

J'ai réussi une fois à générer un BSOD sous Windows XP en utilisant System.Net.Sockets dans .NET 1.1 de manière irresponsable. Je pourrais le répéter assez régulièrement, mais malheureusement, cela remonte à deux ans et je ne me souviens pas exactement comment je l’ai déclenchée, ni le code source n’est plus disponible.

Answer 7

Essayez l’aide vidéo en direct en utilisant directshow dans directx8 ou directx9, la plupart des appels étant dirigés vers des pilotes vidéo en mode noyau. J'ai réussi à utiliser de nombreux écrans bleus lors de l'exécution d'une procédure de rappel à partir d'une source de captation vidéo en direct, en particulier si votre rappel prend beaucoup de temps, peut arrêter l'ensemble du pilote du noyau.

Answer 8

Il est possible que le code managé provoque une vérification d'erreur lorsqu'il a accès aux pilotes de noyau défectueux. Cependant, ce serait le pilote du noyau qui engendrerait directement le BSOD (par exemple, les BSOD DirectShow d'uffe, les BSOD de socket de Terence Lewis ou les BSOD vus lors de l'utilisation de BitTorrent avec certaines cartes réseau).

L'accès direct en mode utilisateur aux ressources de bas niveau privilégiées peut provoquer une vérification d'erreur (par exemple, le gribouillage sur Device \ PhysicalMemory ), s'il n'endommage pas d'abord votre disque dur; Vista ne le fait pas permettre l'accès en mode utilisateur à la mémoire physique).

Si vous voulez juste un fichier de vidage, la suggestion de Mendelt d'utiliser WinDbg est une bien meilleure idée que d'exploiter un bogue dans un pilote du noyau. Malheureusement, la commande .dump n'est pas prise en charge pour le débogage du noyau local. Il vous faudrait donc un deuxième ordinateur connecté en série ou 1394, ou une machine virtuelle connectée via un port série virtuel. LiveKd peut être une option monoposte, si ce n'est pas le cas il faut que l'état de l'image mémoire soit complètement cohérent.

Answer 9

Celui-ci ne nécessite aucun pilote en mode noyau, seulement un SeDebugPrivilege. Vous pouvez définir votre processus critique en NtSetInformationProcess , ou RtlSetProcessIsCritical et tuez votre processus. Vous verrez le même code de vérification que lorsque vous supprimez csrss.exe, car vous définissez le même code "critique". drapeau sur votre processus.

Answer 10

Malheureusement, je sais comment procéder car un service .NET sur notre serveur provoquait un écran bleu. (Remarque: Windows Server 2008 R2, pas XP / Vista).

J'avais du mal à croire qu'un programme .NET était le coupable, mais c'était le cas. De plus, je viens de reproduire le BSOD sur une machine virtuelle.

Le code incriminé provoque un message 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;
}

Si quelqu'un se demande pourquoi je voudrais répliquer l'écran bleu, ce n'est pas malicieux. J'ai modifié notre classe de journalisation pour prendre un argument en lui disant de écrire directement sur le disque car les actions antérieures au BSOD n’apparaissaient pas dans le journal malgré l’appel de .Flush (). J'ai répliqué le crash du serveur pour tester le changement de journalisation. La machine virtuelle est effectivement tombée en panne, mais la journalisation a fonctionné.

EDIT: Tuer csrss.exe semble être la cause de l'écran bleu. Selon les commentaires, cela se produit probablement dans le code du noyau.