Comment aborder le débogage d'une AccessViolationException dans une application .Net sur XP

Question

J'ai une application .net que j'ai développé sur une machine Windows 8.1 en utilisant Visual Studio 2008 Express compilé pour .NET 4.0

Il fonctionne bien sur Windows 8.1 machine, mais sur une (très) ancienne machine à un noyau XP, elle lance occasionnellement une exception AccessViolationException, et je n'arrive pas à comprendre pourquoi.

En cours d'exécution dans Visual Studio en mode débogage, je n'ai rien d'utile.

Le programme est très parallèle et j'utilise le TPL.

Le journal des événements montre ce (qui ne veut rien dire pour moi):

Stack: 
    at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef) 
    at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, 
Int32, Int32) 
    at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext) 
    at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, 
System.Windows.Forms.ApplicationContext) 
    at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun() 
    at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel() 
    at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(System.String[]) 

Les seules bibliothèques en dehors des choses standards .net J'utilise sont System.data.SQLite et Newtonsoft.JSON

L'application utilise le JSON pour accéder à une API RPC-Post.

Des idées quel morceau de mon code pourrait causer cela? Comme je le dis, ça n'arrive que sur la vieille machine XP, mais ça pourrait être une condition de course que je ne vois que parce que c'est beaucoup plus lent. Je ne sais même pas par où commencer!

Answer 1

Je vais noodler à propos de ce problème un peu, il est assez important de réaliser que vous ne pouvez pas obtenir une réponse avec les informations que vous avez posté. Je ne peux parler que de ce que vous devez faire pour découvrir plus d'informations sur ce crash.

Le détail le plus important est que l'incident et s'est produit dans la méthode DispatchMessageW(). Il y a un grand nombre de cadres de pile au-dessus de la trace que vous avez affichée, mais vous ne pouvez pas les voir. Comme ils appartiennent à du code non géré, le CLR enregistre uniquement les informations de trace pour le code managé. DispatchMessage() est une fonction Winapi de travail-cheval qui fait beaucoup de choses différentes dans différents cas, son travail principal est d'appeler la procédure de fenêtre d'une fenêtre. Quel est le code qui gère un message spécifique pour la fenêtre. Ce qui est clair à partir de la trace est que le crash n'a pas été causé par un code .NET. Ce qui est attendu, .NET est très bon pour éviter AccessViolationExceptions. Il y a quelques contrôles que vous pourriez utiliser sur votre formulaire qui pourrait être responsable. Au sommet de cette liste se trouvent les contrôles ActiveX, WebBrowser, les boîtes de dialogue shell comme OpenFileDialog. Tous les contrôles implémentés dans du code natif et dotés d'un wrapper .NET très fin pour les rendre utilisables dans un projet .NET. Ils sont normalement assez bien comporté. Mais alors c'est une vieille machine qui a été soumise à qui-sait-quoi, de telles machines ont tendance à être très mal infectées avec toutes sortes de logiciels "utiles" qui s'injectent dans n'importe quel processus et n'ont probablement pas été entretenus depuis longtemps. temps.

Vous mentionnez «très parallèle», qui tend à être un drapeau rouge. Pas de signal fort, l'accident se produit sur le thread UI du programme, pas un thread de travail. Mais il ne l'exclut pas, vous pourriez exécuter du code sur un travailleur qui fait quelque chose avec la fenêtre d'une manière illégale et la déstabilise. Provoquant un crash suivant. Si vous avez fidèlement utilisé le débogueur sans supprimer intentionnellement InvalidOperationException et ne créez aucune fenêtre sur un thread de travail, ce n'est pas une piste solide.

Pour en venir à la cause première, vous devez utiliser un débogueur non géré afin que vous puissiez voir exactement où le plantage se produit. Cela a tendance à être rude à plus d'un titre, comme ne pas être à la machine quand elle bombarde.Dans ce cas, vous devez demander à l'utilisateur de créer une minidump du processus écrasé. XP rend cela aussi douloureux, ce n'est pas une fonctionnalité intégrée et vous aurez du mal à utiliser le minidump si votre machine ne démarre pas XP. SysInternals' ProcDump utility est utile pour en enregistrer un. Une fois que vous en recevez un du client, vous devez l'ouvrir dans un débogueur et l'inspecter pour trouver la raison du plantage. Cela va être difficile si vous ne pouvez pas donner un sens à la trace de la pile que vous voyez maintenant, assurez-vous de demander l'aide des membres de l'équipe qui en savent plus sur les internes de Windows. Google "comment déboguer un minidump" pour en savoir plus, la page de procédure MSDN minimale is here.

Dans l'ensemble, ne vous attendez pas à des miracles ici, cela va prendre au moins un mois de votre vie escalade plusieurs courbes d'apprentissage raides et aucune garantie de succès. Ce qui inspire l'approche secondaire, si votre application est stable sur n'importe quelle version moderne de Windows, mais pas sur une ou deux machines XP alors, cela, sans doute, cesse d'être votre problème. Temps pour l'utilisateur de mettre à jour ses machines. Bonne chance.

Answer 2

Il y a quelques réponses qui pourraient être utiles ici: C# WebBrowser Control System.AccessViolationException

Aucun n'a été accepté, mais c'est parce que l'OP ne travaille plus sur le système affecté. Ceux qui ont le plus upvotes, en ignorant l'une que l'OP en promotion comme non pertinents sont les suivants:

• réinscrire la bibliothèque jscript.dll
• Surround tous les blocs de code qui accèdent à la commande de navigateur Internet avec des verrous (celui-ci mentionne même qu'il était en réponse à l'exception sur Windows XP 32-bit seulement)