Laden...

[erledigt] Speicherfehler wegen vergessener Freigabe der COM Objekte

Erstellt von Wolf_maYer vor 16 Jahren Letzter Beitrag vor 16 Jahren 5.241 Views
Wolf_maYer Themenstarter:in
286 Beiträge seit 2006
vor 16 Jahren
[erledigt] Speicherfehler wegen vergessener Freigabe der COM Objekte

Hi,
es tut mir furchtbar leid, dass jetzt warscheinlich eine Glaskugel-Frage stelle. Ich hocke nur schon seit Heute Morgen vor zahlreichen Speicherfehlern, bei denen ich einfach nicht weiter komme.

Eine der Fehlermeldung schaut wie folgt aus:

Fehlermeldung: Exception of type 'System.OutOfMemoryException' was thrown.
StackTrace: at System.Threading.Thread.StartInternal(IPrincipal principal, StackCrawlMark& stackMark)
at System.Threading.Thread.Start()
at System.Threading.Thread.Start(Object parameter)

Die Fehlermeldung sagt ja aus, dass es sich hierbei um einen Fehler handelt, bei dem der Arbeitsspeicher voll ist und dem Betriebssystem keiner mehr zur Verfügung steht. Das kann aber nicht sein, da noch ca. ein GB frei ist.

Ein anderer Fehler an einer ganz anderen Stelle lautet:

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
StackTrace: at System.Reflection.AssemblyName.nInit(Assembly& assembly, Boolean forIntrospection, Boolean raiseResolveEvent)
at System.Reflection.AssemblyName.nInit()
at System.Reflection.AssemblyName..ctor(String assemblyName)
at System.Resources.ResourceManager.CanUseDefaultResourceClasses(String readerTypeName, String resSetTypeName)
at System.Resources.ResourceManager.CreateResourceSet(Stream store, Assembly assembly)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
at System.Resources.ResourceManager.GetObject(String name, CultureInfo culture, Boolean wrapUnmanagedMemStream)
at System.Resources.ResourceManager.GetObject(String name)

Jetzt stehe ich leider komplett vor einer Wand, bei der ich icht weiß wo ich anfangen soll zu suchen.

Gibt es vielleicht eine Möglichkeit, mit der man Erfahren kann, ob und womit ein Programm oder ein Teil eines Programms diese Speicherfehler verursacht? Ich glaube, dass die Ursache nicht an der ist, an der der Fehler auftritt sondern an einer ganz anderen, die ich momentan einfach icht auf dem Schirm habe.

Wie Ihr merkt, greife ich gerade nach dem letzten Strohhalm und freue mich auf irgendeinen noch so kleinen Tip.

Viele Grüße, maYer

100 Beiträge seit 2006
vor 16 Jahren

Ein Profiler-Tool könnte dir möglicherweise weiterhelfen, etwa das kostenlose ProfileSharp.

Neben dem normalen Performance-Modus, der dir anzeigt in welchen Funktionen dein Programm die meiste Zeit verweilt, gibt es auch einen Memory-Modus zur Suche von Speicherlöchern.

Bei der Gelegenheit stellt sich die Frage, ob es in C# einen new_handler wie bei C++ gibt 🙂

49.485 Beiträge seit 2005
vor 16 Jahren

Hallo Wolf_maYer,

Die Fehlermeldung sagt ja aus, dass es sich hierbei um einen Fehler handelt, bei dem der Arbeitsspeicher voll ist und dem Betriebssystem keiner mehr zur Verfügung steht. Das kann aber nicht sein, da noch ca. ein GB frei ist.

Speicher != Arbeitsspeicher. Es kann auch sein, dass kein Speicher mehr für die Verwaltung von Threads vorhanden ist, also kein Speicher mehr in bestimmten interen Datenstrukturen des Betriebssystems.

herbivore

Wolf_maYer Themenstarter:in
286 Beiträge seit 2006
vor 16 Jahren

Hi,
danke ihr Beiden. Ihr macht mir Mut, dass es mit viel Mühe ja doch noch zu knacken ist.

Es ist so, dass wir mit einem C++ Bereich Arbeiten, der den CSharp Teil aufruft. Es ist leider momentan nicht anders zu handeln.
Kann es sein, dass im C++ Bereich irgendetwas falsch Initialisiert ist o.Ä., was mich dann im C# Teil mit meinem Threadding in die Knie zwingt? Ich weiß leider nicht, wie ich das besser umschreiben soll.

Den Profiler werde ich mir mal gründlich anschauen. Aber ich glaube, dass die eigentlichen Fehler im C++ Teil liegen. Ich hatte vorher eigentlich nie Probleme mit Speicherbereichen obwohl ich MultiThreadding ausgiebig genutzt habe.

Gruß, maYer

230 Beiträge seit 2007
vor 16 Jahren

Treten die Exceptions immer in der gleichen Reihenfolge auf und sind es ausschliesslich memory Fehler? Programm schon auf einem rohen OS Rechner oder in einer VM getestet? Dlls in C++? oder alles schon gemischt?

S
8.746 Beiträge seit 2005
vor 16 Jahren

