--------------------
From: "Palle" <
[email protected]>
Subject: How to find the faulty driver when Print spoller crashes with access volation c000005
Date: Wed, 7 Apr 2004 16:10:10 +0200
Newsgroups: microsoft.public.win2000.printing
Win 2k Server with SP2, print server for a multitude of printers (HPs,
Xerox, Sharp, Canon).
About 100 different printer queues.
The print spooler crashes around 15 times a day and then recovers (service
set to restart after 60000ms). We do get a Dr Watson log and user.dmp, how
can we analyze this and pinpoint what driver is the culprit ?
/P
----
The most common causes of the Print Spooler service stopping are printer drivers, third-party custom port monitors and
third-party print providers. If a new printer or printer driver was added recently try removing it to see what happens.
Check the following registry key for third-party monitors, removing any non-default monitors after exporting the key as a
backup:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors
The default port monitors are:
AppleTalk Printing Devices (When Services for Macintosh is installed)
BJ Language Monitor
Local Port
PJL Language Monitor
Standard TCP/IP Port
USB Monitor
Windows NT Fax Monitor
LPR Port
Check the following registry key for third-party print providers, removing any non-default print providers after exporting the
key as a backup:
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers
The default print providers are:
Internet Print Provider
LanMan Print Services
We would then need to stop and restart the Print Spooler service for these changes to take affect.
If you open the Dr Watson log in notepad, scroll to the bottom of the log, click so the blinking text cursor is on the last line
and now do a search up for "Application". This will be the last error recorded. Now search down for "Fault" and you should
come to a line that starts with "FAULT ->" pointing to a line of assembly code. Below the assembly code there is a section
called "Stack Back Trace" and normally the top entry under the "Function Name" colume will point to the last DLL!Function
that was called.
You can use the debugging tools from the site below to open the dump file.
http://www.microsoft.com/whdc/ddk/debugging/default.mspx
If you are not comfortable debugging a dump file you may want to open a support incident to have the dump analyzed.
Bill Peele
Microsoft Enterprise Support
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the
terms specified at
http://www.microsoft.com/info/cpyright.htm
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread
from which they originated.
