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!


  1. Hi Christoph – Thank you very much for this blog post. You’re the only one who posted anything about this! Glad you were able to resolve it. Me? Not so lucky. I’m having the same issue with Citrix (on a windows 2016 server), but with InCopy CC2019. Unfortunately the same parameters don’t exist in the same dll’s. (at least I haven’t found them yet in others). Wondering if you have any experience with 2019 at all? PS: It works fine on Windows 2012 with InCopy 2015, which is my current production environment.

    • when i tested with InCopy 2019, i didnt see the same behaviour. can you maybe give more information about how to reproduce the issue? LockSetForegroundWindow is indeed not present in the 2019 binaries and therefore i dont think its the same issue…

  2. How to reproduce it? I just run the published application and get the problem. If I am logged on to the server, and then run the published app, it works fine. Also works fine running published desktop, or on the server itself. I have tried reinstalling Adobe under “Install” mode, same results.

    I have also found the PDApp.log which has tons of entries like this:
    -No Record found for the input fields in opm_getValueForKey
    -Failed in getting value for key in OPMGetValueForKey domain:IMSLib subDomain:CSServiceMap key:ProjectCentral16
    -Failed in fetching default user id for the service, while processing fetchDefaultUserGUIDForClientID
    -Failed to get default user for clientId in fetchDefaultUserInfoForClientId…

    Adobe has so far ignored my requests to explain what these errors have to do with my issues, but they were from attempting to login to Adobe with our Enterprise Account.

    I’m starting to wonder if there is a security setting on Windows 2016 blocking the proper behavior of Citrix.

    • i think adobe does not officially support CS products on Server OS. but are you having the same issue that i posted on my blog? are you using PVS? which VDA version have you installed and which Citrix Receiver/Workspace?

  3. According to my citrix admin we are not using PVS and we installed 7.15CU4.

    And thanks for helping with this. Very frustrating to figure this out. I think I’m going to end up publishing a whole desktop as my solution, since the single published app doesn’t work.


Leave a Reply