Wie viele Thread machst du denn so auf?

Wolf_maYer Themenstarter:in
286 Beiträge seit 2006
vor 16 Jahren

Hi Sarabande,
es waren bis jetzt ausschließlich Speicher Fehler.
Heute ist noch ein neuer Fehlertyp dazu gekommen:

Fehler: Error creating window handle.
StackTrace: at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.TextBoxBase.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.OnParentVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.ScrollableControl.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.Form.OnVisibleChanged(EventArgs e)
at System.Windows.Forms.Control.SetVisibleCore(Boolean value)
at System.Windows.Forms.Form.SetVisibleCore(Boolean value)
at System.Windows.Forms.Control.set_Visible(Boolean value)
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.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()

Wir haben es noch nciht auf einem Cleanen Rechner laufen gelassen sondern auf den üblichen Testrechnern, auf denen das Programm sonst auch immer gelaufen ist.

Bei den C++ Geschichten handelt es sich ausschließlich um DLL´s.

@Svenson:
ich habe eigentlich immer nur einen Thread offen um die Datenoperationen durchzuführen und die GUI nicht zu blockieren. Der Benutzer bekommt einen InfoDialog mit einer Progressbar angezeigt.

Mit dem Profiler werde ich mich heute anfreunden und werde einmal schauen, was er mir so erzählt.

Gruß und vielen Dank für die Denkanstöße,
maYer

49.485 Beiträge seit 2005
vor 16 Jahren

Hallo Wolf_maYer,

Heute ist noch ein neuer Fehlertyp dazu gekommen

auch das kann ein Speicherfehler sein, wenn das Erzeugen des Handles nicht funktioniert, weil (in den internen Datenstrukturen) kein Speicher mehr für einen neuen Handle ist.

Insgesamt sieht es so aus, also würde dein Programm massig Ressourcen (Thread, Controls, Handles) anfordern, ohne sie wieder freizugeben. Hast du irgendwo eine Endlosrekursion oder eine Endlosschleife, die das verursacht?

herbivore

Wolf_maYer Themenstarter:in
286 Beiträge seit 2006
vor 16 Jahren

Hmm,
also das Programm, welches wir schreiben ist eine Integration in eine CAD-Anwendung. Dementsprechend Speicher benötigt die komplette Anwendung.

Ich selber bin nicht für den kompletten Code zuständig sondern nur für ca. 35% des C# Codes (Datenbank Anbindung und ein paar Funktionalitäten in der BI)

Der C++ Code wird von einem anderen Entwickler verwaltet, gewartet und erweitert.
C++ ist deswegen noch enthalten, weil die Integration beim Projektstart nur unter C++ realisierbar gewesen ist. Inzwischen gibt es auch ein C# Interface.

Ich werde ihn einmal anhauen, ob er seine Bereich auf diese Vermutung hin untersuchen kann.

383 Beiträge seit 2006
vor 16 Jahren

Hallo Wolf_maYer

Dieser Artikel befasst sich mit der OutOfMemoryException - Problematik:

https://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx

Gruss
wakestar

S
8.746 Beiträge seit 2005
vor 16 Jahren

Es ist doch offensichtlich ein Problem von nicht-verwalteten Ressourcen. Die Frage ist doch nur, wer damit rumsaut. Der .NET bzw. der C++-Teil.

Dazu einfach die Leistungsanzeige (Systemsteuerung/Verwaltung) starten und den Indikator .NET CLR Speicher / Anzahl der GC Handle auswählen.

Üblicherweise benötigt ein UI-Programm ein paar Dutzend bis ein paar hundert Handles. Falls dein Programm schuld ist, dann wird sich hier der Wert in zweistellige Tausenderzahlen schwingen.

Dann fehlen wahrscheinlich nur Dispose()-Aufrufe - wie schon vermutet.

Wolf_maYer Themenstarter:in
286 Beiträge seit 2006
vor 16 Jahren

Hi,
wir sind schon einmal so weit, dass wir den Bereich eingrenzen können an dem der Mist passiert.

Es scheint wohl so zu sein, dass ich ein COM-Objekt aus der Fremdapplikation aufrufe und dieses nicht wieder richtig frei gegeben wird.

Ein ähnliches Problem trat im C++ Bereich auch schon auf, dass mit einem "Detach auf dem Pointer sobald der Code mit der Arbeit auf dem Objekt fertig war" gelöst wurde.

In C# arbeite ich jetzt nicht mit einem Pointer auf dem Objekt sondern ich Arbeite auf dem Interop Interface und habe dementsprechend keinen Pointer.

Reicht da ein auf NULL setzen?

Gruß, maYer

Wolf_maYer Themenstarter:in
286 Beiträge seit 2006
vor 16 Jahren

Ich versuche es mal mit:


System.Runtime.InteropServices.Marshal.ReleaseComObject()

gruß, maYer

Wolf_maYer Themenstarter:in
286 Beiträge seit 2006
vor 16 Jahren

Es läuft jetzt sauber durch.

Vielen Dank für Eure Hilfe 😉

Gruß, maYer