Version imprimable
Bonjour je développe en ce moment une dll en C# avec Microsoft Visual Studio 2005
et j'ai régulièrement lors de mes séances de debugging le message suivant
Pièce jointe 31707
puis je suis obligé d'arréter le debugger car plus rien ne fonctionne correctement.
Quelqu'un sait-il comment résoudre ce type de problème pour ne plus avoir ces messages qui me ralentissent vraiment beaucoup ?
Merci
PS :
Je suis vraiment débutant en C#
Apparemment, tu aurais un problème avec COM, et pour te répondre, j'aurais besoin de ton code source (mettre la la fonction sur lequel ton programme s'arrête au minimum)
PS: Tu pourrais au moins mettre le message sur ton post (au lieu de mettre une pièce jointe) et évité les titres du genre "Problème avec Visual Studio" (on s'en doute un peu) et mettre un titre plus explicite
Salut Super escargot
D'abord merci d'essayer de me répondre.
Ensuite je post ici depuis peu et je n'ai pas pigé comment faire apparaitre autrement ma petite copie d'écran (le fichier ne s'uploadait pas quand j'attachais directement le fichier car trop lourd).
Sinon malheureusement, je ne peux pas partager mes sources (désolé), de plus pour que tu puisses faire tourner la dll il te faudrait un autre programme (l'interface COM est faite pour ce soft).
En fait, je voulais savoir si,
d'une part,
c'était un problème avec Visual Studio ou bien si c'était parce que le debbuging d'interface COM était sujet à ce type de problème,
et si d'autre part,
quelqu'un avait déjà rencontré le même type de problème et comment il avait pu le résoudre.
J'ajouterai enfin que le debuger marche mais qu'au bout d'un moment si je reste inactif trop longtemps, le message (cf post précédent) apparait et tout est bloqué. Du coup je n'ai plus qu'à redémarrer le debuger.
Merci encore de ton attention.
J'ai aussi eu ce genre de problème lorsque je debug et que je reste sur un point d'arrêt trop longtemps.
Cela peut arriver lorsque tu as une appli multithread et que tu reste sur un point d'arrêt dans un thread et que les autres s'éxécutent. Comme si plusieurs threads (même code) viennent se bloquer sur le point d'arrêt. Sur msdn il y a ça :Citation:
L'Assistant Débogage managé (MDA, Managed Debugging Assistant) ContextSwitchDeadlock est activé lorsqu'un blocage est détecté au cours d'une tentative de transition de contexte COM.
Symptômes
Le symptôme le plus courant est qu'un appel sur un composant COM non managé à partir du code managé ne soit pas retourné. Un autre symptôme est l'augmentation de l'utilisation de la mémoire avec le temps.
Cause
La cause la plus probable est qu'un thread cloisonné (STA, Single-Threaded Apartment) ne pompe pas de messages. Le thread cloisonné (STA, Single-Threaded Apartment) attend sans pomper de messages ou exécute de longues opérations et n'autorise pas la file d'attente de messages à pomper.
L'augmentation de l'utilisation de la mémoire avec le temps est due à la tentative du thread finaliseur d'appeler release sur un composant COM non managé et au fait que ce composant ne soit pas retourné. Cela empêche le finaliseur de récupérer d'autres objets.
Résolution
Suivez les règles COM concernant le pompage de messages STA.
Effet sur le runtime
Ce MDA n'a aucun effet sur le CLR. Il signale uniquement des données relatives aux contextes COM.
Sortie
Message décrivant le contexte courant et le contexte cible.
Configuration
Copier le code
<mdaConfig>
<assistants>
<contextSwitchDeadlock enable="false" />
</assistants>
</mdaConfig>
merci ppphil
je viens de trouver la même chose que toi en bidouillant un peu dans les menus Visual Studio.
J'ai donc décoché :
"ContextSwitchDeadlock" comme ceci (cf piece jointe)
et ça marche bien.
Par contre je ne sais pas trop si ça va pas provoquer des erreurs assez graves par ailleurs et donc je ne sais pas si c'est à recommander comme solution.
Pièce jointe 31742
Salut,
J'ai également eu le problème avec une appli mono thread, sous Visual C# Express 2005, et uniquement durant des sessions de Debug intense.
La désactivation d'exception sur le ContextSwitchDeadLock m'a bien aidé... et d'après la MSDN, cela ne devrait pas avoir d'incidence sur le Runtime (Effet sur le runtime
Ce MDA n'a aucun effet sur le CLR. Il signale uniquement des données relatives aux contextes COM.
)
Au passage, ça m'a permis de sauver quelques cheveux également... :mouarf: