Associating a Crashing Print Driver to a Printer
Posted by William Diaz on May 12, 2011
In Windows XP, if you have Dr Watson set as your post-mortem default debugger (by default it is) it usually does a good job at catching exceptions when the Windows print spooler, spoolersv.exe, crashes*. Most print spooler crashes are the result of a print driver. Finding the problem print driver is a simple matter of going into the drwtsn32.log and finding the thread that contains the FAULT, literally:
A user.dmp is also created in the DrWatson folder. This dump file offers more details and confirms it is a print driver but requires the Windows Debugging Tools to analyze. Resort to the user.dmp if the log is not revealing enough:
In the example here, I was asked to look at a couple accounting servers connected to 30+ printers across just as many offices. I need to find which of the printers is using the problem print driver identified above, SDNT5U.dll. I can go into the local print server in the OS to find which printer(s) are using this driver. In XP, this can be done by going into Printers and Faxes and selecting Server Properties from the File menu. From here, select each printer and click Properties and browse the file list until you locate the print driver.
At this point, select the printer and remove it to delete the print device and purge the print drivers and/or reconnect and update the print drivers. In the case here, the print device indicates it is a HP1022n. This is odd because the 1022 is a local printer, not a network printer. Looking at the printer Name on that office’s print server revealed a different model printer than the one described on the accounting server.
The accounting server:
The print server:
How or why this happened I can only guess. Perhaps the network printer was taken out of service at some point and replaced by a local printer temporarily. When the network printer was put back on the print server, the accounting server did not reflect this, thus creating a situation where the print device on the accounting server was using a driver to communicate with what was an entirely different printer, causing the spooler to crash. Resolving was a simple matter of deleting the problem print device and adding the correct printer.
*Crashing services, like the print spooler, also report to the Windows Event Viewer but do not always point to the problem module.