Viewer control imploding...

[DSSavant]

This is a very elusive bug so be patient ...

My customer is running v197. They are experiencing an issue where the viewer will implode - the out of process viewer will die resulting in the viewer "plugin" icon being displayed within my form where the true viewer control should be shown. I'm using the most recent version of the product, v198, and have yet to reproduce it on my box.

A few things have occurred to bring this implosion about.

We had a bug reported that when loading a larger document the viewer would throw an RPC error. The command:

Viewer.DoVerb("Documents[#4102]", "IsOperationGranted", "System.Object[]", out dataOut, 0);

would throw:

The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

I was querying for the PDF permissions/security settings immediately after the command to open the PDF from a Stream. The basic reproduction steps where to load a PDF, annotate it, save it, close it, load a bigger PDF, boom. I got around this error by adding the following line immediately after the open:

Viewer.SetProperty("Performance.SyncRendering", "true", 0);

This caused the viewer to have to synchronize itself internally (guessing) such that it was in a "ready" state when it came time for me to query it for security settings.

Now I'm seeing instability elsewhere in the viewer. My current heartache deals with changing the Active Tool. I will initiate the command to change the tool, the viewer will do as instructed and send me an event indicating that the a tool has changed. I will query the viewer from within the event and ask which tool. All this is great. No exceptions, life is good. My thread will return back to the viewer's event notification call into me properly (no exceptions, no throws, etc.). The call to initiate the tool change then returns without error. My log files show no errors anywhere (and I log everything). The next thing that happens is that the out of process viewer implodes. If I call into it again, I will obviously get the RPC server is unavailable message. The only thing that is occurring at the user level at this time is mouse moves and possibly keyboard shift clicks.

