Windows freezes

[cew]

Hi,

we currently have a big problem with PDFXCview.exe/PDFXCviewAx.dll version 2.5.316.1 used in a WinForms application running Windows 8 / Windows 7 (64bit).

If the viewer is visible and the application window gets resized, windows “freezes” and the only possible way to exit this situation is to do a hard reset to the computer.

This issue has something to do with refreshing the UI. Because refreshes, caused by the application itself or moving the mouse pointer out the computer using MousWithoutBorders (Microsoft) also lead to that situation.

Version 2.5.213.1 does not have this problem, but it had other problems that made it necessary to switch to 2.5.313.1. This version has the same problem as 2.5.316.1.

Please help!!

Best regards,
cew

[Vasyl-Tracker Dev Team]

Hi, cew.

Please check if parent window of our AcriveX Control has the WS_CLIPCHILDREN flag in style. If not - please add it. It may solve your problem...

HTH.

[cew]

Hi Vasyl!

Please check if parent window of our AcriveX Control has the WS_CLIPCHILDREN flag in style. If not - please add it. It may solve your problem...
HTH.

Sorry, but this does not solve the problem

What could be the reason that the 2.5.213.1 does not have this problem?

best regards,
cew

[Vasyl-Tracker Dev Team]

Unfortunately, but we cannot reproduce any problem in our WinForm test project. Can you provide simple example project for reproducing the issue?

Thanks.

[cew]

Hi Vasyl,

Unfortunately, but we cannot reproduce any problem in our WinForm test project. Can you provide simple example project for reproducing the issue?
Thanks.

I investigated the problem and found a scenario to reproduce the bug:

I created a new form with just a user control ucViewer (containing the activeX viewer control).
In the ucViewer_Load eventhandler, load settings to the contained activeX control.
The maschine freezes.

Encapsulating the LoadSettings solved this problem:

Code: Select all

        var sync = SynchronizationContext.Current;
        sync.Post((object oo) => {
          ucViewer.LoadSettings(filename);
        }, null);
        

Something must be changed from 2.5.213.1 to 2.5.313.1 that produces this problem. I'm sure, that MS updates are also involved in this issue, because we didn't have this problem last week and the 2.5.213.1 is still running well, but has other problems.

We detected another situation, where the bug appears.
We have a form containing a listview. Each listitem represents a document.
Loading the form will automatically select the first listitem.
This causes the viewer to load the related document and it hangs....

Doing the selection of the first item by code in a Post-action solves this issue.


Please contact your developers and try to find out what the real problem is.
It would take us a very long time to test each possible click in our application to find other situations, where the viewer freezes the machine.


Please help!

Best regrads,
cew

[cew]

Hi Vasyl,

another BIG customer has also strange problems in another application.
This one is a WPF application.

In the stacktrace, the last line is

Code: Select all

System.Runtime.InteropServices.COMException (0x82140002): Ausnahme von HRESULT: 0x82140002
   bei PDFXCviewAxLib.IPDFXCview2.LoadSettings(Object DataIn)

It is very important to get a solution for these problems as soon as possible because the software runs in a productive environment.

Best regards,
cew

[Lzcat - Tracker Supp]

Hi.
0x82140002 - this error mean "File not found". Since you get this error from LoadSettings all we can assume that you have passed invalid path to settings file (please note that relative path can be valid or not depending on current folder, so it is recommended to use full path only). If not - we will need much more details.
HTH.

[cew]

Hi.
0x82140002 - this error mean "File not found". Since you get this error from LoadSettings all we can assume that you have passed invalid path to settings file (please note that relative path can be valid or not depending on current folder, so it is recommended to use full path only). If not - we will need much more details.
HTH.

The settings file is addressed using an the absolute filepath.
Using 2.5.213.1 the same piece of code loads the settings correct, but 2.5.313.1 fails.
Why?

Best regards
cew

[Vasyl-Tracker Dev Team]

Hi cew.

Strange.. I just tried one our demo-app:

"<ProgramFiles>\Tracker Software\PDF-XChange Viewer SDK\Bin\AX_C#Examples\PDFViewerActiveXTestCS.exe"

I checked it on 'Settings I/O' tab, case 'Use File' - all working well.
Can you reproduce your issue with our demo-app?

Cheers.

[cew]

Hi Vasyl,

with version 2.5.313.1 we run in different problems at different customers!
It seems, that all problems happen in the context of LoadSettings.
Please contanct your developers and ask them what the changed between 213 and 313.

We use the ActiveX viewer in a WindowsFormsHost. When closing the containing view we trigger the viewer's SaveSetting and dispose the viewer.
At a customer we saw, that the settingsfile has a size of 0 byte.
Could it be, that the viewer saves the settings asynchronous and gets disposed before he had a chance to save the settingsfile?
Have there been changes between 213 and 313 in terms of Load-/SaveSettings??

As I already mentioned, we could solve a loading problem during an event handling process by using a post to call LoadSettings:

Code: Select all

 var sync = SynchronizationContext.Current;
sync.Post((object oo) => {
    ucViewer.LoadSettings(filename);
}, null);

Is the version 313 100% compatible to settings files created with 213?

Best regards
cew

[cew]

Hi Vasyl,

did you get any info from your developers?


Best regards,
cew

[Tracker Supp-Stefan]

Hello cew,

Vasyl is one of the Project Lead developers himself
Did you follow the advise he gave in his last post? Can you reproduce the issue with our sample project?

As for the saving of settings - yes it's usually done on closing the Viewer, so too quick closing might indeed be causing the problem.
Is a workaround with "LoadSettings" / "SaveSettings" being called through your code acceptable?

Regards,
Stefan

[cew]

Hi Stefan,

Did you follow the advise he gave in his last post? Can you reproduce the issue with our sample project?

No, I can't reproduce it with your sample.
We use the viewer in a totally different environment (WPF, MVVM, WindowsFormsHost).

As for the saving of settings - yes it's usually done on closing the Viewer, so too quick closing might indeed be causing the problem.
Is a workaround with "LoadSettings" / "SaveSettings" being called through your code acceptable?

No. We load settings an set some other options direct afetr loading. If we load the settings using the POST method, the LoadSettings will override the previous settings.

Does the viewer write the settings asynchronous? When calling the SaveSettings-method, the viewer has to write the settings synchronous to avoid getting in trouble by the following Dispos().

What does your version log say about Load-/SaveSettings changes between 2.5.213.1. and 2.5.313.1?
The problems occured within the last 3 weeks. I think it is triggered by some MS updates, because our customers didn't have any problems at all...

Best regards
cew

[Vasyl-Tracker Dev Team]

Hi cew.

Does the viewer write the settings asynchronous? When calling the SaveSettings-method, the viewer has to write the settings synchronous to avoid getting in trouble by the following Dispos().

When you call the Load/SaveSettings the Viewer makes it synchronously. It means - caller will definitely wait for finish of Load/SaveSettings.
This behavior was from beginning for that features...

But sure, some other methods can be called asynchronously. The reason for it - the Viewer ActiveX is the two-component model: in-process DLL + out-process EXE-server. The DLL-stub redirects any request to EXE-component. When you calling some Viewer's methods it may show own modal dialog (Print for example). If you will call such method synchronously it will completely block your UI while Viewer displays his own modal dlg.

But for your case - may be is good idea to try pass PXCVA_Sync flag in most cases, just for test..

What does your version log say about Load-/SaveSettings changes between 2.5.213.1. and 2.5.313.1?

No any changes for that features we made in period from 313 to 316.1 build. The unknown interference with other changes is always possible, but...

About this:

I investigated the problem and found a scenario to reproduce the bug:

I created a new form with just a user control ucViewer (containing the activeX viewer control).
In the ucViewer_Load eventhandler, load settings to the contained activeX control.
The maschine freezes.

Encapsulating the LoadSettings solved this problem:
var sync = SynchronizationContext.Current;
sync.Post((object oo) => {
ucViewer.LoadSettings(filename);
}, null);

- sorry, but we had no time to investigate it. will try it a bit later, in next couple days..

Also, There is any change to see and investigate that problem live, through RDP, TeamViewer etc. ?

HTH

[cew]

But sure, some other methods can be called asynchronously. The reason for it - the Viewer ActiveX is the two-component model: in-process DLL + out-process EXE-server. The DLL-stub redirects any request to EXE-component. When you calling some Viewer's methods it may show own modal dialog (Print for example). If you will call such method synchronously it will completely block your UI while Viewer displays his own modal dlg.

That's ok, we don't have any problems with that behaviour. We just saw that customer sometimes have settingsfiles with size 0.
This could be caused by writing asynchronously and getting disposed during writing.

But for your case - may be is good idea to try pass PXCVA_Sync flag in most cases, just for test..

LoadSettings/SaveSettings do not support flags.

What does your version log say about Load-/SaveSettings changes between 2.5.213.1. and 2.5.313.1?

No any changes for that features we made in period from 313 to 316.1 build. The unknown interference with other changes is always possible, but...

The change producing the bug is from 213 to 313.

- sorry, but we had no time to investigate it. will try it a bit later, in next couple days..
Also, There is any change to see and investigate that problem live, through RDP, TeamViewer etc. ?

Teamviewer would be great. Just write a PM.

Best regards,
cew

[Vasyl-Tracker Dev Team]

Hi, cew.

Sorry for delay with answer.

LoadSettings/SaveSettings do not support flags.

I just checked it and using PXCVA_Sync flag for that isn't necessary for you because function is already synchronous.

The change producing the bug is from 213 to 313.

I spent couple hours to detect any significant change that may cause the problem but it looks like impossible to find it only by looking trough all intermediate builds between 213 and 313(including last).
Because number of such builds is 11 and problematic change might be not only in LoadSettings/SaveSettings but in any deeply related place..

So, I see only one way to get potential solution - is after full investigation by remote session..
In next couple days we may do it. This problem still actual for you?

If yes - please email your request to support@pdf-xchange.com.
For our side the best time to get remote session is:
11am - 4pm, PST(UTC:-8hr, Pacific Time), any working day.

Cheers.

[cew]

Hi Vasyl,

Hi, cew.

The change producing the bug is from 213 to 313.

I spent couple hours to detect any significant change that may cause the problem but it looks like impossible to find it only by looking trough all intermediate builds between 213 and 313(including last).
Because number of such builds is 11 and problematic change might be not only in LoadSettings/SaveSettings but in any deeply related place..

So, I see only one way to get potential solution - is after full investigation by remote session..
In next couple days we may do it. This problem still actual for you?

After adding the workaround to all affected code parts, we can "live" with that problem.
Remote debugging would be very hard and time consuming because after each try, the computer has to be resetted

If we run into problems, we are unable to handle, I will come back to you.

Best regards,
cew3

[Tracker Supp-Stefan]

Hello cew,

Thanks for the feedback. So for the time being we will consider this sorted!
Let us know if there are any other issues we can help with!

Regards,
Stefan