Vypínání / padání HeO při ukládání či otevírání souborů

[tomas.koci]

V případě provozu Helios Orange přes terminálový server s Win 2008 R2 nastávají situace, kdy se Helios při použití standardních dialogových oken Windows pro otevření či uložení (Open, Save dialog) bez jakékoli hlášky sám ukončí / vypne / spadne. Např. uložení souboru z náhledu před tiskem, načtení souboru v Obecných importech, v dokumentech při funkcích Nový a Procházet apod.

Dle dosavadních znalostí problém souvisí s používáním 64-bitových Win 2008 R2 a týká se výhradně terminálového provozu. Doposud nevíme přesnou příčinu chyby, objevilo se pouze několik možných cest k řešení.

1) Podle pozorování problém působí jako by vznikal při operaci prvního načítání lokálních disků do terminálového provozu. Stává se, že na začátku terminálové relace Helios několikrát spadne, ale později zůstane spuštěný a Open / Save dialog již funguje.

2) Problém se také objevuje v kombinaci s Průzkumníkem Windows. Když je otevřen průzkumník, tak HEO spadne v okamžiku, kdy má pomocí windows okna přistupovat k souboru na disku (načtení souborů pro nástroje přizpůsobení, obecné importy apod.) Stačí zavřít průzkumníka a na druhý pokus to již projde.

3) Článek z jednoho fóra ukazuje, že se problém povedlo vyřešit po úpravě práv či zkopírování 3 knihoven Windows do adresáře s aplikací (s HeO).

http://stackoverflow.com/questions/3206010/delphi-topendialog-hangs-in-windows-2008-when-run-as-remote-desktop-application


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 under a remote desktop, it runs as expected, but when run as a remote application, as soon as the file dialog pops up, the application hangs, turning all of the application windows white.
...
I have discovered that if I copy the following dlls:
* thumbcache.dll
* dtsh.dll
* wkscli.dll
from the \Windows\System32 folder into the application folder, the problem is eliminated.
I've further discovered that changing ownership and permission levels of these dlls in the \Windows\System32 folder from TrustedInstaller to the Administrator's group has the same result (Copying them to the application directory is changing ownership and permission I think)
To confirm this, I verified that the errors reappeared if I changed the ownership and permission levels back to TrustedInstaller away from the Administrator's group.