Win7/2008 Server - PDFXCview premature death

[DSSavant]

BUG: When on a Windows 7 or Server 2008 box, if the user Logs off the system, the viewer control will allow itself to shutdown before it should. XP and Server 2003 work fine. I never bothered testing on Vista as I consider it a virus.

During a Logoff event, the system will broadcast to all windows asking them to close. Each application can then prompt the user regarding unsaved edits. After a period of time, Windows will get involved and start prompting the user regarding processes that are not shutting down. Refer to:

http://msdn.microsoft.com/en-us/library ... nding.aspx

The viewer process, PDFXCview.exe, is responding too eagerly and shutting down Before its hosting process has shut down thereby causing a loss of data in the case of the PDF Document. This is bad where the PDF Document has legal information, etc. Ignoring the loss of data, the hosting application is simply left out to die because its heart and soul has been ripped out of it unexpectedly.

Below is the exception that is received by the hosting application when the viewer process dies too early. Notice my application is prompting the viewer if it has been modified – getting ready to prompt the user if necessary to save changes before exiting:

Code: Select all

PDFViewerControl.InternalDoVerb :: Error found in call - Viewer.DoVerb("Documents[#4095].Modified", "get", "", out dataOut, 0);

Exception: System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
   at PDFXCviewAxLib.IPDFXCview2.DoVerb(String ObjectName, String OperationName, Object DataIn, Object& DataOut, Int32 Flags)
   at AxPDFXCviewAxLib.AxCoPDFXCview.DoVerb(String objectName, String operationName, Object dataIn, Object& dataOut, Int32 flags)
   at <my call stack here>

The PDFXCview server should not simply die when it receives the Shutdown/Logoff message, rather it should ask itself it is being hosted and if so, Wait till the hosting application disconnects/shuts down.

As an example of proper behavior, load Notepad, type in the following:

“I love Apple and the fact that the OS is based on BSD Unix. I love Unix. Speaking of Presidents, think before you vote because we have to live with our decisions.”

Now logoff the system. You will notice that Notepad asks you to save the most insightful document ever written. This is the key point here, applications should be given the chance to save off unsaved changes. My application never gets that chance on Windows 7 or Server 2008.

And just because, you can find two nice videos (taken from an iPhone 4 (of course)) attached showing examples of closing down properly and being blown out of the water. The videos are very fast moving so you will want to pause often.

As always, scream if you need more.

[Vasyl - PDF-XChange]

Hi, DSSavant.

Thank you for clear and very helpful report. We will fix this bug in the new build (upcoming).

Best
Regards.

[DSSavant]

Thanks! Very very very much appreciated! Please notify me when I can install the next build.

[Paul - PDF-XChange]

Hi DSSavant,

I have made a note to post here when it is ready.

[Vasyl - PDF-XChange]

Hi, DSSavant.

The new build will be today or tomorrow.

With the new build, to resolve your problem, you should intercept and process the new named event "Notifications.EndSession":

Code: Select all

eventhandler OnEvent(type, name...)
{
    if ((type == PXCVA_OnNamedNotify) AND (name == "Notifications.EndSession"))
    {
       // check for modified documents
       // if need - ask end-user for save modifications
       // if need - use notification's property to prevent system logoff/shutdown operation
       ctrl.SetProperty("Notifications.EndSession.Cancel", "true", 0); // default value is "false"
    }
}

NOTE: if you have not stopped the logoff/shutdown operation (by property above) - do not use our control after this event because windows forces the terminatation of our com-server - you may release it only...

We have fixed a similar problem for EU-program users also.

Thanks again for your report.

Best
Regards.

[DSSavant]

I need to make sure I understand properly.

When I receive this notification:

A) In the case I do NOT prevent the shutdown process, I need to set a flag in my routines to indicate the the viewer is no longer usable.
B) In the case that I ALWAYS prevent the shutdown process, I need to allow my 'parent' to process the system message, prompt the user to save modifications, etc. and then shut itself down thereby shutting me down and then the viewer with it.

Item B above is the approach I will take. Always tell the viewer to cancel the shutdown. I will soon shutdown thereafter and take it out when I dispose of myself.

