Hallo, hoffentlich bin ich in diesem Unterforum richtig, denn ich bin mir selbst nicht sicher, was überhaupt der Fehler ist.
Meine Situation ist Folgende: Ich muss eine Anwendung warten (Delphi 7), die im Dateisystem regelmäßig in einem Ordner nach Änderungen schaut. Dabei werden haufenweise
WinApi Calls genutzt (also die ganze Dateisystemzugriff-Palette). Jetzt haben wir ab und zu mal das Problem, dass bei einem Kunden regelmäßig eine EOutOfResources Fehlermeldung hochkommt (er nutzt Windows 7). Im Windows-Event-Log sieht man dann Folgendes:
Name der fehlerhaften Anwendung: ***.exe, Version: 2.1.8.633, Zeitstempel: 0x2a425e19
Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 6.1.7601.24388, Zeitstempel: 0x5c873078
Ausnahmecode: 0x0eedfade
Fehleroffset: 0x0000c5af
ID des fehlerhaften Prozesses: 0x1fc4
Startzeit der fehlerhaften Anwendung: 0x01d4e8856e7ac6aa
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\***\***.exe
Pfad des fehlerhaften Moduls: C:\Windows\syswow64\KERNELBASE.dll
Berichtskennung: ac336f50-5478-11e9-81a3-028037ec0200
Der Fehlercode 0x0eedfade bedeutet ja im Grunde, dass die Aufrufende Anwendung eine Fehlermeldung in der
DLL erzeugt hat (oder so ähnlich) und die
DLL die nicht interpretieren kann. Allerdings kann ich leider nicht eingrenzen, welcher
WinApi-Call das jetzt auslöst, da die
Api-Calls für Dateisystemzugriffe ja alle an die kernel32.dll gehen. In meiner Anwendung hat auch jede einzelne Funktion und Prozedur einen großen try-catch-Block, der sämtlichen Code kapselt (historisch bedingt), allerdings greifen die auch nicht.
Ich gehe zwar nicht davon aus, dass jetzt irgendjemand eine Idee hat, was genau das Problem ist (da ich auch keinen Code schicken kann/darf). Aber vielleicht hat ja jemand eine Idee, was ich noch probieren könnte, um den Fehler genauer einzugrenzen.
Vielleicht dazu aber kurz den Ablauf der Prüfroutine:
1. Ein Timer feuert jede Sekunde das Prüfevent
2. Es wird geprüft, ob das zu prüfende Verzeichnis exisitert (DirectoryExists)
3. Es wird über alle Dateien und Ordner in dem Verzeichnis auf oberster Ebene iteriert (FindFirst und FindNext)
4. Es werden Dateiattribute geprüft und eventuell verändert
5. Am Ende wird aufgeräumt (FindClose)
Für die
Api-Calls wird nicht direkt die Delphi-Implementierung genutzt, sondern eine
Unicode-fähige Implementierung von TMS (kennt vielleicht der ein oder andere). Im Hintergrund rufen die allerdings auch nur die entsprechenden Wide-Varianten der
WinApi-Calls auf (hier wird der Fehler nicht liegen).
Bei früheren Kunden mit dem Problem konnte der Fehler "behoben" werden, indem das Windows-Benutzerprofil gelöscht und neu angelegt wurde (natürlich hatte der Systemadmin nie was an dem alten Profil geändert
). Allerdings ist das jetzt keine Lösung mehr, da unser Support den Fehler nachhaltig gelöst haben will ^^