Fehlersuche: DLL vs eigener Code -> System.AccessViolationException

Moin,

ich hatte hier schonmal was zu einem Fehler gefragt, der wohl durch eine externe dll verursacht wird und schwer zu reproduzieren war.
Nach mehreren Updates war Ruhe und ich dachte das Problem wäre behoben, aber jetzt passiert öfter mal folgendes:

Mein Program läuft im Debugging in VisualStudio, keine Fehler -> Ich öffne z.B. Excel, makiere eine größere Zahl Zellen -> STRG+C -> Mein Programm stürzt ab mit:

Fehlermeldung:
$exception {"Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist."} System.AccessViolationException

StackTrace:

StackTrace " bei System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)\r\n bei System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)\r\n bei System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)\r\n bei System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)\r\n bei System.Windows.Forms.Application.Run(Form mainForm)\r\n bei ABC.Program.Main() in C:\Users\ABC\Documents\DEF\...\Program.cs:Zeile 19." string

Ich selbst benutze keinen Unsafe-Code oder irgendwas natives.
Kann das duch den Teil mit ".Windows.Forms.UnsafeNativeMethods.IMsoComponentManager" sicher so interpretieren, dass das durch die DLL kommen muss?

Oder sonst wie den Verursacher davon finden?

Was genau soll dein Programm denn machen?
Also warum reagiert es auf Eingaben bzw. Interaktion in EXCEL?

Was genau soll dein Programm denn machen?
Also warum reagiert es auf Eingaben bzw. Interaktion in EXCEL?

Mein Programm hat mit Excel nichts zu tun, das Problem ist mit Excel nur am besten zu reproduzieren.

Ein wenig ausgeholt:

Ich nutze den Bildbetrachter von Imageen in der .NET Variante (nennt sich IEvolution). In der Version 5 konnte ich ein Programm schreiben, das zuverlässig beim Verlieren des Fokus' mit der AccessViolation abgestürzt ist.

Nach Update der DLL ist das nicht mehr passiert, alles war in Ordnung.

Jetzt nach vielen Wochen war mein Programm offen (im VisualStudio Debugging) und daneben eben Excel mit ein paar Tabellen.
Ich klickte auf Excel, markierte einige Zellen, drückte STRG+C und mein Programm stürzt ab...

Und bevor ich mich an den Hersteller der DLL wende, würde ich gerne sicher gehen, dass man das auch darauf zurückführen kann und der Fehler nicht in meinem Code liegt.

Uff... schaue doch mal, ob du mit den Demos (https://www.imageen.com/demos/index.html) auch diese Probleme hast. =)

Hätte die DLL gerne ausprobiert, aber finde davon gerade keine Trial. 😁

Die Reproduktion von solchen Sachen ist Glücksache, da solche Fehler meistens passieren, wenn der Garbage Collector Objekte verschiebt, weil er den Speicher kompakter machen will. Der Garbage Collector ist dabei nicht deterministisch.
Du brauchst übrigens nicht zwangsweise unsafe Code - z.B. ein zu langes Buffer.BlockCopy kann auch da hinführen.

Uff... schaue doch mal, ob du mit den Demos (
> ) auch diese Probleme hast. =)

Die Demos sind größtenteils auch beim Paket dabei. Da tritt das bisher nicht auf. Auch bei einem anderen, einfacheren, Programm von mir kommt der Fehler nicht.

Bei meinem Testprogramm für Version 5 trat es auf, als ich:

• Per Druck auf Button1 ein Bild in den Viewer geladen habe
• Per Druck auf Button2 einfach so per LINQ eine sehr lange List<Point> sortiert habe

Es gab keine Verbindung von den Daten her zwischen den Beiden Methoden.

Mein jetziges Programm ist halt sehr viel größer, hat meherere Bildbetrachter, Tabellen, Graphen, parallelisierte Berechnungen, die ~2-5 s dauern...

Je aufwendiger das eigene Gewurste, desto wahrscheinlicher kratzt es ab, irgendwie 😄

Die Reproduktion von solchen Sachen ist Glücksache, da solche Fehler meistens passieren, wenn der Garbage Collector Objekte verschiebt, weil er den Speicher kompakter machen will.

Sowas mache ich auch nicht, ich benutze nach meinen vorhergehenden Erfahrungen nichtmal LINQ, sondern baue entsprechende Schleifen selber.

Ist halb blöd, dass man aus der Fehlermeldung nicht zumindest schließen kann wo der Fehler begraben liegt.

Gibt es da nicht irgendeine Möglichkeit? ^^

Der Garbage Collector arbeitet nicht-deterministisch neben Deinem Applikations-Code als Teil der Runtime. Da spielt es keine Rolle, ob Du Schleifen oder LINQ benutzt, auch wenn LINQ mehr Arbeit für den Garbage Collector macht.
Wenn Du Dich richtig reingraben willst, dann musst Du mit Perfview einen Dump beim Crash erzeugen und dann mit dem WinDbg Debugger ran. Am besten dann mehrere davon und dann kannst Du Glück haben, was zu sehen.

Wenn Du Dich richtig reingraben willst, dann musst Du mit Perfview einen Dump beim Crash erzeugen und dann mit dem WinDbg Debugger ran. Am besten dann mehrere davon und dann kannst Du Glück haben, was zu sehen.

👍
Ok danke.

Klingt nach wenig Spaß und viel Arbeit. Muss ich mal sehen, ob ich dafür Zeit und Lust haben... 🤔