Issue With Deployment via VMWare ThinApp

[aitchisj]

Hi There,

My company has been using the PDF XChange Viewer SDK as an embedded control within our product for the past few years with great success. Our program is a win32 fat-client application developed in PowerBuilder, but has been successfully deployed in environments such as Citrix without issue.

In attempting to deploy it using "VMWare ThinApp" we have run into a troubling problem. It is possible within our application to have multiple instances of the PDF XChange Viewer ActiveX control open simultaneously through different screens; however, what we are finding is that in the VMWare ThinApp environment, opening a second instance will consistently crash. Making calls to the ActiveX functions will cause an exception to occur from our application -- it is unable to call the functions. If we only have one instance open at any given time, everything is fine. We have not had this problem in any other environment in which we've deployed our software.

In troubleshooting the issue to narrow down where things are going wrong, we tried bundling one of your example applications that came with the SDK to see how it would behave.

The one we tried is PDF-XChange Viewer SDK\Bin\AX_C#Examples\OpenDocument.exe

The first instance opens fine as expected but the second instance has the exact same problem as we were finding with our own software, where an error occurs when the C# code tries to interact with the ActiveX control. To me, this helps to eliminate PowerBuilder as a potential culprit on the issue.

We also tried a different test with a separate ActiveX control that we have to see if it could open more than 1 instance simultaneously and we did not have any problem with it.

The version of the ActiveX control we have is somewhat out of date (v.204) because we haven't had a need to upgrade it, so we also tried grabbing the latest version (v.309) to see if that made any difference, which it did not.

We had a VMWare engineer also look at the problem but they were unable to diagnose anything wrong with the configuration of their own software that would cause this problem to occur.

One of the files that is required for distribution is PDFXCview.exe. When opening this application, it behaves just like your end-user product. Interestingly, we found that we could open multiple instances of this program in the VMWare ThinApp environment and it would work just fine. I do not know what is fundamentally different about this particular EXE needed for distribution versus embedding the control as an ActiveX object, but this seems like a good clue.

Do you have any insights as to what may be going wrong that is causing this to happen? This is a serious problem for us right now, so any suggestions or help you can provide is very much appreciated!

Thanks for your time,
-John

[Ivan - Tracker Software]

Viewer ActiveX SDK consists from two components: PDFXCview.exe - EXE COM server (yes, it is the same executable as end user viewer), and PDFXCviewAx.dll - a DLL that contains an ActiveX control that bypasses calls to EXE COM server.
It looks like the second instance of ActiveX cannot instantiate objects from the EXE COM server, but for now I cannot say why it might happen.

We have our suspicions as to what may be happening and we'd like to create a debug build of the ActiveX DLL for you to capture some additional debug data that will hopefully point us in the right direction.

Would that be something you want to do?

[aitchisj]

Thanks for the prompt reply.

Yes please! We are looking to resolve this issue as soon as we can, so if you can create a DEBUG build to help diagnose the problem, we would be more than happy to give it a try.

Thanks,
-John

[Paul - Tracker Supp]

Hi John,

OK - we will make the debug DLL. We won't post it on the forum. Can I email you a link when it's ready to the email associated with this forum account?

regards

[aitchisj]

Yes, that would be perfect.

Being that it's Thanksgiving weekend, there's a chance I might not be able to deploy it until Tuesday, as I do not have access to the ThinApp environment, but I will speak with my team about potentially getting access if you are able to get me a debug DLL sooner.

Thanks, I Really appreciate your help,
-John

[aitchisj]

Hello,

May I please ask approximately when I might expect to receive the debug DLL? We want to plan around this busy weekend if at all possible.

Happy Thanksgiving, by the way!
John

[Tracker Supp-Stefan]

Hello John,

I will ask Ivan to send it to you as soon as he manages to prepare it.
Is the e-mail from your forum signature the one we should use?

Thanks,
Stefan

[aitchisj]

Hello,

I just checked the Forum Settings - the e-mail address associated with my forum user account (the one I get notifications to when you reply on this thread, for example) would be perfect to send to.

Thanks guys, looking forward to figuring this out.
-John

[Tracker Supp-Stefan]

Thanks John,

We will use that one then!
But it's a public holiday in Canada today - so my colleagues might not work (or work from home) so the debug .dlls might be sent to you a bit later.

Regards,
Stefan

[Paul - Tracker Supp]

Hi John,

the guys are working on this right now. We should have it for you today.

hth

[aitchisj]

Thanks for the update, Paul. I am waiting eagerly, but patiently.

[Paul - Tracker Supp]

No worries John,

as soon as it is ready I'll both post here and email you.

regards

[Paul - Tracker Supp]

Hi John,

the debug DLL download link and instructions have been sent to your email.

[Ivan - Tracker Software]

Yes, as I supposed, the issue is because call to ::CoCreateInstance returns an error 0x80040154 (Class not registered)
For now I do not know why it may happen and how to workarround that.

[aitchisj]

Hello Ivan;

Thanks for your feedback and effort in helping to diagnose what may be happening. Is there anything else we can do to take this to a next step? Do you suppose it's a problem with the ActiveX control and associated COM Server, or a problem with the VMWare ThinApp environment that is causing this to happen?

This will be a troubling setback if we are unable to resolve this soon, so any further suggestions or recommendations are greatly appreciated.

Thanks again,
-John

[Vasyl-Tracker Dev Team]

Hi, John.

We don't known exactly what is happening. For now it looks like that the VMWare ThinApp environment causing this.
May be it blocks the using of our external COM-server(PDFXCview.exe, CLSID:FA8A2DAF-0603-4D2C-AB34-FAB373B571DC) by second instance of test-application.

I just found it:

https://communities.vmware.com/message/2367887

- for the similar problem in the last post support suggested "...try playing around with the ThinApp parameters, ExternalCOMObjects and SandboxCOMObjects". I looked to their reference(http://www.vmware.com/pdf/thinapp50_pac ... erence.pdf) and found it:
ExternalCOMObjects
SandboxCOMObjects
VirtualizeExternalOutOfProcessCOM

but I'm not a ThinApp-expert...

HTH.

[aitchisj]

Hi Vasyl,

Thanks for the information - we will investigate it and let you know how it works out.

Much appreciated!
-John

[Tracker Supp-Stefan]

Glad we can help John!

Looking forward to your feedback.

Regards,
Stefan

[aitchisj]

Hi,

I apologize for the lengthy delay in providing feedback on this item. The customer whom we were working with on this problem ended up having to seek alternative solutions for deployment, based not only on this problem, but other issues with VMWare ThinApp.

One of the last communications I received about this suggested that VMWare was able to provide a hot fix to get around the problem which worked in "test" but not in "production". Long story short, I think we can say with a high degree of certainty that the problem was rooted within the VMWare ThinApp environment and nothing to do with the PDF XChange Viewer ActiveX control.

I wanted to close the loop on this item since I knew it was still hanging out there.
Thanks a lot for the help along the way.

Sincerely,
-John

[Paul - Tracker Supp]

Thanks for the update John, most appreciated.