Absturz im Save / Open Dialog

[OlliWW]

Hallo Zusammen,

Wir haben in unserer Software momentan vermehrt Abstürze, wenn ein User einen Open oder Save Dialog öffnen möchte.

Diese Abstürze passieren nicht reproduzierbar und nur manchmal. Nach vielem debuggen und suchen habe ich festgestellt, dass dies etwas mit dem "InitialPath" zu tun haben könnte. Bei vielen Kunden hat es eine Verbesserung gebracht, wenn ich den InitialPath fest auf ein Verzeichnis gesetzt habe, von dem ich weiß dass es existiert. Das ist allerdings auch nur ein Workarround für etwas das meiner Meinung nach funktionieren sollte.

Lustigerweise ist mir eine andere Software die wir gekauft haben heute abgestrüzt, die offenbar a) mit Delphi programmiert ist und b) MadExcept nutzt. Anhand des CallStacks kann ich sehen, dass auch diese Software auf die gleiche Art und Weise beim öffnen des Dialogs abstürzt als auch unsere.

Weiß jemand zufällig ob der Open / Save Dialog buggy ist oder wie man das beheben kann?

Anbei mal ein Beispiel Callstack. Wie man sieht, sitzt der Fehler offenbar tief in VCL / Windows API.
".Start" ist der letzte Teil meines Source-Codes, dort wird das Execute vom Dialog aufgerufen.

Code:

77720196 +00e ntdll.dll                                                NtWaitForMultipleObjects
76f215f1 +0fa KERNELBASE.dll                                           WaitForMultipleObjectsEx
755f1a03 +089 kernel32.dll                                             WaitForMultipleObjectsEx
77710107 +02b ntdll.dll                                                KiUserCallbackDispatcher
75e6f5b7 +00e USER32.dll                                               WaitMessage
75e6ce85 +031 USER32.dll                                               DialogBoxIndirectParamAorW
75e6cc09 +016 USER32.dll                                               DialogBoxIndirectParamW
0066469f +3ab Prog.exe Vcl.Dialogs                                     TCustomFileDialog.Execute
00661451 +199 Prog.exe Vcl.Dialogs                                     TFileDialogWrapper.Execute
006620ae +0d6 Prog.exe Vcl.Dialogs                                     TOpenDialog.DoExecute
0066243b +00f Prog.exe Vcl.Dialogs                                     TSaveDialog.Execute
00660ad1 +035 Prog.exe Vcl.Dialogs                                     TCommonDialog.Execute
01152ee8 +160 Prog.exe gtFRXportIntf                           393 +16 TgtFRXport_Base.Start

Die Fehlermeldungen sind immer anders, der Callstack immer gleich:

Code:

Zugriffsverletzung bei Adresse 60561493 in Modul 'FunDisc.dll'. Ausführung von Adresse 60561493.

oder

Zugriffsverletzung bei Adresse 609412D0 in Modul 'msxml6.dll'. Ausführung von Adresse 609412D0.

Unsere Software wurde mit XE6 und Seattle 10 kompiliert, beide Versionen führen zu dem Verhalten.

[Sir Rufo]

Mit Delphi hat das nichts zu tun, sondern mit den installierten Explorer-Erweiterungen.

fundisc.dll

[Bernhard Geyer]

Das ist kein Fehler deiner Software sondern (fast immer) ein Fehler/Problem einer sogenannten Shell-Extension.
Wenn du nach "FunDisc.dll" suchst findest du z.B. https://social.technet.microsoft.com...w7itprogeneral mit Link auf einen Hotfix.

[OlliWW]

Wow das ging schnell.

Vielen Dank! :thumb:

[OlliWW]

Hallo Zusammen,

Ich hole diesen Thread noch mal nach oben.

Ich habe auf den betroffenen Kundensystemen nun den Hotfix aus dem Beitrag vom Technet installiert. Dieser hat allerdings keine Besserung gebracht. Mittlerweile taucht das Problem bei immer mehr Kunden auf. Ich vermute dass ein Windows Update etwas verändert hat, das dieses Verhalten nun vermehrt hervorruft.

Die Gemeinsamkeit ist der MS Windows 2008 R2 Server und dass es Kundensysteme sind, die diesen Server als Terminalserver nutzen.

Nach ein bisschen googlen bin ich auf dieses Flag gestoßen:

Delphi-Quellcode:

{$SetPEOptFlags  IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}

Ich habe mir im MSDN durchgelesen was dieses Flag macht und wann man es nicht einsetzen soll. Als ein Punkt wird dort aufgezählt, dass man keine INI Dateien verwenden darf. Ist damit gemeint, dass man generell keine Einstellungen in einer INI Datei verwenden darf? Mein Programm nutzt nämlich eine INI Datei im Programmverzeichnis um sich Einstellungen zu merken, die dann über TMemIni gelesen / geschrieben werden.

Beim Absturz wird übrigens jedes Mal eine andere DLL gemeldet:
- FunDisc
- msxml6
- tquery
- u.s.w.

MSDN Link:
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

[DeddyH]

Ich will mich nicht zu weit aus dem Fenster lehnen, aber ich vermute, dass Ini-Dateien nur dann Probleme machen, wenn man mit den nativen Win32-Funktionen wie WritePrivateProfileString u.a. darauf zugreift, was TIniFile tut. AFAIK ist TMemIniFile aber ein Delphi-Eigengewächs, das intern mit Stringlisten arbeitet, das könnte funktionieren, denn Inis sind ja auch nur Text.

[himitsu]

Wenn Microsoft das schreibt, dann meinen die garantiert ihre Windows-INI-API.
GetPrivateProfileString, also TIniFile

TMemIniFile bassiert auf einer TStringList.



https://msdn.microsoft.com/en-us/lib.../cc834995.aspx

Zitat:

legacy applications

Wenn man seine Anwendung dazu zählt, dann gibt es eh noch weitere Probleme. :angle:

[DeddyH]

Hab ich was anderes gesagt? :roll:

[himitsu]

Keine Ahnung, die Redbox meinte es gäbe noch keine Antworten, bzw. sie sagte nix. :stupid: