Hang caused by pdfsaver4 calling SendMessageTimeout()

[nick.tucker]

Hi there

I have a customer who is experiencing hangs in PDF generation using the latest PDF-XChange 4 Drivers API which turn out to be because other unrelated apps (e.g. outlook.exe) are running on their workstation but are either hung or simply busy and not servicing their Windows messages. The cumulative resulting delay runs into minutes because of all the other unresponding windows.

Does version 5 also use SendMessageTimeout()?

Nick Tucker

[Tracker Supp-Stefan]

Hi Nick,

I need to discuss this with our Drivers experts so we will post back a reply here a bit later in the afternoon.

Best,
Stefan

[Ivan - Tracker Software]

SendMessageTimeout is used when the method ApplyDevMode() is called to inform that the the DEVMODE of the printer is changed (message WM_DEVMODECHANGE).
I'm afraid we cannot omit sending this message.

[RMan]

We are running into the same problem. It's not uncommon for the ApplyOptions to take 13 seconds or longer consistently.

Also in testing I see some programs never seam to pick up on the Resolution Change. Open Office 3.2.1 doesn't see the changes where Office 2010 does on mine.

Ivan can you please go into more detail of when this should be called and when it doesn't have to be called? It doesn't look like that information has ever been added to the online help. Does it only need to be called when changing DevMode parameters like the Resolution and Paper Sizes but not when changing things like the output filename and image compression options?

Do you always have to:
1.) CreatePrinter
2.) SetOptions
3.) ApplyOptions

To me I've never understood why we can't create the temporary driver then set all of the settings we want to change and then have the ApplyOptions actually add the driver so programs can see it. The CreatePrinter on mine only takes .5 seconds and the applications all seam to see the new printer before the ApplyOptions is called after I change the settings. I think the vast majority of developers would prefer this workflow and if you need to change the settings other than the output filename during our process you delete and create a new driver which seams to be much faster anyways.

Also most of the time as a developer we know the hwnd of the application we are working with that needs to see the changes. So maybe use the optional flags of the ApplyOptions such that.
0 = Default as it works now
-1 = You do everything except send the SendMessageTimeout and allow us to decide what to do. In my case I would probably do a PostMessage so it doesn't have to wait followed by a SendMessage Timeout to the Window that I know needs to see the changes.
>0 = We pass you the handle of the window that we know needs it and you do the PostMessage to everything and the SendMessageTimeout to just that windows to make it easier for other developers.

In the short term can you post the PrivateDevMode structure so we can handle it ourselves if we know how to set the DevModes.

[RMan]

I've done some more testing. Today is better, only about a 4 to 5 second delay for the ApplyOptions. So I did my own SendMessageTimeout with a 10,000 millisecond wait time and it took over 40 seconds so I'm guessing currently my system has 4 windows not responding and the ApplyOptions is taking 4 to 5 seconds after it to do it's job. Changed it to 1,000 miliseconds and it's about 4 to 5 seconds for my SendMessageTimeout and just slightly longer than the ApplyOptions takes. So again it tells me the other day I probably has 12 or 13 windows not responding to it and today 4.

Then I read up some more on the SendMessageTimeout call and tested the SMTO_ABORTIFHUNG flag option and tried that and it's about 1.8 seconds now which is still not ideal but it is better. I'm hoping sometime to get my system back to where the ApplyOptions was taking 13 seconds and longer to see what it does in that case.

· fuFlags
[in] Specifies how to send the message. This parameter can be one or more of the following values.
SMTO_ABORTIFHUNG
Returns without waiting for the time-out period to elapse if the receiving process appears to be in a "hung" state.
SMTO_BLOCK
Prevents the calling thread from processing any other requests until the function returns.
SMTO_NORMAL
The calling thread is not prevented from processing other requests while waiting for the function to return.
SMTO_NOTIMEOUTIFNOTHUNG
Windows 2000/XP: Does not return when the time-out period elapses if the receiving thread is not hung.

I also in searching came across this Microsoft KB about not setting the Timeout Period to 0 in this case.
http://msdn.microsoft.com/en-us/library ... s.85).aspx

[Paul - Tracker Supp]

Hi RMan,

this was fixed in V5, I'm not sure if this will be fixed in V4, I'm waiting to hear what the official position is on that but it may be a few days as the decision maker is unavailable for a few days.

An upgrade to V5 will definitely solve this for you though.

hth

[RMan]

Paul was this just fixed in the latest release? We were testing build 269 of the V5 driver and it also was doing it.

Also maybe it's time to start a V5 Driver forum for developers?

[Paul - Tracker Supp]

Hi RMan,

I was told by the dev team it was fixed in V5 - current build is 270 - can you confirm that 270 is also not working?

regards

[RMan]

Paul,

Which build was it supposed to be fixed in. Was it just fixed in the latest build 270 or before that?

It's hard to test because even before it didn't always show up. You had to have a non responsive window to cause it.

That said in the latest build 270 I have not seen it take longer than a second yet so it appears much better and hopefully fixed!!!

[Paul - Tracker Supp]

To be honest I'm not sure which build, I was never told. I could ask again, but it's almost academic now and given their V3 workload I don't like pestering the team unless it's really important.

Of course, let us know if you see anything more!

[RMan]

It's not academic now because if it was fixed prior to build 270 of version 5 then there is still a problem because we were testing build 269 and seeing the long wait times.

Can you please verify which version it was supposedly fixed in?

[Paul - Tracker Supp]

Sure. I'll be asking someone in Europe so I won't get an answer until tomorrow though,..

hth

[Ivan - Tracker Software]

This fix has been made in build 270 of the driver, and SendMessage in the ApplyOptions() method now looks like:

Code: Select all

SendMessageTimeoutW(HWND_BROADCAST, WM_DEVMODECHANGE, 0L, (LPARAM)(LPCWSTR)m_sPrinterName, SMTO_ABORTIFHUNG, 10, NULL);

[RMan]

Thanks for confirming which build it was fixed in.

[Tracker Supp-Stefan]

[Victorvon]

It is my understanding the design of virtual printer is to allow application to create a private printer that is only known to the application, if that is true then why bother broadcasting the changes to other unrelated applications? I agree with RMan's suggest to provide ApplyOptions with option to avoid SendMessageTimeOut.

May I know when are you going to fix V4? My company is in the process of upgrading to V5 but that will take a while (considering the need to update our software to use V5 API), it will be nice to simply ask our users to installed the fixed V4 you provided than asking them to wait for the patch from us.

[Paul - Tracker Supp]

Hi Victor,

I may be wrong but it may be that build 211 of V4 got the same. Can you tell me if it works in V4 build 211 (current)?

[Victorvon]

Yes, it is still happening with V4 build 211. My clients will get MFC's famous "server busy" dialog after 5 seconds if they have a lot of top level applications running (normally they do), our current solution to this problem to to disable the dialog but that just gives you an idea there still can be long delay with build 211.

Again, I don't think we can totally get away from this problem if ApplyOptions() function internally calls SendMessageTimeOut(). It really depends on your definition of "working", with MFC's definition delay over 5 seconds is "not working".

With best regards,
Victor Von

[Paul - Tracker Supp]

Hi Victor,

Ivan has responded with the following:

Hi Paul, I can make similar changes in V4 to reduce the side effect of SendMessageTimeout function. Please make a ticket and I will do it in the next build of V4

So I have created a ticket for this RT#1938: Hang caused by pdfsaver4 calling SendMessageTimeout() The ticket is internal only but if you refer to it we can quickly check the status of it if needed.

hth

[Victorvon]

Thank you for taking care of this!

[Paul - Tracker Supp]