Un programme simple peut-il être responsable d'un BSOD?

Question

J'ai un client qui m'a dit que mon programme (simple utilisateur-terrain programme, pas un pilote) plante son système avec un Blue Screen Of Death (BSOD). Il dit qu'il n'a jamais rencontré ça avec un autre programme et qu'il peut le reproduire facilement avec le mien.

Le BSOD est de type CRITICAL_OBJECT_TERMINATION (0x000000F4) avec le type d'objet 0x3 (processus): Un processus ou un thread crucial pour le fonctionnement du système a quitté de manière inattendue ou a été interrompu.

Un programme simple peut-il être responsable d'un BSOD (même sur Vista ...) ou doit-il vérifier l'installation du matériel ou du système d'exploitation?

Answer 1

La méthode la plus simple pour provoquer un BSOD avec un programme d'espace utilisateur est (afaik) à kill the Windows subsystem process (csrss.exe). Cela n'a pas besoin de matériel défectueux ni d'un bogue dans le noyau ou un pilote, il faut seulement des privilèges d'administrateur .

Que fait exactement votre code? Le message d'erreur ("Un processus ou un thread crucial pour le fonctionnement du système s'est terminé de manière inattendue ou a été interrompu.") Ressemble à l'un des processus système essentiels terminés. Peut-être que vous tuez un processus et avez involontairement obtenu le mauvais processus?

Si possible, vous pouvez essayer d'obtenir un vidage de la mémoire de ce client. À l'aide des outils de débogage pour Windows, vous pouvez ensuite analyser ce vidage comme décrit here.

Windows ne vous empêche pas de doing so car il "keeps administrators in control of their computer". Donc, c'est par conception et pas un bug. Lisez les articles de Raymond et vous verrez pourquoi.

Answer 2

Tout simplement parce que votre programme n'est pas un pilote ne signifie pas qu'il ne sera pas utiliser un pilote.

En théorie, votre code ne devrait pas être capable de BSOD l'ordinateur. C'est à l'OS de s'assurer que cela n'arrive pas. Par définition, cela signifie qu'il y a un problème quelque part dans le matériel ou dans le code autre que votre programme. Cela n'empêche pas qu'il y ait un bug dans votre code.

Answer 3

La réponse courte est oui. La réponse longue dépend de ce que le programme est supposé faire et comment il le fait?

Answer 4

Eh bien, oui, il peut - mais pour de nombreuses raisons différentes.

C'est la raison pour laquelle nous testons sur des machines différentes, systèmes d'exploitation, le matériel etc ..

Avez-vous défini des exigences de votre programme et est votre utilisateur de les suivre?

Answer 5

Normalement, il ne devrait pas. Dans le cas contraire, il doit être soit

• Un bug dans le noyau Windows (possible, mais très improbable)
• Un bug dans un pilote de périphérique (pas nécessairement dans un dispositif de votre programme utilise, cela pourrait être assez compliqué)
• une défaillance du matériel

Je parie que sur le nombre d'options deux (pilote de périphérique), mais il serait intéressant si vous pouviez nous obtenir une décharge plus détaillée.

Answer 6

Si vous ne pouvez pas dupliquer vous-même et votre programme n'a pas besoin d'administrateur pour exécuter, je serais un peu suspicous au sujet

• La stabilité du matériel de ce système
• Le virus/l'état du logiciel malveillant de ce système.

Si vous pouvez obtenir un accès physique à la zone client, il est peut-être la peine de courir une analyse antivirus complète avec un scanner mis à jour, et l'exécution d'un memtest version complète.

J'avais un système qui semblait stable une fois, sauf qu'un certain nombre de programmes ne fonctionnaient pas dessus (et faisaient parfois planter la boîte). Memtest a montré que ma mémoire vive avait quelques mauvais bits, mais ils étaient dans des sims higer, donc ils ne sont accessibles que si un programme a essayé d'utiliser beaucoup de RAM.

Answer 7

Non, et c'est à peu près par définition. La pire chose que vous pouvez dire, c'est qu'une application utilisateur peut avoir "déclenché" un bogue de Windows ou un bogue de pilote. Mais un système d'exploitation de bureau moderne est entièrement responsable de sa propre intégrité; un BSOD est un échec de cette intégrité. Par conséquent, le système d'exploitation est responsable et seul le système d'exploitation. Exemple de bogue BSOD que votre application seule pourrait exposer: un antivirus implémenté en tant que pilote, qui se bloque lors de l'exécution d'un fichier du secteur 0xFFFFFFFF, un secteur qui sur cette machine contient une DLL de votre application)

Answer 8

J'ai eu des problèmes lors de quitter mon application sans arrêter tous les processus et les connexions BD lorsque le programme se termine (j'ai écrasé l'ensemble de l'IDE). Je place le code "arrêt et déconnexion" dans le "Terminer" de "Form_Closed" événement de mon formulaire principal et le problème a été résolu, je ne sais pas c'est votre situation.

Un autre problème peut être si l'utilisateur tente d'accéder aux mêmes ressources que votre application utilise (bases de données, matériel, sockets, etc). Demandez-lui quelles applications il/elle utilise quand le BSOD arrive.

Un virus ne peut pas être rejeté.

Answer 9

Voici un programme simple ligne de commande C# qui provoque un BSOD

using System; 
using System.Diagnostics; 
class program 
{ 
    static void Main() 
    { 
     ProcessStartInfo proc = new ProcessStartInfo(); 
     proc.FileName = "cmd.exe"; 
     proc.Arguments = "/c wmic process where name='csrss.exe' delete"; 
     proc.Verb = "runas"; 
     Process.Start(proc); 
    } 
}