mon programme .net provoque un BSOD

Question

Je reçois un écran bleu lorsque mon application Windows winform est exécutée. Il semble que seul un utilisateur l'obtienne. Je ne sais pas où chercher le problème en ce moment. J'utilise cependant du code que j'ai trouvé sur CodeProject pour piéger les événements souris et les événements clavier http://www.codeproject.com/KB/cs/globalhook.aspx cela pourrait-il être cela?

Je cherche des suggestions sur la façon dont je pourrais piéger cette erreur. Cela ne se passe que sur un ordinateur utilisateur sur 40, donc je suis un peu perplexe - d'autant plus que cet utilisateur est le principal acteur.

Mise à jour: Nous avons un incident de plus - le dénominateur commun est le port d'accueil. L'utilisateur utilisait le même port d'accueil.

Answer 1

Il est impossible que votre code soit provoquant un BSOD. Si vous n'êtes pas en mode noyau, alors un BSOD n'est pas votre faute (si vous excusez le jeu de mots).

OTOH, J'ai vu le code managé déclencher un bug dans un morceau de code en mode noyau. Ce bug a ensuite causé un BSOD. Dans mon cas, le code en mode noyau faisait partie d'un logiciel VPN qui voulait comprendre le code que vous utilisiez afin de décider si vous pouviez ou non accéder au VPN. Le code utilisait des hooks en mode noyau pour ce faire, et ils avaient un bug qui était déclenché par le chargement d'un grand nombre d'assemblages.

Apparemment, ils n'avaient jamais testé leur code pendant l'exécution de Visual Studio. Il charge les compléments et autres à l'exécution, ce qui a déclenché leur bug. Un morceau de code C# qui chargeait simplement un grand nombre d'assemblys dans un AppDomain (puis déchargeait AppDomain et recommençait) a également déclenché leur bogue, ce n'était donc pas un problème de Visual Studio. La morale de l'histoire est que quelqu'un doit regarder le vidage sur incident et déterminer quel logiciel en mode noyau a causé le crash, alors peut-être que vous pouvez comprendre ce qui se passait dans le système pour déclencher le noyau. -mode logiciel à planter.

Answer 2

Le problème ne va pas être votre application directement, mais un problème avec son système, alors que roufamatic dit que check est un journal d'événements. Cependant, il y a deux erreurs matérielles courantes qui ont tendance à causer ce genre de problème et vous pourriez les vérifier pour voir si elles vous donneront l'exemple.

1. Mauvaise mémoire. Si une erreur de mémoire s'est développée, il n'est pas inhabituel de voir un programme particulier qui peut 'provoquer' l'accès à la mémoire défectueuse et ainsi conduire à un BSOD. Si, par exemple, il exécute généralement des applications relativement légères, il est possible que l'erreur de mémoire soit dans un emplacement qui n'est normalement pas utilisé. Lorsque vous chargez votre application, en particulier si son empreinte mémoire est importante et que vous appelez de nombreuses dépendances, vous risquez de déclencher le blocage indirectement. Alors lancez une vérification complète sur la RAM de la machine.

2. Pilotes d'imprimante. C'était un problème plus important que maintenant, mais si vous utilisez XP, il apparaît quand même occasionnellement. Les pilotes d'imprimantes sont notoirement mal écrits et assez souvent buggés. Il n'est pas rare qu'une application appelle un pilote d'imprimante qui, à son tour, plante le système. Pour vérifier cela, supprimez simplement les pilotes d'imprimante, puis rechargez-les par la suite.

EDIT: Comme indiqué dans les commentaires, tout mauvais matériel ou mauvais pilotes peuvent provoquer ce genre de comportement. Je souligne simplement la mémoire et les pilotes d'imprimantes, car l'expérience montre que ces deux sont de loin les causes les plus courantes et méritent d'être considérées en premier.

Answer 3

J'ai déjà dû résoudre ce problème. J'écrivais du code C# en mode utilisateur pour parler à un périphérique HID sur le bus USB. Ce problème s'est produit sur mon ordinateur portable mais sur la machine de personne d'autre. Il s'est avéré que cela causait des problèmes parce que je courais un système d'exploitation 64 bits et, par conséquent, avait des pilotes 64 bits. Tous les autres utilisateurs avaient des pilotes 32 bits, ce qui ne posait pas de problème. C'était un ensemble d'utilisateurs modérément contrôlés. Je connaissais chaque utilisateur et ils étaient des utilisateurs compétents qui pouvaient me donner des informations sur leur matériel, leur système d'exploitation et leurs pilotes. Nous utilisions tous le même appareil.

Je ne me souviens pas comment j'ai DÉTERMINÉ le problème. Mais je l'ai résolu tout simplement en définissant le projet d'application pour cibler uniquement Windows 32 bits. Sans une application 64 bits, le pilote défectueux n'est jamais utilisé. Demandez aux utilisateurs de mettre à jour leurs pilotes, leur matériel ou de modifier le code pour éviter d'utiliser le pilote en entier.