Hallo zusammen,

ich habe arbeite an einem Programm, das von verschiedenen Anlagen Messdaten holt und diese dann in eine Firebird Datenbank (Firebird 2.5.4) speichert. Bei einem Kunden der das Programm unter Windows Server 2012 R2 einsetzt habe ich jetzt folgendes Problem:

Mein Programm bleibt zyklisch ca. alle 11 Minuten für ca. 30 s stehen (keine Rückmeldung) und läuft dann wieder normal weiter. Dieses Verhalten konnte ich noch unter keinem anderen Betriebssystem feststellen. Der Kunde hatte vorher einen Windows 2008 R2 Server, auf dem dies nicht vor kam. Das Problem hängt auch nicht von der Abfrage einer bestimmten Anlage ab. Das einzige was ich bis jetzt finden konnte, sind bei jedem "keine Rückmeldung" 2 Einträge in der Ereignisanzeige - Sicherheit mit folgendem Inhalt:

Zitat:

Ein Konto wurde erfolgreich angemeldet. Antragsteller: Sicherheits-ID: SYSTEM Kontoname: WIN-GM6G58DAENC$ Kontodomäne: WORKGROUP Anmelde-ID: 0x3E7 Anmeldetyp: 5 Identitätswechselebene: Identitätswechsel Neue Anmeldung: Sicherheits-ID: SYSTEM Kontoname: SYSTEM Kontodomäne: NT-AUTORITÄT Anmelde-ID: 0x3E7 Anmelde-GUID: {00000000-0000-0000-0000-000000000000} Prozessinformationen: Prozess-ID: 0x1dc Prozessname: C:\Windows\System32\services.exe Netzwerkinformationen: Arbeitsstationsname: Quellnetzwerkadresse: - Quellport: - Detaillierte Authentifizierungsinformationen: Anmeldeprozess: Advapi Authentifizierungspaket: Negotiate Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die neue Anmeldung geben das Konto an, für das die Anmeldung erstellt wurde, d. h. das angemeldete Konto. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Das Feld "Identitätswechselebene" gibt an, in welchem Umfang ein Prozess in der Anmeldesitzung einen Identitätswechsel vornehmen kann. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die Anmelde-GUID ist ein eindeutiger Bezeichner, der verwendet werden kann, um dieses Ereignis mit einem KDC-Ereignis zu korrelieren. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.

Zitat:

Ein Konto wurde erfolgreich angemeldet. Antragsteller: Sicherheits-ID: SYSTEM Kontoname: WIN-GM6G58DAENC$ Kontodomäne: WORKGROUP Anmelde-ID: 0x3E7 Anmeldetyp: 5 Identitätswechselebene: Identitätswechsel Neue Anmeldung: Sicherheits-ID: SYSTEM Kontoname: SYSTEM Kontodomäne: NT-AUTORITÄT Anmelde-ID: 0x3E7 Anmelde-GUID: {00000000-0000-0000-0000-000000000000} Prozessinformationen: Prozess-ID: 0x1dc Prozessname: C:\Windows\System32\services.exe Netzwerkinformationen: Arbeitsstationsname: Quellnetzwerkadresse: - Quellport: - Detaillierte Authentifizierungsinformationen: Anmeldeprozess: Advapi Authentifizierungspaket: Negotiate Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die neue Anmeldung geben das Konto an, für das die Anmeldung erstellt wurde, d. h. das angemeldete Konto. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Das Feld "Identitätswechselebene" gibt an, in welchem Umfang ein Prozess in der Anmeldesitzung einen Identitätswechsel vornehmen kann. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die Anmelde-GUID ist ein eindeutiger Bezeichner, der verwendet werden kann, um dieses Ereignis mit einem KDC-Ereignis zu korrelieren. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.

Ich habe in meiner Software keinen Timer oder ähnliches, das mit diesem Intervall läuft. Debuggen beim Kunde ist leider im Moment auch nicht möglich. Ich habe schon kontrolliert, ob sich irgendwelche Threads gegenseitig blockieren und die Anwendung blockieren, konnte aber nichts in diese Richtung feststellen. Hat da jemand von Euch eine Idee ?

Vielen Dank schon mal im voraus.

Eurekalog hat die Möglichkeit das Hängen zu erkennen (kann man in den Optionen aktivieren) und ein Log zu schreiben. In dem Log stehen dann z.B. Stacktraces aller Threads zum Zeitpunkt des Hängers.
Es gibt auch eine Trial, mit der du testen könntest, ob diese Hänger erfasst werden, bevor du es kaufst.

Hallo jaenicke,

danke für den Tip, ich werd das mal versuchen.

Sieht auf den ersten Blick so aus, als ob dies beim Zugriffen auf ini-Dateien passiert.
Ich muss das heute noch mal genauer untersuchen.

Dateizugriff ? Das ist ja interessant...

Ich habe ein ähnliches Problem gehabt - eine von mir geschriebene Serveranwendung schreibt etliche Logfiles gleichzeitig (natürlich in einem eigenen Thread). Ab und an blieb diese Anwendung einfach hängen, die Warteschlangen für die Dateieinträge füllten sich rapide, Speicherverbrauch stieg an. Irgendwann funktioniert das Dateischreiben wieder, die Warteschlangen leerten sich - aber nicht ganz, dann hing das ganze wieder.

