Handle Count erhöht sich

[venice2]

Der Handle Counter erhöht sich meine Frage wäre warum?

Ich starte die Anwendung.
Jedesmal wenn ich ein neues Plugin starte erhöht sich der Handle Count um 1.
Ich kann im Process Explorer aber verfolgen das die DLL's entladen werden und zwar daran weil sie aus der Liste des Prozesses dann entfernt werden.
Welche Auswirkung hat das auf die gesamte Anwendung bei Dauerlauf?

Wie kann sich also der Count erhöhen wenn doch die DLL's korrekt entladen werden.

Es geht mir um das Handle der DLL nicht um ein Window Handle.

[hoika]

Hallo,
viell. weil es für Windows einfacher ist,
neue Nummern zu erzeugen statt alte wieder zu verwenden?

[venice2]

Zitat von hoika:

Hallo,
viell. weil es für Windows einfacher ist,
neue Nummern zu erzeugen statt alte wieder zu verwenden?

Verstehe ich nicht so recht was du mir sagen willst.
Welche Auswirkungen hat das auf meine Anwendung wenn diese als Beispiel 2 Wochen im Dauerbetrieb läuft 24 Stunden am Tag?

Was muss ich tun bzw wie kann ich das Analysieren welche Handles das sind.
Denn wie ich schon sagte werden die Plugins freigegeben.
Nur der Counter erhöht sich kontinuierlich.

Die Handles freigegeben warum erhöht sich trotzdem der Counter des prozess.

[hoika]

Hallo,
Ok, dann habe ich das falsch verstanden.
Was sagt denn FastMM4?

Was sind das für Plugins?
Ein bisschen Code wäre schön.
Und ein Minimal-Bsp.

Um zur Ausgangsfrage zukommen.
Irgendwann schmiert dein Windows ab wegen Ressourcenmangel.

[venice2]

Zitat von hoika:

Hallo,
Ok, dann habe ich das falsch verstanden.
Was sagt denn FastMM4?

Ist das nun ein Handle Leak oder nicht.
FastMM4 oder Eurekalog sagen dazu nichts.
Beide abwechslungsweise aktiviert.

Zitat:

Was sind das für Plugins?

Visualisierungs Plugins Sonique.

Werden aber freigegeben wäre das nicht so würde die Anwendung hängen.
Quelltext kann ich leder nicht veröffentlichen.
Aber es würde mir reichen wenn ich wüsste wie ich das am besten Analysieren kann.

[hoika]

Hallo,
alles ausklammern (Minimalbeispiel).
Laufen lassen. Testen.
Schrittweise den Code reinnehmen, laufen lassen. Testen.

Eskönnten GDI--Handles sein.

[himitsu]

Zitat von hoika:

weil es für Windows einfacher ist,
neue Nummern zu erzeugen statt alte wieder zu verwenden?

Es ist auch fehlerunganfälliger, wenn kurz nacheinander nicht die selbe ID vergeben wird.

Aber das betrifft nur den "Wert" des Handles, aber nicht die "Anzahl" aller Handles.

Wenn die Anzahl steigt, dann würde ich erstmal an ein "Speicherleck" denken, also dass Handles nicht wieder geschlossen/freigegeben werden


FastMM kennt nur Speicher, der über ihn Reserviert wurde ... Fremder Speicher (auch an ihm vorbei, direkt an VirtualAlloc) oder andere Handles interessieren ihn natürlich garnicht. (er weiß ja nichts davon)




Entweder die Tools von SysInternals.
Oder man macht sich einen Snapshot (alle Handles suchen und merken) und vergleicht das nachher,
dann muß man "nur" noch die neuen Handles auflösen und versuchen rauszubekommen was für ein Handle das ist.

[venice2]

Zitat:

Wenn die Anzahl steigt, dann würde ich erstmal an ein "Speicherleck" denken, also dass Handles nicht wieder geschlossen/freigegeben werden

Library wird freigegeben mit FreeLibrary Rückgabe ist immer true.
Mit GDIView kann ich keine probleme bzgl. GDI>Handles feststellen.

FastMM4 gibt keinen Fehler aus.
Schwierig.

[TiGü]

Und der andere Handle-Viewer von NirSoft?

[venice2]

Zitat von TiGü:

Und der andere Handle-Viewer von NirSoft?

Zeigt auch keine Auffälligkeiten.
Die GDI>Handles bleiben stabil aber der Counter inkrementiert trotzdem.

Habe einen Thread den ich nicht extra deaktiviere wenn ich ein Plugin ändere weil er das Timing regelt.
Dachte das es vielleicht daran liegt habe ihn deaktiviert und beim ändern eines neuen Plugins wieder aktiviert ändert aber auch nichts am Inkrementieren des Counter.