Delphi TOpenDialog зависает в Windows 2008 при запуске в качестве приложения для удаленного рабочего стола

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

2010.07.13 Обновлено

Это можно воспроизвести, используя простой пример. В примере есть два исполняемых файла. Первый - это пусковая программа, называемая 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.

2010.07.14 Обновлено

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

thumbcache.dll 
dtsh.dll 
wkscli.dll

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

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

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

Итак, похоже, что это проблема доступа. Возможно, это поможет обнаружить причину проблемы.

2010.07.18 Обновлено

Дополнительная информация, которая может быть полезной (предоставляется Embarcadero):

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

Все устаревшие приложения (т.е. все приложения, не созданные для служб терминалов или служб удаленных рабочих столов) работают под уровнем совместимости приложений. См. Статью MSDN http://msdn.microsoft.com/en-us/library/cc834995%28VS.85%29.aspx. Флаг IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE определен в Windows.PAS. В целях тестирования вы можете добавить его в свой PE файл приложения, добавив Windows в раздел USES вашего приложения и прямо в разделе USES:

{$ SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}

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

6 ответов

Отчеты Windows AV (c0000005) в модуле thumbcache.dll.

Я думаю, что thumbcache.dll имеет какое-то отношение к созданию/кешированию эскизов для файлов. Создание миниатюр может означать использование сторонних расширений для Explorer, что может не очень хорошо вести себя с RDP.

Попробуйте это на чистой системе. Используйте VMWare или аналогичную виртуальную машину для настройки конфигурации тестирования.

P.S. См. Также эту статью: Как отлаживать приложения зависают? Но я думаю, что зависание является следствием другой проблемы в вашем случае.


FWIW, мы имеем аналогичную ситуацию, но это обусловлено необходимостью безопасности, а не сбой. Когда наше приложение работает через Citrix, нам запрещается показывать обычные окна "открывать" или "сохранять как" диалоги. Таким образом, мы катались сами. Он получил комбинацию букв дисков (только локальные диски), селектор папок (ограниченный одобренными дисками), селектор имен файлов и поле редактирования имени файла.

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

Если они не запущены в песочнице, мы показываем обычные диалоговые окна файлов Windows. Функция-оболочка позволяет нам вызывать ее из любого места и оставлять решение "песочницы против окон" в одном месте.


Неправильный Z-порядок (который я часто вижу в Citrix, без правильного исправления), вы все равно сможете закрыть форму ctrl-F4 или alt-f4. Кроме того, приложение не будет "не отвечать". Иногда порядок корректируется при переключении между задачами


Я рекомендую вам использовать инструмент Process Explorer для просмотра свойств вашего процесса. Проверьте, какие именно DLL загружаются в обоих случаях (вы можете сделать это, выбрав свой процесс и открыв нижнюю панель в виде модулей).

Вы также можете использовать Process Monitor для отслеживания запуска процесса (опять же: в обоих случаях) и посмотреть ссылки на соответствующие DLL файлы.


Вы, кажется, сузили свою проблему до какой-то проблемы доступа, поэтому следующее объяснение может вам не помочь. Но, похоже, существует проблема с всплывающими окнами на RemoteApp, и я мог предположить, что это может привести (по крайней мере теоретически) к аналогичной проблеме, поэтому я хотел бы упомянуть об этом: http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/0a88919f-2d72-4340-abd7-fbe0e9545f25/

По-видимому, Z-порядок окон не всегда корректен при использовании RemoteApp. В вашем случае TOpenDialog должен быть модальным всплывающим окном. Из-за ошибки я мог представить, что TOpenDialog может появиться в фоновом режиме. Ваше главное окно останется на переднем плане, но будет отключено, так как TOpenDialog является модальным. Windows может тогда не знать, как перерисовать отключенное окно и просто нарисовать белый ящик.


У нас были проблемы с OpenDialog.Execute, но только на одном компьютере - и это казалось случайным Я обнаружил, что добавление exe в Windows DEP может решить проблему у нас не было никаких проблем с момента его изменения.

вот ссылка о том, как изменить настройки окна DEP http://www.itechtalk.com/thread3591.html

Это обходное решение - если кто-то знает, как сохранить DEP happy, пожалуйста, добавьте комментарий ниже

licensed under cc by-sa 3.0 with attribution.