Groups > Microsoft > WinDbg > Re: NAS Server Restart similiar time each day




NAS Server Restart similiar time each day

NAS Server Restart similiar time each day
Sun, 13 Apr 2008 16:27:00 -070
We have a DL100 with Windows Storage server 2003 installed on it. The server 
is just file server and hase backup exec 12.0 installed. It restarts each 
night at about 12:40am give or take a few minutes each day. 
I need help finding out what the debugging means. Here is the code from windbg
Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini041408-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: 
srv*f:\symbols\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (2 procs) Free 
x86 compatible
Product: Server, suite: TerminalServer SingleUserTS StorageServer
Built by: 3790.srv03_sp2_gdr.070304-2240
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
Debug session time: Mon Apr 14 00:39:57.140 2008 (GMT+10)
System Uptime: 0 days 23:56:43.937
Loading Kernel Symbols
................................................................................
.....................................
Loading User Symbols
Loading unloaded module list
...
*******************************************************************************
*                                                                            
 *
*                        Bugcheck Analysis                                   
 *
*                                                                            
 *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007E, {c0000005, 0, f59258e8, f59255e4}



Probably caused by : Pool_Corruption ( nt!ExFreePool+17 )

Followup: Pool_corruption
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                            
 *
*                        Bugcheck Analysis                                   
 *
*                                                                            
 *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 00000000, The address that the exception occurred at
Arg3: f59258e8, Exception Record Address
Arg4: f59255e4, Context Record Address

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




EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" 
referenced memory at "0x%08lx". The memory could not be
"%s".

FAULTING_IP: 
+0
00000000 0000            add     byte ptr [eax],al

EXCEPTION_RECORD:  f59258e8 -- (.exr 0xfffffffff59258e8)
ExceptionAddress: 00000000
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000008
   Parameter[1]: 00000000
Attempt to execute non-executable address 00000000

CONTEXT:  f59255e4 -- (.cxr 0xfffffffff59255e4)
eax=00000000 ebx=00000000 ecx=808f9f65 edx=a22d0003 esi=823ea320 edi=00000001
eip=00000000 esp=f59259b0 ebp=f59259f0 iopl=0         nv up ei ng nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010286
00000000 0000            add     byte ptr [eax],al          
ds:0023:00000000=00
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT_SERVER_MINIDUMP

CURRENT_IRQL:  0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"
referenced 
memory at "0x%08lx". The memory could not be "%s".

WRITE_ADDRESS:  00000000 

FAILED_INSTRUCTION_ADDRESS: 
+0
00000000 0000            add     byte ptr [eax],al

BUGCHECK_STR:  0x7E

EXCEPTION_STR:  0x0

LAST_CONTROL_TRANSFER:  from 80892b77 to 00000000

STACK_TEXT:  
WARNING: Frame IP not in any known module. Following frames may be wrong.
f59259ac 80892b77 80938540 e3f270d0 00000000 0x0
f59259f0 f4d99f8c 8000aef8 00000007 e3f27e70 nt!ExFreePool+0x17
f5925b68 f4db3318 e3f27000 8000aef8 fa23dd70 
nfssvr!NfsGetOpenFileAttributes2+0x676
f5925cf8 f4db1cfa e3f27000 00000002 fa23d600 nfssvr!NfsSetAttr+0xe2a
f5925d50 f4dc0e9d 85692630 00000000 fa23d63c nfssvr!NfsInPacketInternal+0x970
f5925d64 f57a62fc 85692630 00000000 fa23d63c nfssvr!NfsInPacket+0x19
f5925dac 80949b7c 0000000b 00000000 00000000 rpcxdr!RxWorkThread+0x308
f5925ddc 8088e062 f57a5ff4 0000000b 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP: 
nt!ExFreePool+17
80892b77 cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!ExFreePool+17

FOLLOWUP_NAME:  Pool_corruption

IMAGE_NAME:  Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MODULE_NAME: Pool_Corruption

STACK_COMMAND:  .cxr 0xfffffffff59255e4 ; kb

FAILURE_BUCKET_ID:  0x7E_NULL_IP_nt!ExFreePool+17

BUCKET_ID:  0x7E_NULL_IP_nt!ExFreePool+17

Post Reply
Re: NAS Server Restart similiar time each day
Wed, 16 Apr 2008 11:31:08 -070
Try to enalbe special pool on nfssrv.sys `verifier.exe /driver nfssrv.sys`
and try to repro under KD.
If you get a repro, I would recomend escalating this to PSS team of your 
country.

-- 

-- 
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Ian Zahn" <IanZahn@discussions.microsoft.com> wrote in message

news:748C64E3-64D0-4D4D-BE4D-DE22057395ED@microsoft.com...
> We have a DL100 with Windows Storage server 2003 installed on it. The 
> server
> is just file server and hase backup exec 12.0 installed. It restarts each
> night at about 12:40am give or take a few minutes each day.
> I need help finding out what the debugging means. Here is the code from 
> windbg
> Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [C:\WINDOWS\Minidump\Mini041408-01.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
> Symbol search path is:
> srv*f:\symbols\websymbols*http://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (2 procs) Free
> x86 compatible
> Product: Server, suite: TerminalServer SingleUserTS StorageServer
> Built by: 3790.srv03_sp2_gdr.070304-2240
> Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
> Debug session time: Mon Apr 14 00:39:57.140 2008 (GMT+10)
> System Uptime: 0 days 23:56:43.937
> Loading Kernel Symbols
>
................................................................................
.....................................
> Loading User Symbols
> Loading unloaded module list
> ...
>
*******************************************************************************
> *
> *
> *                        Bugcheck Analysis
> *
> *
> *
>
*******************************************************************************
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 1000007E, {c0000005, 0, f59258e8, f59255e4}
>
>
>
> Probably caused by : Pool_Corruption ( nt!ExFreePool+17 )
>
> Followup: Pool_corruption
> ---------
>
> 0: kd> !analyze -v
>
*******************************************************************************
> *
> *
> *                        Bugcheck Analysis
> *
> *
> *
>
*******************************************************************************
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
> This is a very common bugcheck.  Usually the exception address pinpoints
> the driver/function that caused the problem.  Always note this address
> as well as the link date of the driver/image that contains this address.
> Some common problems are exception code 0x80000003.  This means a hard
> coded breakpoint or assertion was hit, but this system was booted
> /NODEBUG.  This is not supposed to happen as developers should never have
> hardcoded breakpoints in retail code, but ...
> If this happens, make sure a debugger gets connected, and the
> system is booted /DEBUG.  This will let us see why this breakpoint is
> happening.
> Arguments:
> Arg1: c0000005, The exception code that was not handled
> Arg2: 00000000, The address that the exception occurred at
> Arg3: f59258e8, Exception Record Address
> Arg4: f59255e4, Context Record Address
>
> Debugging Details:
> ------------------
>
>
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at
"0x%08lx"
> referenced memory at "0x%08lx". The memory could not be
"%s".
>
> FAULTING_IP:
> +0
> 00000000 0000            add     byte ptr [eax],al
>
> EXCEPTION_RECORD:  f59258e8 -- (.exr 0xfffffffff59258e8)
> ExceptionAddress: 00000000
>   ExceptionCode: c0000005 (Access violation)
>  ExceptionFlags: 00000000
> NumberParameters: 2
>   Parameter[0]: 00000008
>   Parameter[1]: 00000000
> Attempt to execute non-executable address 00000000
>
> CONTEXT:  f59255e4 -- (.cxr 0xfffffffff59255e4)
> eax=00000000 ebx=00000000 ecx=808f9f65 edx=a22d0003 esi=823ea320 
> edi=00000001
> eip=00000000 esp=f59259b0 ebp=f59259f0 iopl=0         nv up ei ng nz na pe

> nc
> cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000 
> efl=00010286
> 00000000 0000            add     byte ptr [eax],al
> ds:0023:00000000=00
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT:  1
>
> DEFAULT_BUCKET_ID:  DRIVER_FAULT_SERVER_MINIDUMP
>
> CURRENT_IRQL:  0
>
> ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"

> referenced
> memory at "0x%08lx". The memory could not be "%s".
>
> WRITE_ADDRESS:  00000000
>
> FAILED_INSTRUCTION_ADDRESS:
> +0
> 00000000 0000            add     byte ptr [eax],al
>
> BUGCHECK_STR:  0x7E
>
> EXCEPTION_STR:  0x0
>
> LAST_CONTROL_TRANSFER:  from 80892b77 to 00000000
>
> STACK_TEXT:
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> f59259ac 80892b77 80938540 e3f270d0 00000000 0x0
> f59259f0 f4d99f8c 8000aef8 00000007 e3f27e70 nt!ExFreePool+0x17
> f5925b68 f4db3318 e3f27000 8000aef8 fa23dd70
> nfssvr!NfsGetOpenFileAttributes2+0x676
> f5925cf8 f4db1cfa e3f27000 00000002 fa23d600 nfssvr!NfsSetAttr+0xe2a
> f5925d50 f4dc0e9d 85692630 00000000 fa23d63c 
> nfssvr!NfsInPacketInternal+0x970
> f5925d64 f57a62fc 85692630 00000000 fa23d63c nfssvr!NfsInPacket+0x19
> f5925dac 80949b7c 0000000b 00000000 00000000 rpcxdr!RxWorkThread+0x308
> f5925ddc 8088e062 f57a5ff4 0000000b 00000000 
> nt!PspSystemThreadStartup+0x2e
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> nt!ExFreePool+17
> 80892b77 cc              int     3
>
> SYMBOL_STACK_INDEX:  1
>
> SYMBOL_NAME:  nt!ExFreePool+17
>
> FOLLOWUP_NAME:  Pool_corruption
>
> IMAGE_NAME:  Pool_Corruption
>
> DEBUG_FLR_IMAGE_TIMESTAMP:  0
>
> MODULE_NAME: Pool_Corruption
>
> STACK_COMMAND:  .cxr 0xfffffffff59255e4 ; kb
>
> FAILURE_BUCKET_ID:  0x7E_NULL_IP_nt!ExFreePool+17
>
> BUCKET_ID:  0x7E_NULL_IP_nt!ExFreePool+17
>
> Followup: Pool_corruption 

Post Reply
about | contact