Delphi TOpenDialog подвешивает в окнах 2008, когда выполнено как приложение удаленного рабочего стола

У меня есть Delphi 2010 exe, который запускает второй exe. Во втором exe существует диалоговое окно, которое называет openDialog.execute. Когда это работает в соответствии с Windows 2008 Enterprise R2 под удаленным рабочим столом, он работает как ожидалось, но, когда выполнено как удаленное приложение, как только диалоговое окно файла открывается, приложение зависает, поворачивая все белые окна приложения. Единственный способ выйти из него состоит в том, чтобы завершить приложение. Я пытался заменить TOpenDialog TFileOpenDialog, результатами является то же. Я изучил изменение файла RDP, который запускает главное приложение, но не видьте параметры там, которые имели бы значение. Кто-либо когда-либо видел этот вид поведения прежде?

13.07.2010 Обновленный

Это - восстанавливаемое использование простого примера. В примере существует два исполняемых файла. Первым является средство запуска файла, названное m_module.exe, который содержит одно редактирование, одну кнопку и код ниже. Я меняю имя исполняемого файла в редактировании для соответствия второму исполняемому файлу, прежде чем я нажму кнопку запуска:

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;

Второй исполняемый файл содержит кнопку и код ниже:

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

Первый модуль запускается из файла RDP.

14.07.2010 Обновленный

Я обнаружил это, если я копирую следующий dlls:

thumbcache.dll 
dtsh.dll 
wkscli.dll 

от \Windows\System32 папки в папку приложения устраняется проблема.

Я далее обнаружил, что изменение владения и уровней разрешения этих dlls в \Windows\System32 папке от TrustedInstaller до группы Администратора имеет тот же результат (Копирование их к каталогу приложения изменяет владение и разрешение, я думаю),

Для подтверждения этого я проверил, что ошибки вновь появились, если я возвратил владение и уровни разрешения к TrustedInstaller далеко от группы Администратора.

Таким образом, кажется, что это - проблема доступа некоторого вида. Возможно, это поможет в обнаружении причины проблемы.

18.07.2010 Обновленный

Некоторая дополнительная информация, которая могла бы быть полезной (обеспеченный Причалом):

Эта статья MSDN для документов GetWindowsDirectory http://msdn.microsoft.com/en-us/library/ms724454%28VS.85%29.aspx некоторое интересное поведение приложений, работающих под Службами удаленных рабочих столов. В то время как GetWindowsDirectory не называют непосредственно, игра в песочнице каталога Windows System на пользователя могла вызывать своего рода проблему. Возможно, один из DLLs в цепочке вызова к GetOpenFileNameA пытается сослаться на реальный DLL в реальном каталоге System вместо поигравшего в песочнице, таким образом вызывающего нарушение прав. Это - просто предположение, но это стоит исследовать. Если бы Вы смогли получить Проводник Монитора или Процесса Процесса SysInternals, работающий над сервером, то необходимо смочь видеть commdlg32 и другой DLLs в загружаемом отслеживании стека.

Все унаследованные приложения (т.е. все приложения, не созданные для Служб удаленных рабочих столов или Служб удаленного рабочего стола) выполненный под Слоем Совместимости приложения. См. эту статью MSDN http://msdn.microsoft.com/en-us/library/cc834995%28VS.85%29.aspx. Флаг IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE определяется в Windows. ПЕРВЕНСТВО. Для тестирования можно добавить его к заголовку PE приложения путем добавления Windows к разделу USES приложения и прямо под помещенным разделом USES:

{$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}

Это заставит Ваше приложение обходить слой совместимости. Я в настоящее время занимаюсь расследованиями, если порожденные процессы (например, Ваш второй exe) сохраняют все права и настройки приложения, определенного под RDS.