Mein Prozess hat auf einmal hundertausende Handles

[Der schöne Günther]

Die schrecklichen Dinge passieren immer wenn man eigentlich ins Wochenende wollte.

Ein einziges System beim Kunden hat merkwürdige Probleme. Hier der Ablauf:

1. Optional: Im Event-Viewer tritt ein Ereignis 2004 "Resource exhaustion detection" auf
2. Die Anwendung ist nicht merklich langsamer zu bedienen, alles sieht noch normal aus
3. Erste Datei- und Netzwerkzugriffe der Anwendung scheitern: Allgemein ist es der Windows-Fehler 1816
   Delphi-Quellcode:

   NOT_ENOUGH_QUOTA

   für Zugriffe auf Netzwerk-Sockets, serielle Ports sowie das Öffnen von lokalen Dateien auf der Festplatte
4. Wenn man es noch schafft die Anwendung zu beenden während alles in sich zusammenstürzt fährt die Anwendung ordnungsgemäß herunter
5. Nach einem Neustart der Anwendung ist alles wieder gut

Ich hatte diesmal das Glück per TeamViewer fast live dabei sein zu können. Was sehe ich im Task-Manager? Nichts besonderes. Schaue ich später noch einmal: Plötzlich über 650.000 Handles für meinen Prozess. Schwer zu glauben, aber es ist so.
Anhang 47750


Ich kann den Fehler bei mir lokal nicht nachstellen. Schaue ich mit dem Process Explorer mir einmal genauer hin, sind die Handles alle zu

Delphi-Quellcode:

Device\Afd

:
Anhang 47751

Ich suche im Internet zu "device afd handle leak" und ähnlichem, werde da aber auf die Schnelle nicht schlau. Meist scheinen es fehlerhafte Treiber zu sein, auch ich habe hier einen vom Kunden eingebundenen Netzwerkdrucker im Verdacht.


Hat jemand hier noch schlaue Ideen? Ich bin so frustriert dass ich noch nicht einmal eine Ursache finden kann. Fast 24 Stunden lief alles ohne das geringste Murren, dann fällt plötzlich alles in sich zusammen.

Ich werde in der eigenen Anwendung in Zukunft versuchen Dinge wie Speicherfragmentierung und Anzahl der Handles zu protokollieren, aber das hilft einem ja auch nur beim Raten, sollte es bei einem anderen Kunden irgendwann auch einmal auftreten.

[nahpets]

Gib' uns bitte mal ein paar mehr Infos zum Programm:

Was macht es grundsätzlich?

Was im Besonderen?

z. B.:

viele Dateizugriffe lokal, im Netz?
Drucken, lokal, im Netz?
Benutzung von Schnittstellen?
WMI?
Datenbank?
...

Was sonst auch immer, was irgendwelche Handles benötigen könnte?

Besonderheiten beim betroffenen Rechner?
Betriebssystem, Hardware ...

[Der schöne Günther]

Das Programm ist monolithische 32 Bit VCL-Anwendung mit ein paar DLLs, die meisten davon auch mit Delphi erstellt. Kompiliert in 10 Seattle.

Es kommuniziert kontinuierlich mit etlichen Geräte über serielle Ports, Ethernet (IPv4, TCP und UDP) und loggt periodisch auf die Festplatte. Es agiert auch als TCP-Server auf mehreren Ports über mehrere Netzwerkkarten.

Es ist rund um die Welt im Einsatz und hat keine Probleme damit mehrere Wochen am Stück zu laufen und zu arbeiten.

OS ist Windows 7 Pro x64, das System hat 4GB Arbeitsspeicher.



Handles? Natürlich überall. Dinge die wir nicht wirklich im Griff haben was da abgeht sind einmal

• Druckvorgänge (alte Schule über Vcl.Printers sowie FastReport)
• Der TWebBrowser (insbesondere PDF-Anzeige über das Adobe Reader-Plugin)

Gerade letzteres (Anzeigen einer PDF über den TWebBrowser) treibt den HandleCount der Anwendung in die Höhe, möglich dass da etwas nicht ganz sauber ist. Die absolut wahnsinnige Zahl von 650.000 Handles erklärt es trotzdem nicht allein, da hätte jemand mehrere tausend male etliche Seiten PDF wälzen müssen.

Und wie gesagt, es ist nur dieses eine System, andere Fälle sind mir nicht bekannt.

[nahpets]

Einziges System bei diesem Kunden?

System überprüfen, ob Hard- und Software ordnungsgemäß installiert sind und reibungslos funktionieren.

Gibt es irgendwelche Auffälligkeiten im Ereignisprotokoll, ggfls. auch zu anderen Themen?

Irgendwelche Auffälligkeiten bei Benutzung anderer Software auf dem Rechner bekannt?

Wenn die Software weltweit reibunglos funktioniert, dann sicherlich auch auf unterschiedlicher Hardware in den vielfältigsten Hard- und Softwarekombinationen. Das scheint ja kein Problem zu sein.

Von daher würd' ich bei der Fehlersuche den Schwerpunkt auf den konkreten Rechner und seine Analyse legen und nicht auf eure Software.

Oder anders formuliert: Ich vermute da eher eine difuse Fehlerquelle in dem speziellen System und der dort vorhanden Soft- und Hardware.

Irgendwelche besondere Anforderungen an die Hardware vorhanden?

Ansonsten Maschine gegen anderes System austauschen und schauen, ob das Problem bestehen bleibt.
Wenn ja, dann liegt der Fehler irgendwo außerhalb des System, d. h.: Irgendeine "externe" Stelle, mit der kommuniziert, wird arbeitet nicht ordentlich, so dass euer System (oder auch das Betriebssystem) damit nicht zurechtkommt und von daher (von welchen Operationen auch immer) irgendwelcher Reste übrigbleiben, die das System (früher oder später) in die Knie zwingt.

Da könnte z. B. ausgehend von Deiner Beschreibung eine nicht sauber arbeitende Netzwerkverbindung mit ursächlich sein.

Da hilft ggfls. mal Kabel tauschen. Nicht nur am Rechner selbst, sondern auch die, die sonstwo weiter in die nähere oder weitere Netzwerkwelt reichen.

Hast Du 'nen Netzwerkmonitor zur Verfügung, mit dem Du regelmäßig alle vom Rechner aus zwingend erreichbaren "Gerätschaften" anpingen kannst, um über die Ergebnisse feststellen zu können, ob da irgendwo was klemmt?

[Luckie]

Kann der Kunde testweise das Programm auf einem anderen Rechner installieren und nutzen?

[Der schöne Günther]

Vielen Dank für die Antworten.

Zitat:

Zitat von nahpets (Beitrag 1379025)

Einziges System bei diesem Kunden? [...] Ansonsten Maschine gegen anderes System austauschen

Zitat:

Zitat von Luckie (Beitrag 1379031)

testweise das Programm auf einem anderen Rechner installieren und nutzen?

Der PC steckt in einem abgeschlossenen Schaltschrank, das System wurde diese Woche erst in Betrieb genommen und der Techniker von uns ist heute wieder abgeflogen. Die Kernfunktion des Systems ist gegeben, die werden da nichts dran ändern. Verständlich.

Zitat:

Zitat von nahpets (Beitrag 1379025)

Auffälligkeiten bei Benutzung anderer Software

Der PC kommt von uns vorinstalliert, da läuft 24/7 nur unsere Software drauf.

Zitat:

Zitat von nahpets (Beitrag 1379025)

Von daher würd' ich bei der Fehlersuche den Schwerpunkt auf den konkreten Rechner und seine Analyse legen und nicht auf eure Software.

Oder anders formuliert: Ich vermute da eher eine difuse Fehlerquelle in dem speziellen System und der dort vorhanden Soft- und Hardware.

Ich auch. Leider habe ich nur eine TeamViewer-Verbindung und allzu viel auf dem Bildschirm wühlen kann ich auch nicht da mit dem Ding Tag und Nacht Leute arbeiten. Doof.

Zitat:

Zitat von nahpets (Beitrag 1379025)

Hast Du 'nen Netzwerkmonitor zur Verfügung, mit dem Du regelmäßig alle vom Rechner aus zwingend erreichbaren "Gerätschaften" anpingen kannst, um über die Ergebnisse feststellen zu können, ob da irgendwo was klemmt?

Die Software, loggt, wenn sie Kommunikationsprobleme mit anderen Teilnehmern hat, das selbst.

Es war ja heute so dass ca. 24 Stunden keine Auffälligkeit war, alles sauber, plötzlich fällt alles in sich zusammen weil Windows wohl die Handles ausgehen.

Ich habe halt noch die Hoffnung dass ich mit dem "Device\Afd" irgendwie weiterkomme...

[nahpets]

Zitat:

Zitat von Der schöne Günther (Beitrag 1379041)

Ich habe halt noch die Hoffnung dass ich mit dem "Device\Afd" irgendwie weiterkomme...

Viel ist zu dem Thema irgendwie nicht zu finden.

Was ich bisher weiß / erahne:

Es hängt mit der adf.sys zusammen.

WinSocket ist irgendwie betroffen. (Kann auch im Zusammenhang mit dem Printspooler stehen. Druckvorgänge können hier also betroffen sein. Werden bei dem Kunden irgendwelche exotische Druckertreiber genutzt, die sonst kein anderer Kunde nutzt?)

Die Handles bleiben übrig, wenn Sockets nicht geschlossen werden.

Nach alldem, was ich so überflogen habe, würd' ich hier ein Problem in der "Netzwerkumgebung" und/oder im "Druckerumfeld" vermuten. Es scheint so, als würden nicht alle Verbindungen ordentlich arbeiten und/oder beendet werden.

Keine Ahnung ob hiervon was irgendwie helfen könnte:

https://www.petri.com/forums/forum/s...m-outbound-tcp

https://groups.google.com/forum/?_es...na/IlUATnAM7ek

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

https://www.wilderss<br /> curity.c...ce-afd.221765/

[EWeiss]

LOL mir gingen die Handles verloren und du hast mehr als genug davon.

gruss

[jaenicke]

Es gibt mit dem AFD zwar weniger Probleme als mit der AfD :cyclops: aber wenn, dann richtig. Zum Beispiel gab es mal einen Bug, aufgrund dessen bei der Wiederverwendung von Sockets Handle Leaks auftraten:
https://support.microsoft.com/en-us/...ed-together-wi
Windows 7 war davon aber offenbar nicht betroffen, ich selbst hatte das Problem mit Vista.

Die wichtigste Frage ist aber deshalb erst einmal:
Sind dort alle verfügbaren Windows-Updates eingespielt?

Die andere Frage:
Konntest du einmal stichprobenartig die Handleanzahl beobachten? Steigt diese im normalen Betrieb an oder bleibt diese da konstant? Wie ist es bei euch auf einer Testmaschine?
Sprich ist das Verhalten dort schon vor dieser großen Anzahl an Handles anders als bei euch im Test?

Packt ihr fertig vorkonfigurierte Images drauf, auf die ggf. nur noch die Software kommt oder wird danach noch alles eingerichtet?

[Der schöne Günther]

Zitat:

Zitat von nahpets (Beitrag 1379054)

würd' ich hier ein Problem in der "Netzwerkumgebung" und/oder im "Druckerumfeld" vermuten. Es scheint so, als würden nicht alle Verbindungen ordentlich arbeiten und/oder beendet werden.

