AW: Handle Count erhöht sich
Zitat:
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. |
AW: Handle Count erhöht sich
Zitat:
Mit GDIView kann ich keine probleme bzgl. GDI>Handles feststellen. FastMM4 gibt keinen Fehler aus. Schwierig. |
AW: Handle Count erhöht sich
Und der andere Handle-Viewer von NirSoft?
|
AW: Handle Count erhöht sich
Zitat:
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. |
AW: Handle Count erhöht sich
Es gibt verschiedene "Handles", drum hat der Taskmanager auch mehrere Spalten dafür, z.B.
* Handles (z.B. Dateien und Dergleichen) * GDI-Objects (die aus'm GDI) |
AW: Handle Count erhöht sich
Zitat:
Welche Schritte ich verfolge habe ich ja schon geschrieben. Nochmal. DLL entladen. true GDI_Handles keine Auffälligkeiten. Dateien werden freigegeben siehe DLL entladen. Threads ein und ausschalten versucht. Keine Änderung beim Counter. Das Handle das über BeginThread erstellt wird, wird ebenfalls geschlossen.
Delphi-Quellcode:
CloseHandle(Handle);
Danke. |
AW: Handle Count erhöht sich
Wieviele Handles hat Dein Programm vor dem Laden der DLL?
Wieviele Handles benötigst Du beim Laden der DLL? (vermutlich 1) Wieviele Handles hat das Programm, wenn die DLL geladen ist? (vermutlich 1, wenn mehr, benötigt die DLL selber auch noch welche) Wieviele Handles hat Dein Programm nach der Freigabe der DLL? Theoretisch Handles des Programmes + 1 beim Laden der DLL - 1 durch die Freigabe der DLL. Sollte also zu einem Nullsummenspiel werden: Handles vorher = Handles nachher. Wenn aber bei geladener DLL mehr als 1 Handle hinzukommt, aber beim Freigeben der DLL nur 1 Handle entfernt wird, liegt der Fehler (höchstwahrscheinlich) in der DLL. Hab' keine Ahnung, wie man das sicher und verlässlich überprüfen kann. Im Zweifelsfalle im Debugger an alle möglichen Stellen 'nen Breakpoint setzen und dort dann jeweils nachschauen, wie es so bei den Handles aussieht. DLL entladen. true: Das heißt aber nicht, dass die DLL selbst "vernünftig" aufgeräumt hat, sondern nur, dass Dein Programm die DLL "vernünftig" entladen hat. Das schließt halt nicht aus, dass hier trotzdem noch Handles übrigbleiben. |
AW: Handle Count erhöht sich
https://docs.microsoft.com/en-us/sys...wnloads/handle
oder den Process Explorer Ich hatte auch mal vor Jahren ein Handle-Leck und hab mir am Ende ganz böse einen extrem ineffektiven Code gebastelt, der alle eine Milliarde möglichen Handles durchprobiert, die "Gültigen" gezählt und dann vor/nach verdächtigen Funktionsaufrufen die Differenz gebildet. HANDLE = LongWord (Integer), aber die Handles sind "immer" an Integergrenzen ausgerichtet (weil ist "aktuell" zufällig direkt der Index zur HandleListe des Systems), deswegen ging es am Ende 3/4 schneller. :roll: Das Ergebnis könnte man sich auch in einer Liste oder Bitmaske speichern und für den Vergleich nutzen. Und teilweise ist es dann auch möglich zum Handle auch einen Namen zu bekommen. z.B. GetFinalPathNameByHandle, GetModuleFileName usw. |
AW: Handle Count erhöht sich
Zitat:
Und wird dann beim nächsten start einer anderen DLL inkrementiert. Zitat:
Warum bekomme ich mit LoadLibrary(xxx.dll) immer das gleiche Handle? |
AW: Handle Count erhöht sich
Zitat:
(Bei früheren Win Versionen konntest du via [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer] AlwaysUnloadDLL=1 erzwingen, dass die DLL nach dem Entladen nicht noch im Cache landete.) Es gibt sicher Leute hier, welche ganz genau wissen, wie das heute so läuft... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:19 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz