Delphi TOpenDialog hangs in windows 2008 when run as remote desktop application

Question

I have a Delphi 2010 exe that launches a second exe. In the second exe, there is a dialog that calls openDialog.execute. When this runs under Windows 2008 Enterprise R2 un

Answer 1

We were having problems on the OpenDialog.Execute but only on one computer - and it seemed to be random I found that adding the exe the Windows DEP may resolve the problem we haven't had any issues since changing it

here is the link on how to change the windows DEP settings http://www.itechtalk.com/thread3591.html

this is a workaround - if anyone knows how to keep the DEP happy please add a comment below

Answer 2

I recommend you to use Process Explorer tool to view properties of your process. Check, which exactly DLLs are loaded in both cases (you can do it by selecting your process and opening lower pane in modules view).

You can also use Process Monitor tool to monitor process startup (again: in both cases) and see any references to DLLs in question.

Answer 3

Windows reports AV (c0000005) in thumbcache.dll module.

I think that thumbcache.dll have something to do with building/caching thumbnails for files. Building thumbnails may mean using 3rd party extensions to Explorer, which may not behave nicely with RDP.

Try that on clean system. Use VMWare or similar virtual machine to setup test configuration.

P.S. See also this article: How to debug application’s hang? But I think that hang is just consequence of another problem in your case.

Answer 4

FWIW, we have a similar situation, but it's driven by a security need, and not a crash. When our app runs via Citrix, we are forbidden to ever show the regular windows "open" or "save as" dialogs. So we rolled our own. It's got a combo of drive letters (local drives only), folder selector (restricted to the approved drives), filename selector, and filename edit box.

For us, this gets around any active directory issues, and keeps security happy. And it keeps the users from trying to drop files into our filesystem or see things they shouldn't.

If they're not running in the sandbox, we show the regular windows file dialogs. A wrapper function allows us to call it from anywhere and leave the "sandboxed vs windows" decision in one spot.

Answer 5

You seems to have narrowed your problem to an access issue of some kind, so the following explanation might not help you. But there seems to exist a problem with popup windows on RemoteApp and I could imagine that it could lead (at least theoretically) to a similar problem, that's why I would like to mention it: http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/0a88919f-2d72-4340-abd7-fbe0e9545f25/

Apparently the Z-order of the windows isn't always correct when using RemoteApp. In your case TOpenDialog should be a modal popup window. Due to the bug, I could imagine that TOpenDialog could appear in the background. Your main window would remain in the foreground but would be disabled as TOpenDialog is modal. Windows might then not know how to redraw a disabled window and simply draw a white box.

Answer 6

It the Z-order is incorrect (which I often see in Citrix, without having a proper fix to it) you would still be able to close the form with ctrl-F4 or alt-f4. Furthermore the application would not be "not responding". Sometimes the order will correct itself when switching between tasks