Das tue ich auch, kann es aber nicht beweisen. Es gab von Anfang an wohl Probleme mit dem Einrichten eines Netzwerkdruckers vom Kunden, am Freitag habe ich das System auf einen lokalen Drucker zurücksetzen lassen, ich hoffe dass es seitdem keine Probleme mehr gab.

Zitat:

Zitat von jaenicke (Beitrag 1379057)

Die wichtigste Frage ist aber deshalb erst einmal:
Sind dort alle verfügbaren Windows-Updates eingespielt? (...) Packt ihr fertig vorkonfigurierte Images drauf, auf die ggf. nur noch die Software kommt oder wird danach noch alles eingerichtet?

Die Rechner kommen mit aktuellem Update-Stan von einem Drittanbieter, unsere Leute werfen dann nur noch ein Setup an und nehmen ggf. ein paar kleinere Anpassungen vor.

Zitat:

Zitat von jaenicke (Beitrag 1379057)

Konntest du einmal stichprobenartig die Handleanzahl beobachten? Steigt diese im normalen Betrieb an oder bleibt diese da konstant?

Die Anzahl bleibt, wie Speicherauslastung, absolut konstant.

[Luckie]

Eventuell vergessen im Fehlerfall noch offene Handles zu schließen? Try...except...end?

[Der schöne Günther]

Dann, denke ich, würde das bei allen Installation auftreten und höchstwahrscheinlich auch die Handle-Anzahl mit der Zeit kontinuierlich wachsen.

Ich werde zunächst irgendwie mal ein bisschen Logging einbauen was die Handle-Anzahl des eigenen Prozesses angeht, bei dem Kunden aktivieren und ansonsten denke ich darüber nach alle Druckvorgänge in einen eigenen Prozess auszulagern, den könnte man nach jedem Druck-Vorgang schließen...

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1379092)

Dann, denke ich, würde das bei allen Installation auftreten und höchstwahrscheinlich auch die Handle-Anzahl mit der Zeit kontinuierlich wachsen.

Nicht unbedingt.
Eventuell knallt es ja auch nur bei diesem Kunden,
dann würde eine falsche Fehlerbehandlung auch nur da zuschlagen.

[TiGü]

War denn 23 Stunden und 59 Minuten alles gut und schön und grüne Wiese mit Regenbogeneinhörnern mit Puschelschwänzchen UND DANN ging der Hades auf und verschlang alle Handles des Systems ODER stieg nur für dieses System kontinuierlich vom Start an im Laufe der Zeit die Anzahl der Handles?

Workaround Idee 1: Ist es praktikabel eure Anwendung alle XX Stunden automatisch neu zu starten?

Workaround Idee 2: Druckausgaben in PDF umleiten und die dann später zum Netzwerkdrucker schicken?

Idee von Luckie nochmal aufgreifen und alle Try-Handler angucken.
Irgendwo werden Handles im Fehlerfall nicht zu gemacht.
Wird der Fehler wirklich protokolliert?
Ggf. schluckt das einfach die RTL oder sonstige verbaute Internet-Komponenten und man bekommt nichts mit?

[himitsu]

Nur der Vollständigkeit halber:

Natürlicgh kann es sein, dass z.B. ein Usermdedriver des Druckers/Printsystems hier durchdreht und die Handles nicht im eigenen, sondern in fremden Code entstehen (dort nicht richtig freigegeben werden).
Mit einem anderem Programm drucken und da schauen, ob das Problemchen dort auch auftritt.



PS: Man kann die eigene Anwendung auch auf mehrere EXEn verteilen und das Ausdrucken in einem Subsystem erledigen, damit der Hauptprozess störungsfreier arbeiten kann.

[Der schöne Günther]

Zitat:

Zitat von TiGü (Beitrag 1379101)

War denn 23 Stunden und 59 Minuten alles gut

So ungefähr. Ich konnte keinen kontinuierlichen Anstieg beobachten. Ich konnte auch nicht ständig dort im Task-Manager wühlen oder in Ruhe den Windows-Performance-Monitor aufsetzen da Zugriff nur per TeamViewer und die Leute brauchen den Bildschirm zum arbeiten.

Zitat:

Zitat von TiGü (Beitrag 1379101)

Ist es praktikabel eure Anwendung alle XX Stunden automatisch neu zu starten?

Nein, das ist leider keine Option.

Zitat:

Zitat von TiGü (Beitrag 1379101)

Wird der Fehler wirklich protokolliert?
Ggf. schluckt das einfach die RTL oder sonstige verbaute Internet-Komponenten und man bekommt nichts mit?

Das Problem ist ja: Was ist "der Fehler"? Ich sehe nur die Auswirkungen: Hohe Handle-Anzahl im Task-Manager und im Exception-Log des Programms dass alle möglichen Operationen wie Dateien öffnen oder Netzwerk-Sockets mit NOT_ENOUGH_QUOTA fehlschlagen.

Zitat:

Zitat von himitsu (Beitrag 1379104)

Mit einem anderem Programm drucken und da schauen, ob das Problemchen dort auch auftritt.

Das werde ich unbedingt testen müssen. Und zwar nicht nur Notepad, sondern am besten gleich einmal ein komplettes Delphi-Druck-Test-Programm mit Vcl.Printers und FastReport.

[himitsu]

Etwas zum Loggen.
GetProcessHandleCount


Wir hatten auch ab und an mal Probleme mit irgendwelchen Ressourcen, in einem Service, beim Kunden.
Bei uns läuft daher im Hintergrund ein Thread, der regelmäßig danach schaut und das loggt. So können wir dann nachsehen wann in der letzten Woche sich dort was änderte.
> Speicher (HDD, System-Memory, VirtualMemory, DelphiMM-Allocation), Handles, Threads, CPU-Auslasung (Prozess und System), Status einiger Locks (CritialSections), ...

[Der schöne Günther]

Ja, genau solchen Kram einzubauen bin ich grade dran 8-)

Insbesondere den FastMM Usage Tracker.

[TiGü]

OT:
Das Schlimme ist, das bei solchen aufwendigen und zeitraubenden Fehlern die Ursache sich innerhalb von ein bis drei Zeilen Quelltext finden und fixen lässt.
Der Aufwand zur Fehlersuche und tatsächliche Fehlerbehebung stehen oft in einen krassen Missverhältnis.

[Der schöne Günther]

Oh ja. Aber noch viel schlimmer als diese drei Zeilen (die potentiell noch bei anderen Kunden zutreffen könnten) wäre die Tatsache wenn es sein beschissener Netzwerkdrucker ist den es nur bei ihm gibt :twisted:

[yogie]

Hallo,
mal ganz naiv ... steht das Problem ev. in Zusammenhang mit der 24 Stunden Angabe?
Oder ist die Aussage ... alles läuft 23 h 59 min problemlos ... mehr symbolisch zu verstehen.
Ich denke da an solche Sachen, wie Zeitumrechnung über einen 24 Std. Zeitraum hinweg und
dann entsprechende Überläufe und die vielen Handles sind dann nur ein Folgeproblemm.

[Der schöne Günther]

Gute Frage, aber das war wirklich nur rein symbolisch zu verstehen. Im ersten Fall weiß ich nicht wie lange es lief, im zweiten Fall waren es so um die 22 Stunden.

[TiGü]

Ach, wer hat nicht so Quelltextzeilen:

Delphi-Quellcode:

if Now > zufälligerWert then
  RasteKomplettAusUndBringeDasSystemZumAbsturz;

Die heißen natürlich in der Realität SendDocToNetworkPrinter, LoadDataFromDatabase, SaveApplicationSetting usw. usf.! :-D

[Der schöne Günther]

