Re: Help analyzing Crash Dump file

Tech-Archive recommends: Fix windows errors by optimizing your registry

On May 7, 10:01 am, "Darhl Thomason"
<dar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Herb Martin" <n...@xxxxxxxxxxxxxx> wrote in message

news:u7lAiD4gHHA.3852@xxxxxxxxxxxxxxxxxxxxxxx> What additional services and drivers do you run on this system?

--
Herb Martin, MCSE, MVP
http://www.LearnQuick.Com
(phone on web site)

Hi Herb,

Sorry it took so long to reply.

My machine is a Win03Sp2 DC, it is running Symantec Antivirus 9.x corporate
edition, SQL server 2000, MDaemon mail server, & IIS, as well as functioning
as a file share point.

As for devices, it has APC PowerChute controlling a USB connected UPS, it
has an ATI Radeon 9000 series video card, a 3Com Etherlink 3C905B-TX
ethernet adapter and the motherboard integrated SoundMAX digital audio. The
motherboard is an Asus P4S533-X motherboard. I have the onboard SIS
900-based ethernet adapter disabled.

I'm 99% sure it happens when I am doing work across the network, so I wonder
if it is related to the 3Com network card. I was on my XP workstation
working on updating a website this and XP reported that it lost connection
to the server. I turned around to look at the server and the screen was
blank and watched the server come back up.

The CrashDump analysis this time is pointing to srv.sys, crash dump below.

Thanks!

Darhl

Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available

************************************************************
WARNING: Dump file has been truncated. Data may be missing.
************************************************************
Symbol search path is:
SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 2) UP Free x86
compatible
Product: LanManNt, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.070304-2240
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a8e48
Debug session time: Mon May 7 06:36:51.492 2007 (GMT-7)
System Uptime: 0 days 21:58:18.519
Loading Kernel Symbols
............................................................................­.....................................................
Loading User Symbols

Loading unloaded module list
..........
***************************************************************************­****
*
*
* Bugcheck Analysis
*
*
*
***************************************************************************­****

Use !analyze -v to get detailed debugging information.

BugCheck 20, {0, ffff, 0, 1}

*** WARNING: Unable to verify timestamp for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for
mssmbios.sys
Probably caused by : srv.sys ( srv!SrvTerminateWorkerThread+57 )

Followup: MachineOwner
---------

kd> !analyze -v
***************************************************************************­****
*
*
* Bugcheck Analysis
*
*
*
***************************************************************************­****

KERNEL_APC_PENDING_DURING_EXIT(20)
The key data item is the thread's APC disable count.
If this is non-zero, then this is the source of the problem.
The APC disable count is decremented each time a driver calls
KeEnterCriticalRegion, KeInitializeMutex, or FsRtlEnterFileSystem. The APC
disable count is incremented each time a driver calls KeLeaveCriticalRegion,
KeReleaseMutex, or FsRtlExitFileSystem. Since these calls should always be
in
pairs, this value should be zero when a thread exits. A negative value
indicates that a driver has disabled APC calls without re-enabling them. A
positive value indicates that the reverse is true.
If you ever see this error, be very suspicious of all drivers installed on
the
machine -- especially unusual or non-standard drivers. Third party file
system redirectors are especially suspicious since they do not generally
receive the heavy duty testing that NTFS, FAT, RDR, etc receive.
This current IRQL should also be 0. If it is not, that a driver's
cancelation routine can cause this bugcheck by returning at an elevated
IRQL. Always attempt to note what you were doing/closing at the
time of the crash, and note all of the installed drivers at the time of
the crash. This symptom is usually a severe bug in a third party
driver.
Arguments:
Arg1: 00000000, The address of the APC found pending during exit.
Arg2: 0000ffff, The thread's APC disable count
Arg3: 00000000, The current IRQL
Arg4: 00000001

Debugging Details:
------------------

BUGCHECK_STR: 0x20_NULLAPC_KAPC_NEGATIVE

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 8095b0d0 to 80876ae0

STACK_TEXT:
b9d2fcac 8095b0d0 00000020 00000000 0000ffff nt!KeBugCheckEx+0x1b
b9d2fd44 8090a5d6 00000000 00000102 00000000 nt!PspExitThread+0x64c
b9d2fd5c 8092581f 822a9a38 00000000 00000001
nt!PspTerminateThreadByPointer+0x4b
b9d2fd70 ba76291d 00000000 8229b720 00000010 nt!PsTerminateSystemThread+0x26
b9d2fd84 ba77d399 00000000 822a9a38 00000000
srv!SrvTerminateWorkerThread+0x57
b9d2fdac 80905b6b 0129b720 00000000 00000000 srv!WorkerThread+0xa1
b9d2fddc 808286ed ba776602 8229b720 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
srv!SrvTerminateWorkerThread+57
ba76291d 5e pop esi

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: srv!SrvTerminateWorkerThread+57

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: srv

IMAGE_NAME: srv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d6a048

FAILURE_BUCKET_ID:
0x20_NULLAPC_KAPC_NEGATIVE_srv!SrvTerminateWorkerThread+57

BUCKET_ID: 0x20_NULLAPC_KAPC_NEGATIVE_srv!SrvTerminateWorkerThread+57

Followup: MachineOwner
---------

I had the same issue a while back. I found a fix on Symantec to get
rid of a certain file. This would only work temporarily. Once I
upgraded to Symantec Anti Virus 10 it fixed my reboots.

.

Quantcast