The Case of the Print to PDF Hangs
Posted by William Diaz on April 4, 2011
One morning I started hearing a few reports of cases where users were not able to print to the BullZip PDF software printing device. After a wait of 5 minutes, the BullZip printer would return the following error: “An error occurred. Error 1008: Ghostscript timed out – Make PDF”
After a reinstall of BullZip failed to resolve in all cases, I began to wonder is some recent change may be the cause. The affected user was in the same office as me so I decided to print some random text from Notepad to a PDF and was able to reproduce the same hang.
I started troubleshooting by opening Process Explorer, which would allow me to select the hung process and dump it. This is the quickest way to get a dump of a crashing or hanging process in Windows XP. Windows 7/Vista Task Manager now support dumping processes or debugging by right-clicking the process. Other methods you can use are to use ADPlus from the Windows Debugging Tools, SysInternals ProcDump, or directly attaching to the hung process with WinDbg.
Spoolsv.exe starts gui.exe, which is the BullZip user interface. Gui.exe then starts the command shell, which then launches gswin32c.exe, the Ghost Script engine which does the conversion to PDF. It is gswin32c.exe that is the hung process. Normally before dumping the process, I like to open its properties and examne the Threads tab to see the stacks for important clues as to what may be causing the hang, e.g. other 3rd party components. In this case, however, even though you can see there 2 threads in this process, the Threads tab was empty and a dump would be needed to examine further.
After dumping the process, I opened the .dmp file with WinDbg and ran !analyze –v –hang. The hang switch goes the extra step in looking for a dead lock, a situation when two or more tasks permanently block each other by each task having a lock on a resource which the other tasks are trying to lock*. Here is part of the output where you can see in the box below there is, in fact, a deadlock:
Further down, we can see a 3rd party module in one of the frames, PGHook.dll. This is new to me. Msctf.dll may play a role; its properties are not too telling of its exact purpose but it part of Microsoft text services. For now, I ignore it and use the lmvm command to tell me what PGHook.dll is:
At this point I recall a new auditing service was pushed out to our local office for piloting. To see if this resolved the hang, I went into the services console on my workstation and stopped the service (Avecto Privilege Guard service), printed again using BullZip PDF, and the problem no longer occurred. Why the audit is causing Bullzip (or specifically gswin32c.exe) to encounter a deadlock is beyond me. In it’s current pilot, it is only meant to audit local workstations to see what processes are running and report the results back to a central location.
*Expanding on the deadlock, you can also use the !locks command in WinDbg to dig deeper into the issue. In the case here, it is not difficult finding the deadlock as there are only 3 threads. You can see threads 1520 and 11d8 waiting on each other (both own the CriticalSection in the others thread):