Nach ein paar Tagen waren die 16GB des Servers aufgebraucht und wir mußten das Programm neustarten. Ich habe dann nach ein paar Wochen herausgeknobelt, das es an den Logfilezugriffen liegt, konnte die exakte Ursache für diese Hänger aber nie herausfinden. Verzweiflungstat, weil einzige Lösung bisher: Logging abschalten und beten, das nix schiefgeht. Betriebssystem Win2008 Server und später Win2012 Server.

Kann es sein, dass du die Uralt-Routinen für den Ini-Zugriff benutzt? Sprich TIniFile? Das basiert auf den Routinen aus Windows 3.x Zeiten, die schon lange als veraltet markiert sind und nicht mehr verwendet werden sollten.
Eine Alternative ist die delphieigene Implementierung in TMemIniFile.

(In Delphi selbst kann Embarcadero das nicht so einfach umstellen, weil man dann die Bugs der Windows-Implementierung nachbauen müsste, damit es kompatibel ist... ich sage nur Handling von Anführungszeichen...)

Öhm... Zumindest mein XE4 sagt nix von wegen deprecated. Mit Einführung der Registry (Win95 IIRC) empfahl Microsoft dann, alles auf Registry umzustellen und INI-Files nicht mehr zu benutzen. mit Windows 2000 hat MS dann selbst zugegeben, das das mit der Registry einer der größten Fehler war, die sie je gemacht haben.

Aber gut zu wissen, das TMemIniFile eine "Neuimplementierung" ist, werds zukünftig nur noch nutzen.

OlafSt hat folgendes geschrieben :

Öhm... Zumindest mein XE4 sagt nix von wegen deprecated.

Leider... das ändert aber nichts daran, dass die dahinterliegenden API Funktionen wie WritePrivateProfileString den Hinweis enthalten: "This function is provided only for compatibility with 16-bit versions of Windows."
Ob die Funktionen tatsächlich einmal entfernt werden, weiß man nicht, die bestehenden Fehler werden jedenfalls nicht mehr behoben.

Ich verwende hier ini-Dateien, um Konfigurationsdaten von Anlagen zu speichern, die Zugriffe erfolgen über TMemIniFile.
Im Stacktrace von Eurekalog bin ich auf die Funktion "BaseIsAppCompatInfrastructureDisabled" gestoßen, ich hab dann mal mit den Kompatibilitätseinstellungen rumgespielt, das kurze Hängen des Programms kommt immer noch vor, jetzt gibt es aber keine Einträge mehr in der Ereignisanzeige.

Wenn da nichts Geheimes drin ist, kannst du ja das Log von einem solchen Hänger hier posten, vielleicht lässt sich dazu ja etwas sagen.
(Den Teil mit den Rechnerdaten usw. kannst du ja rauslöschen, es geht ja nur um den Teil mit den Stacktraces.)

Das Problem hat sich jetzt doch gelöst. Ich konnte mir das Problem direkt beim Kunden (in Polen) auf dem Server anschauen und mal eine Testversion mit Eureka ausführen. Der Kunde hat in der Software den Datenaustausch mit anderen Systemen über eine seperate Datenbank aktiviert. Eigentlich sollte er nach dem Abholen von Datensätzen einen Timestamp in einer Spalte setzen, tut er aber nicht. Die Software geht zyklisch hin und löscht die als abgeholt markierten Datensätze. Da keiner markiert ist sind in der Datenbank über verschiedene Tabellen verteilt in der Zwischenzeit ca. 8 Mio Datensätze angefallen. Das hängen des Hauptprogramms kommt dann an der Stelle, wenn versucht wird die Daten zu löschen "Delete from T_XXX where PROCESSED is not NULL". Die Spalte PROCESSED ist nicht indiziert, da eigentlich nicht sehr viel drin stehen kann, wenn natürlich die Daten als abgeholt gekennzeichnet werden. Das Ergebnis ist eine ewig dauernde Abfrage die mir das Programm blockiert.
Ich werd die Tabellen jetzt mal indizieren, das löschen in einen seperaten Thread verlagern (beides zur Vorbeugung) und noch mal mit dem Kunden über die Handhabung der Schnittstelle reden.

Trotzdem vielen Dank für Eure Hilfe, der Tip mit EurekaLog war echt super.

Witz komm raus: Auch mein Problem wurde heute gelöst.

Ursache war ein volllaufendes RichEdit. In dieses schrieb ich ab und zu ein paar Meldungen rein, damit der Benutzer (sofern er mal draufschaut) sieht, das das Programm noch lebt. Das TRichEdit hat ein Property MaxLength, das ich auf 32768 (ergo 32KB) eingestellt habe - aber das wird völlig ignoriert. Und so lief das Richedit irgendwann voll, fraß den Speicher GB-weise und lähmte somit die GUI - während die vielen Hintergrundthreads normal weiterliefen.

Die übliche Kürzungsroutine eingebaut (while RichEdit.Lines.Count > 2500 do RichEdit.Delete(0) und Ruhe sollte nun sein.

Dieses Problem tauch nur auf dieser Maschine auf, auf keiner anderen. Auf meinem eigenen Server läuft das ganze ohne Kürzungsroutine 5-6 Wochen, ohne den Speicher wegzufressen. Schon merkwürdig.