Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

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.

Before dumping, I needed to see what process was actually getting hung. With BullZip, there is actually another process that is started by the Windows spooler service; you can see that here:

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):


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: