Mein Prozess hat auf einmal hundertausende Handles

[Luckie]

Du hast doch gesagt, das dein Prozess die Handles verbraucht und zu deinem Prozess gehören. Also werden sie auch in deinem Prozess erzeugt. Und somit bist du auch für deren Freigabe zuständig. Also irgendwas stimmt da nicht.

[HolgerX]

Hmm..

Zitat von Luckie:

Du hast doch gesagt, das dein Prozess die Handles verbraucht und zu deinem Prozess gehören. Also werden sie auch in deinem Prozess erzeugt. Und somit bist du auch für deren Freigabe zuständig. Also irgendwas stimmt da nicht.

Leider nicht immer...

Es gibt Windows-APIs welche manchmal ihre intern erzeugten Handles nicht wieder freigeben oder zu exceptions führen.
Dadurch, dass deine App diese API aufruft, wird durch das Laden der zugehörigen DLL diese in deinen Prozess verfrachtet und seitens Windows als deine Handles/Exceptions angenommen.

Dies ist bei Treibern nicht anders...

[nahpets]

Zitat von Luckie:

Du hast doch gesagt, das dein Prozess die Handles verbraucht und zu deinem Prozess gehören. Also werden sie auch in deinem Prozess erzeugt. Und somit bist du auch für deren Freigabe zuständig. Also irgendwas stimmt da nicht.

Wenn ich die Ausgangsbeschreibung hier im Thread recht verstanden habe, bestehen nur bei einem Kunden Probleme mit Handles. Alle anderen Kunden haben kein Problem.
Der Kunde, bei dem das Problem auftritt, konnte es dadurch beheben, dass der zu verwendenden Drucker auf die Ausgangskonfiguration zurückgestellt wurde, also den von der zu Software zu verwendenden Drucker änderte.

Welches Problem muss jetzt in dem Programm behoben werden, das nur bei der Nutzung eines bestimmten Druckers Probleme mit Handles bekommt, aber sonst 24/7 problemlos bei der Zusammenarbeit mit beliebigen anderen Druckern funktioniert?

Oder anders formuliert: Wieso bin ich für Fehler verantwortlich, die von mir genutzte Druckertreiber ... enthalten und wie kann ich diese Fehler beheben, ohne Zugriff auf die Quelltexte dieser Treiber zu haben?

[Luckie]

War nur eine Idee.

[Der schöne Günther]

Die Jahre zogen uns Land, und heute bin ich wieder an einer Kiste, das gleiche Szenario:

Unsere Anwendung läuft erst seit wenigen Minuten, frisst aber ein halbes Gigabyte Speicher und hat 925.000 Handles! Wieder Device\Afd. Immerhin bleibt die Anzahl konstant. Ausgeliefert wurde die Kiste um den gleichen Zeitraum wie damals das System.

Ich vermute schon eher einen Bug in Windows/Windows Patch zu diesem Zeitpunkt, wäre nicht das erste mal gewesen.

[TiGü]

Wie ist denn der Windows-Stand (winver)?
Sind Updates eingespielt?

Hier irgendwas dabei, was du nicht schon kennst?
https://www.google.com/search?q=Devi...w=960&bih=1088

[Der schöne Günther]

Heute trat es wieder auf, und ich konnte es endlich reproduzieren.

Es ist eine Verkettung unglücklicher Zustände:

1. Eine selbst geschriebene DLL leakt zeitweise Sockets, also schließt sie nicht, obwohl sie es müsste
2. Unter bestimmten Umständen (nur während etwas anderes bestimmtes gleichzeitig abläuft) fängt diese DLL an und tut das mit ca. tausendfacher Geschwindigkeit
3. Unter noch bestimmteren Umständen spawnt unsere Anwendung zeitgleich noch zwei Konsolenanwendungen und vererbt alle ihre Handles noch an diese Kindprozesse (darunter halt zehntausende ungültige Sockets). Da diese Handles alle dupliziert werden lastet das den Rechner noch weiter aus, teilweise bis zum vollständigen Absturz

Das war echt einer der spannendsten Bugs seit langer Zeit