Erreur de mémoire corrompue C#

Question

Je ne peux pas publier le code (problèmes propriétaires), mais est-ce que quelqu'un sait quels types de choses provoqueraient l'erreur suivante en C#.Il est lancé par un client VOIP que j'ai écrit (à l'aide de l'API Counterpath) lorsque l'appel est terminé par l'autre client.L'erreur est :

System.AccessViolationException was unhandled
  Message="Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
  Source="System.Windows.Forms"
  StackTrace:
       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.Run(Form mainForm)
       at CollabAnalysisSF.Edge.GUI.Forms.Program.Main() in d:\data\beyerss\Desktop\client\GUI\ARGui\Program.cs:line 18
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

MISE À JOUR:
Il s'avère que l'une des bibliothèques que nous utilisions envoyait un événement dont nous ne connaissions pas l'existence, et le problème était quelque part.Corrigé maintenant.

Answer 1

Liste de quelques possibilités :

• Un objet est utilisé après avoir été éliminé.Cela peut arriver souvent si vous supprimez un objet géré dans un finaliseur (vous ne devriez pas le faire).
• Une implémentation non gérée de l'un des objets que vous utilisez est boguée et a corrompu le tas de mémoire du processus.Cela arrive souvent avec DirectX, GDI et autres.
• Le mashaling sur la frontière gérée-non gérée est défectueux.Assurez-vous d'épingler un pointeur géré avant de l'utiliser sur une partie non gérée du code.
• Vous utilisez un bloc dangereux et faites des choses amusantes avec.

---

Dans votre cas, cela pourrait être un problème avec Windows Forms.Mais le problème n’est pas que cela se produit, mais plutôt que cela n’est pas signalé correctement ;vous avez peut-être encore fait quelque chose de mal.

Êtes-vous en mesure de déterminer quel contrôle est à l’origine de l’erreur à l’aide du HWND ?Est-ce toujours pareil ?Ce contrôle fait-il quelque chose de drôle juste avant que l'application ne plante ?La partie non gérée du contrôle est-elle une fenêtre personnalisée ou un contrôle standard ?

Answer 2

Ce type de problème peut se produire si vous appelez du code non géré, par ex.une dll.Cela peut se produire lorsque le Marshalling tourne terriblement mal.

Pouvez-vous nous dire si vous appelez du code non managé ?Si oui, utilisez-vous le Marshalling par défaut ou des éléments plus spécifiques ?D'après l'apparence de la trace de la pile, utilisez-vous du code dangereux, par ex.Des pointeurs et autres ?Ce pourrait être votre problème.

Answer 3

Voici une trace de pile plus détaillée.Il me semble que cela a quelque chose à voir avec System.Windows.Form.dll

le TargetSite est répertorié comme {IntPtr DispatchMessageW(MSG ByRef)}
et sous le module, il a System.windows.forms.dll