Delphi TOpenDialog hängt in windows 2008, wenn die Ausführung als remote-desktop-Anwendung

Ich habe ein Delphi 2010 exe-Datei, startet eine zweite exe-Datei. In der zweiten exe, es ist ein dialog, fordert openDialog.ausführen. Wenn diese läuft unter Windows 2008 Enterprise R2 unter einem remote-desktop, es läuft wie erwartet, aber bei der Ausführung als eine remote-Anwendung, sobald der Datei-dialog öffnet sich, reagiert die Anwendung, drehen Sie alle mit der Anwendung windows weiß. Der einzige Weg raus aus der es ist, um die Anwendung zu beenden. Ich habe versucht, ersetzen TOpenDialog mit TFileOpenDialog, die Ergebnisse sind die gleichen. Ich habe mir in ändern Sie die RDP-Datei, startet die Hauptanwendung, aber nicht sehen können, alle Parameter, es würde einen Unterschied machen. Hat jemand je gesehen, diese Art von Verhalten vor?

---

2010.07.13 Aktualisiert

Dies ist reproduzierbar mit einem einfachen Beispiel. Es gibt zwei ausführbare Dateien, die in dem Beispiel. Die erste ist eine Datei launcher, genannt m_module.exe enthält ein edit, ein button, und der code unten. Ich ändern Sie den Namen der ausführbaren Datei in dem edit-entsprechend der zweiten ausführbaren Datei, bevor ich Sie auf die starten-Taste:

procedure TForm1.Button1Click(Sender: TObject);
begin
     ShellExecute(Handle, 'open', stringToOLEstr(edit1.text) , nil, nil, SW_SHOWNORMAL) ; 
end;

procedure TForm1.FormShow(Sender: TObject);
begin
     edit1.text:=application.exename;
end;

Die zweite ausführbare Datei enthält eine Schaltfläche und den folgenden code:

procedure TForm1.Button1Click(Sender: TObject);
begin
     OpenDialog1.execute;
end;

Dem ersten Modul gestartet ist, aus einer RDP-Datei.

2010.07.14 Aktualisiert

Habe ich entdeckt, dass wenn ich kopieren Sie die folgenden dlls:

thumbcache.dll 
dtsh.dll 
wkscli.dll 

aus dem \Windows\System32 Ordner in den Programm-Ordner, das problem ist beseitigt.

Habe ich weiter entdeckt, dass die Eigentümer wechseln und die Berechtigungsstufen, die diese dlls in \Windows\System32 Ordner vom TrustedInstaller auf den Administrator-Gruppe hat das gleiche Ergebnis (Kopieren Sie das Verzeichnis der Anwendung ändert sich das Eigentum und die Erlaubnis glaube ich)

Um dies zu bestätigen, ich habe überprüft, dass der Fehler wieder aufgetaucht, wenn ich änderte die Eigentums-und Berechtigungsstufen wieder TrustedInstaller Weg von der Administrator-Gruppe.

So scheint es, dass dies ein access-Problem in irgendeiner Form. Vielleicht hilft bei der Entdeckung der Ursache des Problems.

2010.07.18 Aktualisiert

Einige zusätzliche Informationen, die hilfreich sein könnten (zur Verfügung gestellt von Embarcadero):

In diesem MSDN-Artikel für GetWindowsDirectory http://msdn.microsoft.com/en-us/library/ms724454%28VS.85%29.aspx Dokumente einige interessante Verhalten von Anwendungen unter Terminal Services. Während GetWindowsDirectory ist nicht direkt aufgerufen die Sandbox des Windows-System-Verzeichnis pro Benutzer verursachen könnten irgendeine Art von problem. Vielleicht eine der DLLs, die in der aufrufenden Kette an GetOpenFileNameA versucht Verweis auf die real-DLL in das Reale System Verzeichnis statt auf die Sandbox einer so verursacht eine Rechtsverletzung dar. Es ist nur Spekulation, aber es ist eine Untersuchung Wert. Wenn Sie waren in der Lage zu Holen Sie sich die SysInternals-Prozess Monitor oder Process Explorer auf dem server arbeiten, sollten Sie in der Lage, um zu sehen, commdlg32 und den anderen DLLs in dem stack-trace geladen werden.

Alle legacy-Anwendungen (d.h. alle Anwendungen, die Sie nicht geschaffen für Terminal Services oder Remote Desktop Services) laufen unter einem Application Compatibility Layer. Finden Sie in diesem MSDN-Artikel http://msdn.microsoft.com/en-us/library/cc834995%28VS.85%29.aspx . Die IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag ist definiert in Windows.PAS. Für Testzwecke können Sie es hinzufügen, um Ihre Anwendung PE-header durch das hinzufügen von Fenstern zu der Anwendung VERWENDET Abschnitt und direkt unter der USES-Abschnitt setzen:

{$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}

Dies bewirkt, dass Ihre Anwendung die bypass-Kompatibilität Schicht. Ich bin derzeit, wenn gespawnt Prozesse (z.B. Ihre zweite exe) behalten alle Rechte und Einstellungen in der Anwendung definiert, die unter RDS.