9
votes

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

J'ai un client qui m'a dit que mon programme (programme d'utilisateurs simple, non conducteur) bloque son système avec un écran bleu bleu de décès (BSOD). Il dit qu'il n'a jamais rencontré cela avec un autre programme et qu'il pouvait la reproduire facilement avec le mien.

Le BSOD est de type critical_Object_Termination ( 0x000000f4 ) avec type d'objet 0x3 (processus): un processus ou un thread crucial pour le fonctionnement du système est excitée ou a été terminé de manière inattendue. < / p>

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


6 commentaires

Dans quelle langue est-elle écrite?


C'est un programme C ++ utilisant WxWidgets Toolkit.


@Math: pourrait un bug dans WxWidgets qui donne des problèmes à la Win API.


Consultez ceci (à partir de 2005): Symantec.com/security_Response/vulnerability.jsp? Enchère = 13121


Juste hors de curiosité, pourriez-vous reproduire (et résoudre) le problème à l'aide du dépotoir de crash?


@Divo: Pas pour le moment, je n'en ai pas. J'ai choisi votre réponse en raison de la possibilité qu'un utilisateur disposant de privilèges d'administration puisse tuer (par inadvertance ou non) un processus critique qui puisse alors déclencher un BSOD. Je ne sais pas si c'est mon cas mais ça vaut la peine de noter.


8 Réponses :


10
votes

Juste parce que votre programme n'est pas un pilote ne signifie pas que ce ne sera pas utiliser un pilote.

En théorie, votre code ne devrait pas être capable de bsod l'ordinateur. Il appartient au système d'exploitation 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 aussi un bogue dans votre code.


2 commentaires

"En théorie"? Peut-être trop fort un mot lorsque vous décrivez Windows. Je ne pense pas qu'il y ait une vraie science qui postule de théories sur Windows. Je pense que cela est plus d'espoir que Microsoft Harbors. Je pense que le bon mot pourrait être "espoir".


S.Lott: Je suppose que ce qu'il voulait dire qu'en mode protégé X86, la bague 3 ne devrait pas être capable de démonter la bague 0. Cela n'a rien à voir avec Windows.



4
votes

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


0 commentaires

3
votes

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

C'est pourquoi nous testons sur différentes machines, systèmes d'exploitation, matériel, etc.

Avez-vous défini certaines exigences pour votre programme et votre utilisateur les suivit-il?


0 commentaires

4
votes

Normalement, cela ne devrait pas. Si c'est le cas, il doit y avoir soit

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

    Je parierais sur l'option numéro deux (pilote de périphérique), mais il serait intéressant de pouvoir nous procurer un dépotoir plus détaillé.


4 commentaires

+1: un bug dans Windows? Vraiment? Qui aurait pensé à ça?


@ S.Lott: Étonnamment et malgré toutes ces blagues de Windows, mais les rares BSOD que j'ai vus depuis que Windows XP pourraient tous être traçés vers des produits tiers ou des défauts matériels.


@Divo: bon point. Cependant, lorsqu'un produit tiers peut planter des fenêtres, je soupçonne qu'il y a toujours un bogue quelque part en dehors de la composante tierce.


@ S.Lott: Cela ne serait vrai que si Windows ne permettait aucun composant tiers d'exécuter en mode noyau. Exécution des pilotes de périphérique en mode utilisateur est possible et plus stable, mais cela ne vient pas gratuitement - généralement l'impact de la performance pour tous les transitions de mode utilisateur / noyau serait trop élevé.



6
votes

Le moyen le plus simple de provoquer un programme BSOD avec un programme d'utilisation de l'utilisateur est (AFaik) à tuer Le processus de sous-système Windows (CSRSS.EXE). Cela n'a pas besoin de matériel défectueux ni d'un bogue dans le noyau ou un pilote, il n'a besoin que de privilèges d'administrateur 1 . .

Quel est votre code exactement? Le message d'erreur ("Un processus ou un fil-threads crucial pour le fonctionnement du système a été excité de manière inattendue ou terminée.") Cela ressemble à celui des processus système essentiels terminés. Peut-être que vous tuez un processus et obtenez involontairement le mauvais processus?

Si possible, vous pouvez essayer d'obtenir une mémoire de mémoire de ce client. Utilisation des outils de débogage pour Windows Vous pouvez ensuite analyser davantage que la décharge comme décrit ici .

1 Windows ne vous empêche pas de Ce faisant parce qu'il " administrateurs en contrôle de leur ordinateur ". Donc, c'est par conception et pas un bug. Lisez les articles de Raymond et vous verrez pourquoi.


0 commentaires

1
votes

Si vous ne pouvez pas le dupliquer vous-même, et votre programme n'a pas besoin d'admin pour exécuter, je serais un peu soupdicat de

  • la stabilité du matériel de ce système
  • l'état des virus / logiciels malveillants de ce système.

    Si vous pouvez obtenir un accès physique à la zone client, il peut être utile d'exécuter une analyse du virus complet avec un scanner à jour et d'exécuter une MEMTEST dessus.

    J'ai eu un système une fois que cela semblait stable, sauf que certains programmes certian ne s'exécuteraient pas (et seraient parfois en train de planter la boîte). MEMTEST a montré que mon bélier a eu quelques mauvais morceaux, mais ils étaient à Higer Sims, ils n'ont donc eu accès que si un programme a essayé d'utiliser beaucoup de RAM.


1 commentaires

Oui, il peut s'agir d'une défaillance matérielle.



1
votes

Non, et c'est à peu près par définition. La pire chose à laquelle vous puissiez dire est qu'une application utilisateur-terre peut avoir "déclenché" un bogue Windows ou un bug de pilote. Mais un système d'exploitation moderne de bureau 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 d'un bogue BSOD que votre application à elle seule pourrait exposer: un scanner de virus 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 )


2 commentaires

Je ne dirais pas que seul le système d'exploitation est responsable. Certes, le système d'exploitation devrait être inscru à une application non privilégiée, mais nous devons faire face à des systèmes d'exploitation réels.


Les bugs du système d'exploitation sont un fait indiscutable, mais que l'observation n'enlève rien de la responsabilité.



0
votes

J'ai eu des problèmes lors de la sortie de mon application sans empêcher tous les processus et les connexions BD lorsque le programme se termine (j'ai écrasé toute l'IDE). Je place le code "Arrêt et déconnectant" dans la "Terminate" de "Form_Close" de ma forme principale et du problème résolu, je ne le 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 utilise lorsque le BSOD arrive.

Un virus ne peut pas être jeté.


1 commentaires

Funny Comment une réponse peut collecter un vote négatif huit ans plus tard (j'étais si jeune à l'époque!)