Comment puis-je provoquer un blocage de Windows?
Je dois tester le comportement du matériel dans le cas où Windows hard se bloque/se bloque (par exemple, un écran gelé, aucun voyant clignotant, aucune réaction aux entrées, y compris Ctrl + Alt + Suppr , etc. ). Afin d’avoir suffisamment d’expériences dans un temps relativement court, je dois initier ces suspensions soit par programme, soit autrement.
Je suis intéressé par Windows 10 en particulier, mais tout moyen de travail pour les autres versions est apprécié.
Chacune des recherches que j'ai effectuées sur ce sujet m'amène naturellement à des discussions sur la manière de éliminer ces situations et non de les provoquer. Donc, la question peut sembler assez étrange.
Commentaires: J'ai essayé plusieurs des recettes proposées dans les réponses et les commentaires. Tout d’abord, les collisions impliquant BSoD ne m’intéressaient pas (c’est pourquoi j’ai décrit un gel, pas un crash).
Je dois avouer que Windows 10 64 bits a bien résisté à de nombreux problèmes. Il se débrouille assez bien avec presque toutes les méthodes charge du processeur (y compris fork-bomb , boucles, etc.). Les méthodes qui génèrent des erreurs immédiates (la plupart des méthodes de blocage de NotMyFault) sont gérées par le système d'exploitation avec redémarrage ou arrêt (ce qui n'est pas ce que j'ai poursuivi). Les meilleurs résultats ont été obtenus par fuite de mémoire méthodes de NotMyFault - blocage réel sans possibilité de redémarrage.
Enfin, j'ai été impressionné par la quantité de documentation fournie par Microsoft sur le blocage de Windows. On dirait qu'ils connaissent cette partie beaucoup mieux que l'inverse (la lutte se fige) ;-)
Peut-être que cela peut aider: Forcer un crash système depuis le clavier
Avec les claviers USB, vous devez activer le blocage provoqué par le clavier dans le registre. Dans la clé de registre HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\kbdhid\Parameters, créez une valeur nommée CrashOnCtrlScroll et définissez-la sur une valeur REG_DWORD égale à 0x01.
Vous devez redémarrer le système pour que ces paramètres prennent effet.
Une fois cette opération terminée, le clavier peut être bloqué à l'aide de la séquence de touches suivante: Maintenez la touche CTRL la plus à droite enfoncée et appuyez deux fois sur la touche SCROLL LOCK.
Ou vous pouvez lancer une bombe à la fourchette: voir cette SO question
Il y a aussi NotMyFault
Notmyfault est un outil que vous pouvez utiliser pour planter, bloquer et causer des fuites de mémoire du noyau sur votre système Windows. C’est utile pour apprendre à identifier et à diagnostiquer les problèmes matériels des pilotes de périphériques et matériels, et vous pouvez également vous en servir pour générer des fichiers de vidage d’écran bleu sur des systèmes défectueux.
On dirait que vous testez la réaction d’un périphérique externe face à un système d’exploitation qui ne répond plus.
Si votre matériel peut être connecté à une installation Windows virtualisée, vous pouvez suspendre et reprendre la machine virtuelle autant de fois que vous le souhaitez. Installez le système d'exploitation souhaité dans un environnement VirtualBox (ou autre virtualisation de postes de travail), exposez toute interface matérielle utilisée (USB, Ethernet ou autre) à la machine virtuelle.
Vous pouvez ensuite mettre en pause et reprendre la machine virtuelle à volonté.
Au moins sous une ancienne version de Windows (il y a quelques années), les éléments suivants ont fonctionné:
J'ai écrit un programme C avec une boucle sans fin:
while(1) {}
... puis j'ai donné à ce programme la "priorité temps réel" dans le gestionnaire de tâches (il existe également une API qui peut le faire).
Sur un système multicœur, je devrais le faire plusieurs fois pour qu'une boucle s'exécute sur chaque cœur ...
Le blocage le plus puissant du noyau (c'est-à-dire, aucun suivi de la souris, etc.) survient lorsque le code passe dans une boucle infinie en mode noyau avec des interruptions désactivées.
Il est possible d'y parvenir avec un pilote de périphérique et, mieux encore, d'écrire le pilote de sorte qu'il démarre et arrête le blocage sous votre contrôle (en supposant que la boucle infinie teste la condition dont vous êtes le contrôle).
Comment écrire et installer ce pilote serait le sujet d'une autre question ou trois, mais c'est l'approche que je choisirais.
Veuillez vérifier la question suivante sur StackOverflow qui est similaire à la vôtre: Comment faire geler les fenêtres pendant une courte période
Le problème, c’est qu’il n’ya aucun moyen de le faire (de manière fiable).
Plutôt que de figer ou de bloquer Windows, vous pouvez peut-être simplement interrompre la communication avec votre équipement.
Je ne sais pas du tout quel est votre équipement et comment vous le connectez. S'il s'agit d'un adaptateur USB ou Ethernet, par exemple, vous pouvez facilement le désactiver dans le Gestionnaire de périphériques ou le débrancher? Si vous bloquez ou suspendez le système avec force, vous risquez de l'endommager de différentes manières. Soyez donc prudent avec ce que vous faites.
Le mode de débogage du noyau n'est-il pas une option?
Je l'ai configuré dans Windows 7 et les instructions liées dans cette réponse spécifient XP ou une version ultérieure, de sorte que cela devrait fonctionner avec Windows 10.
Je l'ai installé sur FireWire/1394 , car c'est le plus facile, à mon avis. Mais vous pouvez aussi le faire sur le réseau ou USB (et plus ).
Fondamentalement,
Configurez l’ordinateur cible en exécutant ces commandes dans une invite élevée (sélection d’un canal n):
bcdedit /debug on
bcdedit /dbgsettings 1394 channel:n
Ce qui revient à accéder à l'onglet de démarrage de msconfig et à sélectionner le bouton 'Avancé':
Ensuite (après le redémarrage de l'ordinateur cible), exécutez WinDbg sur l'ordinateur hôte en utilisant le même nombre de bits que WinDbg de l'ordinateur cible.
Ensuite, il vous suffit de suspendre l'exécution du noyau à tout moment à partir de l'ordinateur hôte. Si votre équipement de test exécute une opération asynchrone, cela devrait être aussi efficace que d'autres moyens.
Je ne sais pas s'il s'agit d'un gel total, car le curseur de la souris se déplace toujours à l'écran, mais l'interface utilisateur de Windows 7 ne répond plus si vous rencontrez des erreurs d'E/S de périphérique, plus précisément une panne de disque dur. L'un de mes disques durs était l'auto-signale une panne imminente de disque via SMART et Windows 7 le montait mais se bloquait à chaque fois que j'essayais d'accéder à certains fichiers sauvegardés. L'interface utilisateur se verrouille (sauf pour le mouvement du curseur de la souris) pendant 5 minutes au maximum, jusqu'à ce qu'elle soit capable de lire le fichier ou de démonter le lecteur après le délai. Je ne sais pas si Windows utilise l'horloge système pour le délai d'expiration, mais peut-être que si vous bloquez le temps, vous pouvez prolonger la durée du délai d'expiration? Peut-être que cela vous mènera à mi-chemin, mais pas à 100% la réponse que vous cherchez.
Voici le code source d'une application que j'utilise dans mes cours de débogage. Il montre comment une application en mode utilisateur peut effectuer une sorte d'attaque DoS.
Vous remarquerez que le curseur de votre souris se déplace très rarement (une fois toutes les onze secondes sur ma machine). Potentiellement, votre PC réagira quand même sur le bouton d'alimentation si vous attendez assez longtemps.
Cela fonctionne en utilisant une boucle sans fin et en définissant la priorité la plus élevée pour le processus (0x100 "en temps réel") et en définissant la priorité la plus élevée pour les threads (15 "critique de temps"). Il en démarrera 8, ce qui suffit pour les ordinateurs i7. Si vous avez besoin de plus, adaptez la boucle. Plus d’entre eux pourraient potentiellement ralentir davantage les choses.
#include "stdafx.h"
#include <windows.h>
#include <string>
#include <sstream>
#include <iostream>
void WasteTime()
{
int priority = 15;
::SetThreadPriority(::GetCurrentThread(), priority);
while (true)
{
}
}
int _tmain(int argc, _TCHAR* argv[])
{
::SetPriorityClass(::GetCurrentProcess(), 0x100);
for(int i=0; i<7; i++)
{
LPDWORD threadid = 0;
::CreateThread(NULL, 64*1024, (LPTHREAD_START_ROUTINE)&WasteTime, NULL, 0, threadid);
::Sleep(2000);
}
WasteTime();
return 0;
}
Ce bogue bloque Windows assez rapidement en raison de l'épuisement des ressources. Facile à reproduire aussi.
Il s’avère qu’il s’agit d’un bug dans la manière dont la ligne de commande (plus précisément
cmd.exe) analyse les fichiers de traitement par lots et pourrait conduire à une attaque rapide de type déni de service; mettre la ligne suivante dans un fichier de commandes (sans nouvelles lignes) consomme très rapidement une quantité de mémoire considérable en raison de ce bogue (à titre d'exemple):^ nul<^En résumé, lorsqu'un signe d'insertion se trouve à la fin du fichier, la fin réelle du fichier est "ignorée" et le descripteur de fichier "réinitialisé" à 0 (essentiellement) afin que le lot soit à nouveau analysé (à l'infini).
Avez-vous essayé le CPUEater utility fourni avec Process Lasso? _ {Ps. Je ne travaille pas pour le bitum.} _