Erst einmal vielen Dank noch einmal für die Antworten.

So wie es mittlerweile aussieht ist nach dem Zurückstellen auf den von uns gelieferten Drucker das Wochenende über nichts mehr vorgefallen, alles lief bestens.

Naja, dafür loggt die Anwendung in der nächsten Version auch fleißig Dinge mit wie Handle-Anzahl, CPU/Speicher-Auslastung, Anzahl der IO-Vorgänge auf der Platte...

Hatte also auch sein Gutes 8-)

[TiGü]

Also lag es letztendlich an einen fehlerhaften Drucker(-treiber)?
Spannend und nur nice-to-have wäre natürlich, den fehlerhaften Drucker vom Kunden (leihweise) zu bekommen und in der Entwicklung testen zu können.
Eventuell kann man derartige Fehler-Szenarien auch im eignen Programmcode behandeln.
Aber das wäre auch nur was für ruhige Stunden.

[nahpets]

Zitat:

Zitat von TiGü (Beitrag 1379331)

Also lag es letztendlich an einen fehlerhaften Drucker(-treiber)?
Spannend und nur nice-to-have wäre natürlich, den fehlerhaften Drucker vom Kunden (leihweise) zu bekommen und in der Entwicklung testen zu können.
Eventuell kann man derartige Fehler-Szenarien auch im eignen Programmcode behandeln.
Aber das wäre auch nur was für ruhige Stunden.

Reicht es da nicht aus, nur den entsprechenden Treiber zu installieren?
Der Drucker selbst muss ja nicht angeschlossen sein. Den Treiber auswählen und die Druckaufträge im Spooler stehen lassen. Kann man dann dort ja später rausschmeißen.

Die grundsätzliche Funktion von Druckaufträgen hab' ich immer erstmal mit ausgeschaltetem Drucker entwickelt und getestet bzw. den Drucker am Entwicklungsrechner offline geschaltet.

Ein eventuell vorhandenes Fehlverhalten des Druckertreibers müsste aber eigentlich trotzdem auffallen.

[TiGü]

Zitat:

Zitat von nahpets (Beitrag 1379351)

Reicht es da nicht aus, nur den entsprechenden Treiber zu installieren?
Der Drucker selbst muss ja nicht angeschlossen sein. Den Treiber auswählen und die Druckaufträge im Spooler stehen lassen. Kann man dann dort ja später rausschmeißen.

Die grundsätzliche Funktion von Druckaufträgen hab' ich immer erstmal mit ausgeschaltetem Drucker entwickelt und getestet bzw. den Drucker am Entwicklungsrechner offline geschaltet.

Ein eventuell vorhandenes Fehlverhalten des Druckertreibers müsste aber eigentlich trotzdem auffallen.

Stimmt auch wieder.
Das wäre Schritt eins.
Wenn sich das Fehlverhalten damit aber nicht reproduzieren lässt, kommt man um eine vollständige Testkette nicht drum rum.

[mkinzler]

Zitat:

Ein eventuell vorhandenes Fehlverhalten des Druckertreibers müsste aber eigentlich trotzdem auffallen.

Nicht unbedingt, wenn das Fehlverhalten bei der Kommunikation mit dem Drucker entsteht

[Luckie]

Deutet das aber dann nicht auch auf eine unvollständige Fehlerbehandlung im Code hin?

[nahpets]

Um welchen Fehler handelt es sich in meinem Programm, wenn ein Druckertreiber Handles nicht freigibt?

Welche Chance der Fehlerbehebung habe ich denn dann?

Allenfalls kann ich doch nur das Problem feststellen und ggfls. warnen ... aber die Chance der Fehlerbehebung im eigenen Programm dürfte da doch eher gegen 0 tendieren. Oder irre ich da?

[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:

Zitat von Luckie (Beitrag 1379410)

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:

Zitat von Luckie (Beitrag 1379410)

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 :cyclops: