CITRIX IPC messages HANG

[michel]

I have processes communicationg using SendIpcMessages(). They run in the same user session.
In Windows 7, Vista and XP they run fine regearless of the USE_NEW_IPC_LOGIC option.
In XP + CITRIX:
a/ If SetMadCHookOption USE_NEW_IPC_LOGIC is not set (usage of the default setttings): SendIpcMessages() returns FALSE.
b/ If SetMadCHookOption USE_NEW_IPC_LOGIC is set: SendIpcMessages() freeze (it never returns)
I have traces of the two processes showing that the quesues are correctly created. The Citix traces are the same as the normal traces for queues creation.
How to communicate in XP + Citrix?
I don't know if Citrix Windows 7 and Vista communications are working because I don't have Citrix and the tests are done by one of our clients.

[madshi]

Did you use USE_NEW_IPC_LOGIC both before calling CreateIpcQueue and before calling SendIpcMessage?

Unfortunately I don't have Citrix, either, so I've no way to debug this...

[michel]

Seem strange to have to call a global function setting some global bits before each other function call. If this is mandatory the option must be a parameter in all of the MadCHook functions.
I call SetMadCHookOption(USE_NEW_IPC_LOGIC) one time after the library initialisation.
The problem is not a 'general' functions options and functions call but a CITRIX XP only one. The non CITRIX XP application run fine with or without calling SetMadCHookOption(USE_NEW_IPC_LOGIC).
I'll make a new build and ask (the support to ask) our client to test it.
How can we debug the CITRIX + XP IOC problem?

[madshi]

You don't have to call that option before every function call. But you need to call it in every process which uses the IPC functions, before using the IPC functions the first time. Usually CreateIpcQueue and SendIpcMessage are called in two different processes. That's why I said you need to activate USE_NEW_IPC_LOGIC before both CreateIpcQueue and SendIpcMessage. Maybe I should have better said: You need to activate USE_NEW_IPC_LOGIC in every process which uses the IPC functions, before calling the first IPC related function. Of course you need to activate USE_NEW_IPC_LOGIC only once per process.

If everything runs fine with USE_NEW_IPC_LOGIC on a non-citrix PC then there's no need to create a new build.

I don't know how to debug Citrix without having access to it. I guess the only way to fix this is to either have Citrix fix the problem on their side, or us getting access to a Citrix installation somehow.

[michel]

Thanks for the answer.
I confirm that I call SetMadCHookOption after the Madshi library initialization in each of my 4 processes using IPC (injected DLL, service processing the injection callback, broker and Acrobat plug-in) and that everything run well on any OS on non Citrix PC including on Oracle VM VirtualBox PC.
I have asked (our conmpany to ask) for a user account onto our client Citrix server. I have to wait (Californian time or perhaps Mumbai time!).

[michel]

I'm able to repoduce the problem without Citrix when I do a Remote Login.
Configuration (on my dev 64bit machine):
- Oracle VirtualBox with XP 32 bits + Acrobat Reader 11 + our applications installed and running.
- When I login into virtual XP the IPC works fine.
- When I do a Remote Login into the virtual XP the IPC don't work.
It appears that in the Remote Login the Windows session returned by WTSGetActiveConsoleSessionId() and the MadCHook session returned by GetCurrentSessionId() are differnet (they are identical in the XP login).
Whe I'm remote logged the IPC works fine between the plug-in (an Acrobat Reader dll) and the Service (automatically started during the boot) but that if fails between the plug-in and the Broker (user application automatically started in the user autostart programs).
I don't know how you are implementing the IPC so I don't know if this may help.

[madshi]

I'm not sure if I already asked this in the other thread (why did you create a new thread? that makes things more complicated!).

Do you use add a session number to the IPC name? If so, are you sure that the numbers match between your broker and the plugin? Or are you not using session numbers?

Please check with the SysInternals Process Explorer which "port" names you have in both processes (those which fail to communicate). You'll find those in the list of handles. You should find a port there which contains the name of your IPC queue, if you use USE_NEW_IPC_LOGIC.

[michel]

I've opend another thread called 'IPC called from Acrobat Reader in Citrix fails' but you don't answer to the last posts that's why I open this one.
The names of the IPC was the first thng I verified. The plug-in <==> brother are the same for the same user during the same session (FileOpenBrokerListenPipe0 in XP and FileOpenBrokerListenPipe3 in Remote Login).

I'll check the 'port' names with PE (which is my 'standard' process explorar program: I use it to chek the injection).

[madshi]

I didn't reply in the other thread because you wrote there: "I'll send a test version with SetMadCHookOption() and I'll let you know their answer" and I was waiting for you to let me know their answer.