C# erreur de mémoire corrompue

Question

Je ne peux pas poster le code (problèmes de propriété), mais quelqu'un sait quels types de choses causeraient l'erreur suivante en C#. Il est lancé par un client VOIP que j'ai écrit (en utilisant 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 au large un événement que nous ne savions pas à propos, et le problème était là quelque part. Fixé maintenant

Answer 1

Liste de quelques possibilités:

• Un objet est utilisé une fois qu'il a été disposé. Cela peut arriver beaucoup si vous disposez d'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 mise en cache et a corrompu le tas de mémoire de processus. Ça arrive beaucoup avec DirectX, GDI et autres.
• Le masquage sur une limite 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 du code non gérée.
• Vous utilisez un bloc non sécurisé et faites des choses amusantes avec.

---

En vous cas, il pourrait être un problème avec Windows Forms. Mais le problème n'est pas que cela se produise, mais plutôt qu'il n'est pas rapporté correctement; vous avez peut-être encore fait quelque chose de mal.

Etes-vous en mesure de déterminer quel contrôle cause l'erreur en utilisant le HWND? Est-ce toujours la même chose? 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 prolem peut se produire si vous appelez du code non géré, par ex. un dll. Cela peut arriver quand le Marshalling va terriblement mal. Pouvez-vous nous dire si vous appelez du code non géré?

Si oui utilisez-vous Marshalling par défaut ou des choses plus spécifiques? A partir de l'apparence de la trace de la pile, utilisez-vous un code dangereux, par ex. Les 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 le System.Windows.Form.dll

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