SOLVED: Citrix Published App staying in Foreground (Adobe InCopy)

disclaimer: this is not an official solution and probably not even legal. this blogpost is for educational purposes only!

if you are working with Citrix products, you might have been requested to install Adobe CC software on your image already. this is not a problem when we are using VDI, but with RDS or XenApp this is a little bit trickier.

you can google this topic and will find out, that Adobe does not support installations on RDS or XenApp. but there might be use cases where you still want to do it. in the past i even had to modify the installer, because it refused to run on Server OS, but the newest versions install just fine. Adobe CC runs good on XenApp, but of course it requires a lot of resources.

this post is about an issue i saw recently after a migration to 7.15. especially with InCopy 2018 when using it as a published App: you can open as much published Apps as you want, but if you start InCopy as your last App, it will not allow other Windows come to the foreground. it does somehow block other windows come to the top and only the ALT key will change that behaviour. we also found out, that it will release the foreground lock after you click around and perform certain actions. but for the enduser this is quite annoying.

the same issue does not happen in a full desktop session and also doesnt happen on a 6.5 farm with the same Adobe version. RDP initial app also doesnt show this problem and probably RemoteApp neither (didnt test that). Seamless Flags or disabling hooks didnt help at all and because of that we even opened a Citrix case.

Citrix did a good job on analyzing the issue and reported following to us:

ERROR: ForceToForeground: Error: Unable to set window 0x10094 as the foreground window.

Citrix suspected following: Adobe InCopy application calls LockSetForegroundWindow API to prevent background process from changing foreground window.

Citrix twi3.dll is trying to call SetForegroundWindow() but the application does not allow it, because it used LockSetForegroundWindow().

they closed the case and told us to get in contact with Adobe, but since they dont support Adobe CC on RDS, we probably wouldnt get help from them anyway. the reverse engineer in me woke up and i checked the Adobe binaries for this API – to confirm what Citrix suspected. with UltraEdit you can search through files and thats what i did. this API is indeed used and was found only in one DLL.

using IDA Pro i checked this DLL (PlugPlugOwl.dll) for LockSetForegroundWindow() and its references (you can find it in the Imports tab).

we have here two references to this API. IDA shows them four time, but in fact its only called twice. from the Microsoft documentation, we can also learn, that this function only takes one argument.

if we now can spot a LockSetForegroundWindow() call with LSFW_LOCK we might have found the culprit!

and yes – in IDA we can find only one call to this API with the LSFW_LOCK parameter. lets patch this! if we change the parameter to 2 instead 1, it will always send a LSFW_UNLOCK and therefore never block the SetForeground() API.

with a hex editor we can jump to 0xBE3B5 (file offset from IDA) and locate the instructions for mov ecx, 1 (B9 01 00 00 00) – and now we just change it to B9 02 00 00 00 (mov ecx, 2).

and here is the file compare:

above you can see the simple patch. only 1 byte and after testing we can see that the issue is GONE! no more foreground lock from Adobe!

another disclaimer: dont do this. Adobe will not support it and this breaks the EULA.

but if you kept reading until here, you probably have learned something new and thats why im sharing it 🙂 cheers!

Be the first to comment

Leave a Reply