Print drivers can cause failures in the Windows Print Spooler and PaperCut Print Provider services as well as applications when calling into print driver methods. If there is a dialogue message stating “’Application Name’ has stopped working” or an expected running service is no longer running, you can track these failures reviewing events in Windows Logs.
How to identify the binary causing the crash Select Start → Server Manager → Tools → Event Viewer. From here, expand Windows Logs → Application. Right-click, Filter Current Logs, set Event sources: Application Error. This will provide a list of events with ID 1000. Search through the events for the faulting application name: spoolsv.exe or pc-print.exe. Failures related to other print components are printisolationhost.exe and splwow64.exe as well as the executable for an application. Each event will contain “Faulting module name” data. Failures that can be traced further have information with a print driver binary name.
Ignore module names of ntdll.dll and kernel32.dll, print drivers will call into these modules but they do not directly link back to the print driver.
In the following example MyTestPrintDriver.dll is causing a failure in the print spooler service.
Faulting module name: MyTestPrintDriver.DLL, version: 6.1.14.13, time stamp: 0x52fd1c1a
Exception code: 0xc00000fd
Fault offset: 0×00000000001500da
Faulting process id: 0×2d9c
Faulting application start time: 0×01d0e431c4b366c5
Faulting application path: C:\Windows\system32\spoolsv.exe
Faulting module path: C:\Windows\system32\spool\DRIVERS\x64\3\MyTestPrintDriver.DLL
Report Id: 257c39f8–5025–11e5–82ae-00249b0fae66
How to identify the driver On Server 2012 and newer, use PowerShell to perform a search of the print drivers installed to determine the print driver associated with this .dll file. Open Windows Powershell, execute the get-printerdriver commandlet. You can use wildcard characters with a partial binary name, just substitute the binary name identified in the Windows event.
get-printerdriver | where {$_.ConfigFile -like "*MYTestPrintDriver*" -or $_.DependentFiles -like "*MyTestPrintDriver*" -or $_.Monitor -like "*MYTestPrintDriver*"}
This will return:
Name PrinterEnvironment MajorVersion Manufacturer
-— ——————- ————- ————–
My Test Print Driver Windows x64 3 TestPrintDriverVendor
On Windows Server 2008 and newer you can use the vbs scripts included with the operating system to filter for the driver name and the binary name. This method works for Windows Server 2012 and 2012R2 but the previous PowerShell command is the better choice.
cscript c:\Windows\System32\Printing_Admin_Scripts\en-US\PRNDRVR.VBS -l |findstr /i /c:"Driver Name" /c:MyTestPrintDriver
Note replace en-US with the locale information of your operating system.
This will provide a complete listing of the driver names due to the search on “Driver Name”. Look through the list and find the one that uses the faulting module name.
Driver name My Test Print Driver, 3, Windows x64
C:\Windows\system32\spool\DRIVERS\x64\3\MyTestPrintDriver.DLL
Steps to a solution Armed with the print driver name, you can determine the printers impacted and determine if there is an updated driver for the device or you can evaluate a compatible replacement that would work better in your environment. Please check the relevant vendor website and Windows Update for driver updates and test with alternative drivers for the device.
We also recommend having a look at our article Improving Windows Print Spooler stability for some specific suggestions on how to isolate or mitigate buggy print drivers.
Comments
0 comments
Please sign in to leave a comment.