Server unresponsive, Event IDs 1053, possible thread pool problem

We have a Windows 2003 server, SP2, (member server) that started becoming
unresponsive once or twice a day. The event viewer shows three different
Event ID 1053 events:

1) Windows cannot determine the user or computer name. (The RPC server is
unavailable.). Group Policy processing aborted.

2) Windows cannot determine the user or computer name. (The specified domain
either does not exist or could not be contacted.). Group Policy processing
aborted.

3) Windows cannot determine the user or computer name. (Not enough storage
is available to complete this operation.). Group Policy processing aborted.

The console is somewhat functional in that the keyboard and mouse work.
However, you can't do practically anything from the console - even an
ipconfig throws an error. You can't access anything on the server over the
network.

In looking through some articles, I got a hint that this might be an issue
with the handles created by a process, so within the task manager, handles
were added to the columns. After a reboot, spoolsv had around 260 handles.
When the server crashed, spoolsv had over 12,000 handles. Even after
terminating the spoolsv service, the system still didn't respond properly
until a reboot.

I'm not sure what is causing the spoolsv to flake out and how to resolve
this problem, or even if there is something else going on.

I did run across another article that said to use pstat.exe for
troubleshooting, but I couldn't find a copy for Win2K3.

Thanks for any guidance.

Sorry, but I left out some information. The system log also shows Event ID
2019, "The server was unable to allocate from the system nonpaged pool
because the pool was empty." Here's the article I went through last night:

http://blogs.msdn.com/ntdebugging/ar...0-or-2019.aspx

"Allyn" wrote:

> We have a Windows 2003 server, SP2, (member server) that started becoming
> unresponsive once or twice a day. The event viewer shows three different
> Event ID 1053 events:
>
> 1) Windows cannot determine the user or computer name. (The RPC server is
> unavailable.). Group Policy processing aborted.
>
> 2) Windows cannot determine the user or computer name. (The specified domain
> either does not exist or could not be contacted.). Group Policy processing
> aborted.
>
> 3) Windows cannot determine the user or computer name. (Not enough storage
> is available to complete this operation.). Group Policy processing aborted.
>
> The console is somewhat functional in that the keyboard and mouse work.
> However, you can't do practically anything from the console - even an
> ipconfig throws an error. You can't access anything on the server over the
> network.
>
> In looking through some articles, I got a hint that this might be an issue
> with the handles created by a process, so within the task manager, handles
> were added to the columns. After a reboot, spoolsv had around 260 handles.
> When the server crashed, spoolsv had over 12,000 handles. Even after
> terminating the spoolsv service, the system still didn't respond properly
> until a reboot.
>
> I'm not sure what is causing the spoolsv to flake out and how to resolve
> this problem, or even if there is something else going on.
>
> I did run across another article that said to use pstat.exe for
> troubleshooting, but I couldn't find a copy for Win2K3.
>
> Thanks for any guidance.

If you haven't already, see:
http://support.microsoft.com/kb/312362/en-us
http://support.microsoft.com/default...b;EN-US;304101
http://support.microsoft.com/kb/247904/EN-US/

The first two helped us with a similar issue.

For the spooler problem, you might get better answers in the newsgroups:
microsoft.public.win2000.printing
microsoft.public.windows.vista.print_fax_scan
microsoft.public.windowsxp.print_fax

Sometimes a quite knowledgeable person (about printing and the spooler
service) from Microsoft responds to posts in those groups.

Usually, spooler (spoolsv) problems are caused by a "bad" printer driver.
Unfortunately, tracking down which one can be tricky, but if you've added or
updated one recently, that might be something to look into.

Sometimes, 1053 events happen if a user is a member of a large number of
groups and the maximum Kerberos token size is too small - see
http://support.microsoft.com/kb/935744/en-us - (can cause the GPO procesing
issue as well as the join to domain issue) - but if the nonpaged pool is
getting exhausted, this probably is not the problem.

--
Bruce Sanderson MVP Printing
http://members.shaw.ca/bsanders

It is perfectly useless to know the right answer to the wrong question.



"Allyn" <Allyn@discussions.microsoft.com> wrote in message
news:6069EB8B-6BDB-42C1-97D1-446036C4827F@microsoft.com...
> We have a Windows 2003 server, SP2, (member server) that started becoming
> unresponsive once or twice a day. The event viewer shows three different
> Event ID 1053 events:
>
> 1) Windows cannot determine the user or computer name. (The RPC server is
> unavailable.). Group Policy processing aborted.
>
> 2) Windows cannot determine the user or computer name. (The specified
> domain
> either does not exist or could not be contacted.). Group Policy processing
> aborted.
>
> 3) Windows cannot determine the user or computer name. (Not enough storage
> is available to complete this operation.). Group Policy processing
> aborted.
>
> The console is somewhat functional in that the keyboard and mouse work.
> However, you can't do practically anything from the console - even an
> ipconfig throws an error. You can't access anything on the server over the
> network.
>
> In looking through some articles, I got a hint that this might be an issue
> with the handles created by a process, so within the task manager, handles
> were added to the columns. After a reboot, spoolsv had around 260 handles.
> When the server crashed, spoolsv had over 12,000 handles. Even after
> terminating the spoolsv service, the system still didn't respond properly
> until a reboot.
>
> I'm not sure what is causing the spoolsv to flake out and how to resolve
> this problem, or even if there is something else going on.
>
> I did run across another article that said to use pstat.exe for
> troubleshooting, but I couldn't find a copy for Win2K3.
>
> Thanks for any guidance.