[Windows 7] Gibt es noch resourcen die ins System leaken?

[Memnarch]

Hi,
Habe eine Applikation. Diese wird mehrmals am Tag im Hintergrund gestartet. Benutzt wird alles, von GUI, über Pipes und CriticalSections. Kann es sein, dass es noch Resourcen/Handles gibt die ins System leaken? Ich dachte Windows räumt beim beenden des Prozesses alles auf?

Symptom: Nach 1-2 Tagen lässt sich nichts mehr in Windows Starten, der Benutzer muss abgemeldet und wieder angemeldet werden. Ram ist OK, globaler HandleCount sowie GDI-Count im Taskmanager ist auch nicht verdächtig.

Andere Programme kriegen dann beim Starten intern den OSError dass entweder kein Speicher zur Verfügung steht und/oder das Fenster nicht erstellt werden konnte. Das ist recht merkwürdig, da nach außen hin nichts ungewöhnlich scheint.

Jemand spontan ne AHnung, welche Resourcen ins System leaken? Dann kann ich darauf mal genauer nen Blick werfen.

Grüße
Memnarch

[Bernhard Geyer]

Richtiger Rechner oder Citrix-Verseucht? Also ein Citrix-Server der das Problem hat

[Memnarch]

Richtig Rechner, soweit nichts spezielles.

EDIT: Da wir das Problem vor kurzem festgestellt haben, haben wir einen Lasttest aufgesetzt. Auf dem PC wird die Applikation jetzt mehrerer Tausendmal gestartet/geschlossen. Damit lässt sich der Zeitraum auf ~1-2Tage reduzieren. Normalerweise würde es vllt 4-5 Tage dauern. Da der Kunde aber theoretisch genau sowas machen könnte, muss das auch funktionieren(Falls jemand meint 5 Tage wäre ja lang genug ;) ).

[Namenloser]

Irgendeine Form von Speicherfragmentierung vielleicht? :gruebel:

Oder vielleicht ein fehlerhaftes Virenschutzprogramm, das sich irgendwie vor dem Taskmanager verbirgt? (oder sonstiges Rootkit?)

[Memnarch]

Die Testumgebungen um dem Problem auf die Spur zu kommen, sind extra dafür aufgesetzt. IIRC wurde auch keine AntiVir irgendeiner Art installiert. Die haben nicht mal Internet-Anschluss. Speicherfragmentierung kommt nicht Frage, da nach beenden des Prozesses nur ~4-500MB Ram von 2GB belegt sind. Das sollte niemanden stören.

EDIT und tatsächlich ist nach dem alles kaputt ist, das wichtigste den Benutzer ab/anzumelden. Danach ist wieder alles in Butter.

[zagota]

Welche Delphi-Version verwendest du?

In Delphi 2010 ist in Controls.pas ein Bug.
Bei jedem Start wird mit RegisterWindowMessage() eine Message registiert, die in die User-Atomtabelle eingetragen wird und daraus nicht mehr gelöscht werden kann.

https://forums.embarcadero.com/threa...threadID=47678

cu

[Memnarch]

Delphi XE
EDIT: wie darf ich den QC EIntrag deuten? Ab XE3 gefixxt?

[zagota]

Zitat:

Zitat von Memnarch (Beitrag 1288887)

Delphi XE
EDIT: wie darf ich den QC EIntrag deuten? Ab XE3 gefixxt?

in XE3 ist es gefixt.

in D2010 habe ich es so gefixt:
// RM_GetObjectInstance := RegisterWindowMessage(PChar(ControlAtomString));
RM_GetObjectInstance := RegisterWindowMessage('DelphiRM_GetObjectInstance' );

PS: hier kannst du ein Programm herunterladen, dass die Atomtabelle ausgibt:
https://code.google.com/p/atom-table-monitor/

[Memnarch]

Vielen Dank an alle, das könnte es sein. habe das Tool auf einemd er Testrechner gestartet und wir gucken dem System jetzt mal beim Sterben zu. Bisher sinds stolze 2244 Atoms von Delphi, zahl stetig steigend. Aufgrund der hohen frequenz der Delphi-Atoms sind die netterweise ROT markiert. Eine Wall of Death die auf dem Monitor langsam nach unten schneckt.

Wir haben bereits XE7, aber bis unsere komplette Buildumgebung umgestellt und getestet wurde, ob die genutzten Komponennten noch so laufen wie sie sollen, wirds nochn paar Wochen dauern.

Trotzdem gut zu wissen, wo der hase lang zu laufen scheint.

[Klaus01]

.. ganz unten in dem link aus Beitrag #6 ist doch das IDE-Fixpack von jbg aufgeführt - sollte damit nicht dem Problem beizukommen sein?

Grüße
Klaus

[zagota]

Zitat:

Zitat von Klaus01 (Beitrag 1288893)

.. ganz unten in dem link aus Beitrag #6 ist doch das IDE-Fixpack von jbg aufgeführt - sollte damit nicht dem Problem beizukommen sein?

Grüße
Klaus

Ich glaube das ist nur ein Fix für die IDE, den Fix für die Sourcen musst du in der controls.pas durchführen.

cu

[Memnarch]

Jup da gibts ControlAtomsFix.pas
Sieht auch vielversprechend aus. Frage ist nur:

Besagtes Programm linkt gegen ein Package(Von uns), welches gegen die VCL/RTL Packages gelinkt ist.
Die besagte unit mit dem FIX soll aber unbedingt vor allen GUI units laufen. Das heißt, wenn ichs an den anfang der dpk von unserem Basispackage packe läuft deren Initialize trotzdem nach denen der VCL/RTL packages, oder? Damit wäre Controls.pas mindestens einmal gelaufen bevor die FixUnit läuft.

[Memnarch]

Nachdem ich ejtzt mal ein bisschen rumprobiert habe, musste ich feststellen, dass die ControlsAtomFix.pas nicht funktioniert.
Builde ich ohne packages
"Patch applied" meldung, leaked aber weiterhin

wenn ich mit Packages Builde kommt gar keine Meldung, und es leaked weiter.

EDIT:
Im Consolefenster meldets mit dann "RegisterWindowMessageW import table slot not found"

[Memnarch]

Ich hab jetzt eine eigene implementierung gemacht, die MadCodeHook benutzt. Wetaus kürzer und lesbarer und funktioniert jetzt wies soll.
Zugegeben, da gabs noch ein anderes Problem:

Meine Applikation linkt gegen PackageA(Was gegen RTL/VCL gelinkt ist). Allerdings linkt meine Applikation auch gegen MeineDll, welche auch gegen PackageA linkt. Was bedeutet das? Es zerrümpelt die Reihenfolge in der units initialisiert werden, den dadurch kommen erst die units aus den packages und dann die units aus Meiner Applikation (normalerweise ist das von der Reihenfolge in der Applikation abhängig). Deswegen war auch schon alles initialisiert bevor der erste initialisierungsblock meiner Applikation lief -.-

EDIT: Habe den Verdacht, dass das laden der Packages durch die DLL auch hierfür verantwortlich ist:
CreateProcessAsUser + Link gegen VCLPackage = kein Application.Handle

Dass muss ich aber nochmal testen