You guys have a clue what might be happening? Have you made an update recently that would have fixed this (I have to justify updates to my SDK's as it impacts a whole lot of people and companies and computers). Has this ever been reported by other people?

If I could duplicate this and send you instructions I would but I can't. It is a hit or miss thing. Some people can reproduce it within ten minutes, some it takes hours. Me, ... never but then I don't have hours to try.

[Vasyl-Tracker Dev Team]

Hi, DSSavant.

Your code:

Viewer.DoVerb("Documents[#4102]", "IsOperationGranted", "System.Object[]", out dataOut, 0);

- is incorrect. The value for input parameter #3 is wrong. Correct example (C#):

Code: Select all

object dataIn = new object[2];
dataIn[0] = 1; // object identifier, 1 == "document"
dataIn[1] = 4; // operation identifier, 4 == "modify"
object dataOut = 0;
Viewer.DoVerb("Documents[#4102]", "IsOperationGranted", dataIn, out dataOut, 0);
bool isReadOnlyDoc = (dataOut != 1);

HTH.

[DSSavant]

Sorry, my very bad. The code snippets were from my log statements - I log what I can of the command I'm sending to the viewer control. In this case the "System.Object[]" represented datain being of type object array. I have double checked the code and it is in fact doing what you have suggested.

My actual datain is:

Code: Select all

object[] dataIn = { (int)objectType, (int)actionType };

I should point out that my code is working 98% of the time across a lot of machines. It is just once in a while when the viewer control just gets up and gives up the ghost so errors that would typically have the viewer fussing at me have been worked out of the system (I hope <grin>).

Any input you guys can supply is valued. Question, do you have a detailed bug fix list that may indicate any core work done on the viewer's engine or threading processes?

[Vasyl-Tracker Dev Team]

Hi, DSSavant.

Try to use special flag:

Viewer.DoDocumentVerb(docId, null, "IsOperationGranted", dataIn, out dataOut, PXCVA_Sync);

- may be it solve your problem..

WITHOUT the PXCVA_Sync flag the DoVerb/DoDocumentVerb will imitate the synchronous call by default: it will send the special request-packet to the COM-server and wait for result from this server with internal message-loop. The waiting with internal message-loop may cause some unobvious problems in difficult client applications - any windows-message (send-, post-, timer-), excepting mouse/keyboard message, can be processed during call-time of DoVerb/DoDocumentVerb. So, for example, possible scenario:

>> begin DoVerb("object", "operation", dataIn, out dataOut, 0); // without PXCVA_Sync
1. prepare and send the request-packet to the our COM-server
2. >> begin _InternalMessageLoop_
...
2.1. GetMessage and DispatchMessage()
--- in DispatchMessage() the system can send to your application any system event (windows-message), so in this moment your program takes control for itself and can run any other action
...
3. << end _InternalMessageLoop_
4. unpack result save it to dataOut parameter
<< end DoVerb

WITH PXCVA_Sync the DoVerb/DoDocumentVerb works without internal message-loop...

Question, do you have a detailed bug fix list that may indicate any core work done on the viewer's engine or threading processes?

As I understand, your problem is unspecific and is related to usage-scenario. History of bug-fixing is here (SDK/EU):
https://www.pdf-xchange.com/PDFXV_history.html

HTH.

[DSSavant]

My application has tons of threads that will transition to the UI thread as needed. I can see that I'm probably getting nailed right and left due to not using the PXCVA_Sync flag.

Can I assume that this flag is OK to use on just about every call I make?

[Vasyl-Tracker Dev Team]

You may use the PXCVA_Sync flag in ANY case, but note - when you call the:

DoDocumentVerb(docID, "", "Print", _in_, null, PXCVA_Sync);

- the our COM-server displays the modal Print Document dialog and waits (synchronously) for end-user. Our COM-server is a separate process.
The DoDocumentVerb/DoVerb(..., PXCVA_Sync) blocks the messages processing in your app during call-time, so, for example,
if you move our Print Document dialog over any UI-form from your app - your form not be redrawn (on XP and below) but will be repainted correctly after call-time.

[DSSavant]

I understand. Thank you.

[Paul - Tracker Supp]

[DSSavant]

I have used the PXCVA_Sync flag in just about every call I'm currently making as my product makes use of heavy thread-pool threading with UI thread transitions. I believe that this has removed a few instability issues I have experienced. One still remains though.

The basic flow is to load a PDF from a stream, select the pencil tool, draw, save to stream, unload. I can repeat this sequence 100 times successfully and on the 101'th once the tool is selected the viewer will implode.

Load stream.
Set the active tool.
--> View control will event that a new tool is now active.
-->--> My code will say thank you and cleanly return to the viewer's event.
--> Viewer will return from the set active tool command call successfully.
I will return out of that routine and return to my caller.
>>> Viewer implodes! My control which houses the viewer ActiveX control will now show the funky PDF Icon where the viewer should be.

Can I reproduce this? Not such that I can tell you how. Give me five minutes of repeating the steps above and I will break the viewer. If I'm lucky, it might be within the first five attempts.

Do you have any logging I can turn on? Debug build I can load? Something?

I've reproduced this on builds 196, 197, and 198.
------

I have updated my logging and have also increased mouse filtering to include all mouse events. What I now see is:

My toolbar "tool" button is clicked (I can't use your toolbars as they are not customizable enough):
:: PDFViewerControl.ProcessToolClick :: Tool Click - Key: PencilTool, Double Clicked? False, Control Key Down? False, Shift Key Down? False

I instruct the viewer to change tools. It in turn tells me (via events) that it is changing the tool:
:: PDFViewerControl._viewer_OnEvent :: Name: 'Tools.Active', Type: 'PXCVA_OnPropertyChanged', Flags: '0', DataIn: '', DataOut: ''

In the event handler I figure out the active tool and log it:
:: PDFViewerControl.ViewerOnToolActivationNotification :: Active Tool changed. Target: PencilTool, Name: Pencil, ID: 33129, Ignoring? False

I then log right before returning from the event handler:
:: PDFViewerControl._viewer_OnEvent :: Done processing event.

The viewer then returns back from being called to change the tool and I log before I return to the toolbar click code:
:: PDFViewerControl.ProcessToolClick :: Tool click processed.

The user then moves the mouse over the PDF view pane and the viewer notifies me of a mouse move:
:: PDFViewerControl._viewer_OnEvent :: Name: 'Notifications.Mouse', Type: 'PXCVA_OnNamedNotify', Flags: '0', DataIn: '', DataOut: ''

I then log right before returning from the event handler:
:: PDFViewerControl._viewer_OnEvent :: Done processing event.

The viewer then implodes and removes itself from memory (no longer shows up in the task list in task manager). The PDF Icon then shows up in my user control.

*****
The problem here is that I don't know what exactly I'm doing such that I'm causing the viewer to get in a state where it implodes. In a perfect world, I should not be able to do anything that would harm the viewer but ... I would be willing to take a debug build of yours if your developers desire and run it here to help you get debugging information -- whatever you guys need. As it is now, I get absolutely nothing when the viewer dies that can assist us in figuring out what is going on. Since my code will work 100 times without causing grief, I'm wondering if it something I'm doing or just the state of the viewer. If it is the state of the viewer then why will it blow at 101 sometimes and 3 others.

[Vasyl-Tracker Dev Team]

Hi, DSSavant.

Please give us the simple example (with source code) for reproducing this trouble. We still unable to reproduce it with our examples...
Thanks.

[DSSavant]

LOL. If it was that easy, I would have already given you a full project. As it is, if you have a good size server and client, I can give you an install of our product (that was a joke). The problem with using tools is that you weave them into your product such that you can't simply pull a piece out. I've been trying to reproduce this in a simple app but cannot thus the reason I'm asking if you have any diagnostics built into your viewer that you can enable. Any other ideas?

[DSSavant]

My QA department tested with 2.5.194 and it blows apart as well. Just FYI.

[Vasyl-Tracker Dev Team]

I think we can investigate and fix this problem by TeamViewer...
http://www.teamviewer.com/en/index.aspx

[DSSavant]

Another idea would be for me to install my product into a VM and send it to you. I'm not sure what you can do by remote controlling my box other than watch me play with the viewer for 1 to 5 minutes before it blows up. I'm OK with doing that though if you think it will help. With a VM on the other hand, you would be able to play with the product yourself and place a debugger on the viewer's COM server - you could debug it from your side. Alternatively, maybe I could get you a VPN into a server here so you can simply install our client on a box on your side and debug the viewer's COM server that way.

Please email me directly so we can discuss outside the forums.

[Vasyl-Tracker Dev Team]

Another idea would be for me to install my product into a VM and send it to you

Your idea is good. I sent you my email via PM.