pdfsaver.exe hangs after printing a large amount of files

[Matchay]

Hello,

sorry you have to hear from me again, but it seems we stress your software very hard Unfortunately we're having another problem. Sometimes our software must reprocess a large number of datafiles, after reprocessing of a single datafile a set of reports is generated, one of them goes to your PDF printer. It's usually a fast process, which means that the PDF printer gets a new job every few seconds. Sometimes pdfsaver4.exe hangs after a few hundreds (200-300) of reports. I have made a dump file of the hanging pdfsaver4.exe, I also noticed that after every printing the number of handles used by the pdfsaver4.exe increases (3 handles a run) and doesn't go down anymore.

Handles problem can be visible on both Vista and XP, and also in the 155, but the hang-problem only on Vista.

I also have an impression the version 155 didn't have the hang-problem.

We're in a very hard situation now, practically we have released our software with a PDF-issue now. I could provide you with the dumpfile, I can also cooperate if you send me some debug version of the driver.

Regards,
Maciej

PS: the pdfsaver4.exe is always hanging directly after printing a file (a PDF file is complete) - seems to be about to send an FileSaved event, but it hangs there.

[Ivan - Tracker Software]

Please try to turn off AutoUnload option. (Run from Programs menu, and on on Settings page uncheck the option "Autounload pdfSaver after".

[Matchay]

I investigated the hang-issue as far as I could with WinDbg.
I could find out following:
1) !locks command notifies me there is a lock on one of the pdfsaver4.exe's threads, it turned out the thread is at "WaitForSingleObject" with the handle number "0x1408".
Critical section of one of threads is locked.

DebugInfo = 0x0026a8d0
Critical section = 0x006b8c04 (pdfSaver4+0x2B8C04)
LOCKED
LockCount = 0x2
WaiterWoken = No
OwningThread = 0x00000e90
RecursionCount = 0x1
LockSemaphore = 0x1BC
SpinCount = 0x00000000

2) I listed all handles of your process, and it turned out numbers match very well:

there is 1236 Handles (it matches the number shown by Windows' Task Manager), the most important are Events and Keys:
Type Count
Event 799
Key 395
[...]
It is almost exactly 2 Events and 1 Key for a single PDF-file printed (these are the 3 handles I mention in my post above). It might be you create some semaphores/critical sections/mutexes for every print-job without deleting the old objects?

All Key-objects refer to:
"\REGISTRY\USER\S-1-5-21-3808959830-993822314-23610568-1120\Software\Tracker Software\PDF-XChange 4.0\Drivers\Control\00000001"

[Matchay]

Please try to turn off AutoUnload option. (Run from Programs menu, and on on Settings page uncheck the option "Autounload pdfSaver after".

Hi,

in our installation it's turned off by default. But I played around with those settings too and it doesn't help. May I remind you: we create a PDF-printer at a start-up of our app and use the one and only for all print jobs. Therefore I don;t think the Autounload is relevant anyway.

Regards,
Maciej

[Ivan - Tracker Software]

Will try to reproduce. Will let you know the result.

[Matchay]

I also tested the following (with "unload" turned off)

1) I printed from the notepad to the default installed PDF-Xchange 4.0 Printer (not the temp one). If you print once every 2-3 minutes, the number of handles goes up, and then comes back to the original number. But try to print a file every few seconds - the number of handles increases to never go down again.

But it's mainly "Key" objects that remain

Name \REGISTRY\USER\S-1-5-21-198358228-527928863-167192953-155143\Software\Tracker Software\PDF-XChange 4.0\Drivers\Control\00000001

2) I printed from the notepad to the temp printer. The number of handles increases no matter how often it's being printed. In end effect it's always exactly 3 handles per job: 1 Key + 2 Events.

I debugged a little further, and I am quite sure the leaking Events have to do with triggering OnStartDoc, OnFileSaved etc. events. The leak doesn't depend on how I print (from Notepad or as PlayMetafile on a DeviceContext) but only if the printer is temporary or not.

I believe the hangs which happen form time to time have to do with unclean handling of the events. The handles are not cleaned up properly and in combination with tight timing when printing files quite fast a deadlock occurs.

[Ivan - Tracker Software]

I'm working on solution, and will let you know when it will be ready.

[Ivan - Tracker Software]

Had found dead-lock and event/handles leak. Updated build 159 will be released in 10 hours.

[Matchay]

I find it simply incredible. Thanks! Waiting for the build to verify it.

Regards,
Maciej

[Matchay]

Hi,
unfortunately the events are not working at all with the new build. I noticed also there is two pdfsaver4.exe processes (never happened to me before this build). I restarted the machine to start clean.The first pdfsaver4.exe is created when I am creating a temporary printer, and the second comes up when the first printing job comes. The first shows activity in Task Manager always when a printer is created, and the second when something is printed. It seems the job goes not to the one I was registered for events at.

Regards,
Maciej

PS: I managed to get it working temporarily, after playing around with "autounload" option, killing the processes again and again the weird behaviour vanished. Then I restarted the machine and I got it again. It must have something to do with "autounload", but I can't figure out the conditions.

[Ivan - Tracker Software]

I can send you debug version of the pdfSaver4.exe, just let me know email to send it.

[Matchay]

Thank you for the perfect support as usual!

The problem was solved, I must admit it wasn't a bug in PDF-Xchange code, rather an unlucky coincidence how OUR printing process was created - which was incompatible with the newest PDF-Xchange release. Ivan helped me to find out the root cause in our code and it works now.

Thank you!
Regards,
Maciej

[John - Tracker Supp]

Fantastic news Maciej,

Pleased all is well