Please let me know if I'm not correct in my assumption.

[Vasyl - PDF-XChange]

Hi, DSSavant.

A) In the case I do NOT prevent the shutdown process, I need to set a flag in my routines to indicate the the viewer is no longer usable.

- correct, you may use this event to set this flag only

B) In the case that I ALWAYS prevent the shutdown process, I need to allow my 'parent' to process the system message, prompt the user to save modifications, etc. and then shut itself down thereby shutting me down and then the viewer with it.

- the Windows sends the shutdown verification notify (WM_QUERYENDSESSION message) to our control before (and it prompts you by this event) and then - Windows sends this message to your application. When you prevented the shutdown process in OnEvent(..., "Notifications.EndSession") handler then Windows will break notification process for all applications and your application doesn't receive this system notify. I think the best way is full processing (prompting the end-user) of the shutdown notification in OnEvent(..., "Notifications.EndSession") case, but I could be wrong.

HTH.

[DSSavant]

Yuck. I have wrapped the viewer in a User Control to isolate it from our main application. Meaning, it is nothing more than a control like many of the other controls in the application. PDF Documents (and thus the viewer) is a small part of the overall application.

As a thought, the viewer control could simply ignore Window's request to shut down if I tell it knowing that it has a host connection it should and must honor. I would rather have it do that if possible. The only downside to this approach is if Windows physically rips it out of memory which it should only do as a last resort. I consider the Viewer just another control. If all the sudden, all the controls on your form start to disappear, how would an application ever be able to shutdown gracefully? I do understand the viewer is an out of process control but still.

Can we change the implementation to what I'm suggesting above?

[Vasyl - PDF-XChange]

Hi, DSSavant.

As a thought, the viewer control could simply ignore Window's request to shut down if I tell it knowing that it has a host connection it should and must honor. I would rather have it do that if possible. The only downside to this approach is if Windows physically rips it out of memory which it should only do as a last resort. I consider the Viewer just another control. If all the sudden, all the controls on your form start to disappear, how would an application ever be able to shutdown gracefully? I do understand the viewer is an out of process control but still.

I understand you but I cannot suggest you another solution in current implementation because viewer must(!) process the system's shutdown/logoff notification. IF viewer returns the TRUE(allow to shutdown) or ignores this notification(default window procedure will return TRUE also) THEN system terminates(!) our process (PDFXCview.exe com-server), we have no choice in this case (thanks for guys from Microsoft). There will be in-process component(dll) only WITHOUT any external exe com-servers in the new version of our SDK(V3).

Best
Regards.

[DSSavant]

I understand. I don't like it but I do understand.

[DSSavant]

Sorry guys, I must disagree after thinking this one through a bit.

I've uploaded another video in "2008 admin workspace.zip". Please refer to it.

If you step through the video you will notice:

1. Application is running.
2. Application is made dirty.
3. Start menu, Logoff is selected.
4. Application receives the terminate message and Cancels it - it says NO!
5. Application starts a graceful shutdown process prompting the user to Save Changes.
6. Windows prompts user to Force logoff or Cancel to save their changes.
7. Under Windows 7, the user will be given ample time to decide. Under Server 2008, the system will forcibly go down faster.
8. If the user Cancels at this point, the Application will continue running.
9 If my viewer control has gone to lunch, I'm dead.
10 If the viewer control has waited, as it should since its hosting process is still alive, all will work fine.

Lastly, ignoring all of that, when my process ends, your process immediately ends. When I load my process with the viewer showing and kill it via the task manager, your process immediately goes away. This in itself is another reason you should ignore the request and say NO, windows will not immediately kill you, my application will tell you it is time to die.

Please reconsider - please forward this to development.

[Corwin - Tracker Sup]

Hi DSSavant,

As I have test it on my Win Server 2008 - all works fine.
Also please note that if PDFVeiwer server rejects a Windows logoff message then this will stop the logoff for all other apps. You can read about this on MSDN
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

I have attached a sample C# project, that shows that you cannot logoff normally always when setting "Notifications.EndSession.Cancel" property to true and as you can see - PDFXCview process remains active after logoff.

[DSSavant]

I'll look at what you got and get back to you today.

[Paul - PDF-XChange]

looking forward to it...

[DSSavant]

Ok, let's try this again

I’ve reviewed the code you sent and will not be able to use your event in any way within my product. Thank you for the time and effort though. Please understand that the viewer is just a control like many other in my product. I have up to ten tabs with various bits of information on them. Each of the ten tabs will have one of your viewer controls embedded in them. Again, I have ten of your viewer controls, not one. The viewer controls are just controls and as such should not be telling the main application that Windows is shutting down or the user is logging off, my application can easily determine that via Form Closing, Session Ending, and Session Ended events however it desires.

As I see it, the viewer is a hosted control just like an edit control, grid control, label, drop down, etc. Albeit that the viewer is much more complicated than an edit control but nevertheless it is a control. I do not listen to any control to tell me what Windows will tell me on its own. I further do not expect any control to decide to terminate itself without my express permissions. And lastly, I do not expect any control to ever prevent Windows from shutting down.

When the user initiates a shutdown/logoff, Windows will send out a WM_QUERYENDSESSION, the .NET equivalent is SystemEvents.SessionEnding.

>>> MSDN: “The WM_QUERYENDSESSION message is sent when the user chooses to end the session or when an application calls one of the system shutdown functions. If any application returns zero, the session is not ended.”

>>> MSDN: “Occurs when the user is trying to log off or shut down the system.” – Cancellable.

The message is Cancellable. If cancelled, the entire shutdown/logoff sequence is aborted. As you know, this equates to the viewer’s “Notifications.EndSession.Cancel” message.

The message/event does NOT tell the application to terminate! It says that the user desires to start the shutdown/logoff process. The User Is Trying, not the System Is Forcing. There is a big difference. “I’m thinking of buying” an iPhone is not the same as “I’m buying” an iPhone.

If no applications cancel this event, the system will continue the shutdown process. At that point my application will get a Form Closing event and I will terminate thereby taking the viewer with me. This is how it should be.

If any application cancels the event then Windows stops asking everyone and leaves the system intact – note, while you may view the viewer as an application, in this context it is not. It is a hosted control and nothing more. The key point here is that it is not up to a hosted control, or any control for that much, to decide to commit suicide. It is up to the main applications to decide if they are to exit or not. The controls should rely on the wisdom of the main application receiving its message from Windows to decide what to do, not from the controls it hosts.

Tracker is telling me that their viewer control has no choice, that Windows will terminate them if they do nothing. This is incorrect. WM_QUERYENDSESSION does not kill the applications. It will be followed by WM_ENDSESSION which will indicate if the session is ending or not. Only when the hosted viewer receives this message and is told that the session is in fact truly ending should the viewer exits. Even then I would think that if it is being hosted, it should wait for its hosting application to terminate it.

The viewer is killing itself on the wrong event! Upon receiving WM_QUERYENDSESSION, it should do nothing if it being hosted. When my application that hosts the viewer as a control, just like edit controls and grids and …., decides to die, it will exit and take the viewer with it.

I truly do not feel I’m being unreasonable, the viewer is a control and as such should act like one.

[Lzcat - Tracker Supp]

Hi DSSavant.
Did you COMPLETELY read and undersand my comments about WM_QUERYENDSESSION and how it is working? I think not...

Let's see whats going on:

We have two applications - Yours (1) and theViewer (2). Yes, we have two applications, Viewer AX reside in separate process.
When a user selects logoff/shutdown BOTH applications receive WM_QUERYENDSESSION and if they respond TRUE they will receive WM_ENDSESSION. BUT the order in which they receive both messages is out of our control. What can we do here? NOTHING!

We can answer FALSE for WM_QUERYENDSESSION - but this will prevent system from logoff/shutdown.

We can answer TRUE for WM_QUERYENDSESSION - in this case the Viewer may be terminated before your application (because it will receive WM_ENDSESSION almost immmediately) and you will loose everything that was in it if modified.

There are no other options for QUERYENDSESSION. There is no way to exclude the Viewer from such processing.

The Problem is because the Viewer resides in a separate process, and until V3 we cannot change this. If you know how to handle such cases - please advise us and we will be happy to solve this problem...

[DSSavant]

Did I read and fully understand your statements. Yes. Did I run your application and fully get a grip on what you are doing? Yes. Did I write some of my own? Yes. Did you fully understand my point. I think not...

When the viewer receives the ENDSESSION message, are you terminating the process right then and there or are you ignoring it and letting Windows terminate you?

[DSSavant]

Yea, ignore that last one. The order in which Windows is sending it messages to each process is not allowing my routines to be notified before yours. I can't repo with your viewer what I can with my test harnesses. Bottom line, I have to work around the viewer being out of process and getting notified before my application.
---
I've asked before and I'll ask again, can I someone in your organization contact me regarding V3 and its timing - the product manager perhaps? I'm writing a ton of code in my product to support and utilize V2 features. I also realize I will have to rewrite the vast majority of it when release V3 is out. If V3 is out next month then I will cease all V2 work and wait. If V3 is not out till next year, then I can't wait and must sink time and resources into V2 for the sake of my customer's needs.

Can you help me out here and have someone email me please?

[John - Tracker Supp]

Hi,

we have actually put a formal statement out with a simple road map of the core features coming etc - and shortly we will issue a document regarding 3rd party developer Plug-ins for our end user viewer which will allow you to add functionality directly into our end user product without creating a separate application - these will work as core features to our own Viewer extending its functionality and we have great hopes for this and its ability to provide good revenue streams for independent 3rd party dev's - we anticipate there will be no Royalties payable on revenue you generate from these plug-ins - we will make a modest annual charge for the Plug-in SDK and make our real revenue from the base Viewer sales which we hope will be extended in appeal through the added functionality 3rd party developers attract to the Viewer itself in this manner.

I explain this just in case this would have any affect on your own development plans over the next 6 months or so.

You can view the above mentioned thread and road-map here
https://forum.pdf-xchange.com/ ... 35&t=10100

[DSSavant]

Thanks for the info John. I will cease anymore development on my product with regard to viewer features at this point. Version 3.X, I'm hoping, does not move in the direction that Acrobat did -- away from embedding and more towards an end user product. For example, Acrobat X, there is no way I can customize that beast enough to use it in my existing code base anymore. When I say "customize" I really mean fully dumbing down the viewer - very limited toolbars, context menus, etc. --I just need a PDF editor without all the bloat. If it does move in that direction, which could be very wise, maybe have a different product spin off of it such that it is nothing more than an embedded viewer thereby removing the product vs. control plug-in feature contention. Version 2.X, while it has it failings, has been customizable "enough" for me to include it in my new product and to fully replace Acrobat. The only thing I'm really lacking at this point is dynamic stamps.

Is there a way I can be a beta site? This would help me and you. You in that I tend to actually find bugs and report them. I have a full product full of features I would have to implement thereby exercising your stuff. I also give you guys grief and not only that, a perspective of how different companies desire to use your product.

[John - Tracker Supp]

Thanks for coming back, whilst we want to keep the balance of the viewer features and functionality fairly close to our chest for the time being - I can assure you that although we see great potential for the plugins - they will not replace the Viewer SDK - they are 2 totally different directions and we will support and extend both fully as we progress.

Further in the V3 Viewer SDK we will give much greater control to dev's in the configuration of both the toolbar's and functionality in view and will even be putting in the option to create your own 'skins' within certain parameter's to make the product look and feel more the way you want it.

Additionally if we had Plugins available now for example - you could have created a dynamic stamps plugin now and it would have been a really big seller for sure.

I really dont think the end result will be anything but a 'release' for dev's feeling constrained currently and will also ensure the 'bloat' potential that is I agree a very real danger is removed as you will be able to limit the functionality to a large degree that your clients see in the embedded Viewer Ax.

The biggest problem for us always with Beta's is the fact that the SDK is always the final component delivered and therefore doc's and examples are lacking and once we have provided to dev's even as a beta it causes 'noise' that can distract us from the final preparations for release - so whilst I genuinely do hope to release a beta as we can all see the value in this - it will most likely only be available at or after the release of the end user product.release

But certainly we will offer a beta of the end user product for testing and would be happy to include any licensed SDK user in this release testing.

Have a great weekend.

[DSSavant]

So my QA department just got to testing this in my code and imagine my chagrin when I found out it does not work. More specifically, it works great if you Step through the code in the debugger but fails when you do not.

Win7, 64-bit box
Also 2008, 64-bit server
Build 2.5.193.

I updated the C# FullDemo program by supplementing the following routines:

Code: Select all

        private void axCoPDFXCview1_OnEvent(object sender, AxPDFXCviewAxLib._IPDFXCviewEvents_OnEventEvent e)
        {
// START OF SUPPLEMENTAL CODE
			if ((e.type == (int)PXCVA_EventTypes.PXCVA_OnNamedNotify) && (e.name == "Notifications.EndSession"))
			{
			   // check for modified documents
			   // if need - ask end-user for save modifications
			   // if need - use notification's property to prevent system logoff/shutdown operation
				Debug.WriteLine("VIEWER END SESSION - responding FALSE");
				axCoPDFXCview1.SetProperty("Notifications.EndSession.Cancel", "true", 0); // default value is "false"
			}
// END OF SUPPLEMENTAL CODE
	switch(e.type)
            {
            case (int)PDFXCviewAxLib.PXCVA_EventTypes.PXCVA_OnPropertyChanged:
                {
                    OnPropertyChanged(e.name);
                    break;
                }
            }            
        }

and the Form Closing routine...

Code: Select all

        private void Form1_FormClosing(object sender, FormClosingEventArgs e)
        {
            ProcessOnParamChanged = false;

// START OF SUPPLEMENTAL CODE
			if (e.CloseReason == CloseReason.WindowsShutDown)
			{
				Debug.WriteLine("ON FORM CLOSING - cancelling event");
				e.Cancel = true;
			}
			else
			{
				base.OnFormClosing(e);
			}
// END OF SUPPLEMENTAL CODE
        }

So when I put a break point on the "axCoPDFXCview1.SetProperty" line in the event handler code, the routine will work every time. When I disable the break point and allow the debugger to run through it without stopping, the viewer will unload itself thereby causing bad things.

What did I miss?

[Corwin - Tracker Sup]

Hello DSSavant,

I have tested your code on Window7 x64 and x86 versions and everything works fine except line "base.OnFormClosing(e);" when I manually close form. Why do you put this code there? And also maybe you can give more detailed description of how to reproduce your problem with Viewer control?

[DSSavant]

Sorry, specifically here is what I do:

Success---
1. Load project in the debugger.
2. Set a break point on the line:
>>> axCoPDFXCview1.SetProperty("Notifications.EndSession.Cancel", "true", 0);
3. Run
4. Perform a System Logoff -> Start Menu > Logoff
5. In the debugger, after you have broke, simply continue running.
6. Everything should work as expected - the Viewer will remain intact, the form will still be running. Goodness!

Failure---
1. Load project in the debugger.
2. Remove any break point found on the line:
>>> axCoPDFXCview1.SetProperty("Notifications.EndSession.Cancel", "true", 0);
3. Run
4. Perform a System Logoff -> Start Menu > Logoff
5. You should not stop in the debugger for any reason.
6. The viewer will unload, the form will not, the debugger will ask you if you want to continue debugging. Badness!

In both cases, success/failure, the Output Debugger window will show, among other things, this at the bottom:

>>> 'PDFViewerActiveXTestCS.vshost.exe' (Managed): Loaded 'C:\Windows\assembly\GAC_MSIL\System.Configuration\2.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll'
>>> VIEWER END SESSION - responding FALSE

Scream if you want a video or something cool like that.

Oh and simply ignore (delete) the call to "base.OnFormClosing(e)". That code will not be executed during this failure. It was a shameless copy/paste from other code and not fully debugged on my part while trying to give you a test harness you could reproduce the issue with.

[Corwin - Tracker Sup]

Hi DSSavant,

Thanks for info. Please try to use new build 194 which should be available this evening.

[DSSavant]

You guys are great! Thanks, I will try it this coming Monday.

[Paul - PDF-XChange]

all praise to the Dev Team!!!

[DSSavant]

Looks good thus far. Will go to QA later today. Thanks.

[Paul - PDF-XChange]