Windows 2003 server reboots continously

NTDEV
1

Hello All,
I got the below dump. I don't see my module in the below call stack.. Can some one point me on how to proceed further or should i send it to MS?

!analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: e060f7a9, The address that the exception occurred at
Arg3: f5912bc8, Exception Record Address
Arg4: f59128c4, 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:
nt!CcFlushCache+1c9
e060f7a9 f6400420 test byte ptr [eax+4],20h

EXCEPTION_RECORD: f5912bc8 -- (.exr 0xfffffffff5912bc8)
ExceptionAddress: e060f7a9 (nt!CcFlushCache+0x000001c9)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000004
Attempt to read from address 00000004

CONTEXT: f59128c4 -- (.cxr 0xfffffffff59128c4)
eax=00000000 ebx=00000000 ecx=e06b6000 edx=00000000 esi=fcf879f0 edi=00000000
eip=e060f7a9 esp=f5912c90 ebp=f5912cfc iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
nt!CcFlushCache+0x1c9:
e060f7a9 f6400420 test byte ptr [eax+4],20h ds:0023:00000004=??
Resetting default scope

PROCESS_NAME: System

CURRENT_IRQL: 0

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

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 00000004

READ_ADDRESS: 00000004

FOLLOWUP_IP:
nt!CcFlushCache+1c9
e060f7a9 f6400420 test byte ptr [eax+4],20h

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from e060fcff to e060f7a9

STACK_TEXT:
f5912cfc e060fcff fe4e7514 00000000 00000001 nt!CcFlushCache+0x1c9
f5912d40 e061291e ff9823b8 e06b0620 ff96a290 nt!CcWriteBehind+0x11b
f5912d80 e06820cf ff96a290 00000000 ff9823b8 nt!CcWorkerThread+0x15a
f5912dac e074c09a ff96a290 00000000 00000000 nt!ExpWorkerThread+0xeb
f5912ddc e068fd1e e0681fe4 00000000 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!CcFlushCache+1c9

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4b7a7fd2

STACK_COMMAND: .cxr 0xfffffffff59128c4 ; kb

FAILURE_BUCKET_ID: 0x7E_nt!CcFlushCache+1c9

BUCKET_ID: 0x7E_nt!CcFlushCache+1c9

Followup: MachineOwner

2

xxxxx@gmail.com wrote:

Hello All,
I got the below dump. I don’t see my module in the below call stack… Can some one point me on how to proceed further or should i send it to MS?

What kind of a driver are you writing? This looks like a file system
driver is dereferencing a null pointer. That usually means your driver
has overwritten memory somewhere.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

>What kind of a driver are you writing? This looks like a file system

driver is dereferencing a null pointer. That usually means your driver
has overwritten memory somewhere.

I am just trying to analyze the rootcause, I am not the actual developer of
the drivers:) We do have Filesystem drivers but not sure how to proceed
further. How to get to the failing call stack? I ran !process 0 7 and i
don’t see any call stacks leading to KeBugCheckEx(). Pls. suggest…

On Thu, Dec 9, 2010 at 2:06 PM, Tim Roberts wrote:

> xxxxx@gmail.com wrote:
> > Hello All,
> > I got the below dump. I don’t see my module in the below call stack…
> Can some one point me on how to proceed further or should i send it to MS?
>
> What kind of a driver are you writing? This looks like a file system
> driver is dereferencing a null pointer. That usually means your driver
> has overwritten memory somewhere.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

Suren R Gundumalla wrote:

>What kind of a driver are you writing? This looks like a file system
>driver is dereferencing a null pointer. That usually means your driver
>has overwritten memory somewhere.

I am just trying to analyze the rootcause, I am not the actual
developer of the drivers:) We do have Filesystem drivers but not sure
how to proceed further. How to get to the failing call stack? I ran
!process 0 7 and i don’t see any call stacks leading to
KeBugCheckEx(). Pls. suggest…

No, this was a background system thread. If it was a memory overwrite,
that kind of thing is very, very difficult to chase down. The first
thing I would do is enable Driver Verifier on your driver, making sure
that Special Pool is turned on.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

>No, this was a background system thread. If it was a memory overwrite,

that kind of thing is very, very difficult to chase down. The first
thing I would do is enable Driver Verifier on your driver, making sure
that Special Pool is turned on.

Driver verifier is enabled in the dump. So look for paged pool /nonpaged
pool tags?

On Thu, Dec 9, 2010 at 2:33 PM, Tim Roberts wrote:

>
> > >What kind of a driver are you writing? This looks like a file system
> > >driver is dereferencing a null pointer. That usually means your driver
> > >has overwritten memory somewhere.
> >
> > I am just trying to analyze the rootcause, I am not the actual
> > developer of the drivers:) We do have Filesystem drivers but not sure
> > how to proceed further. How to get to the failing call stack? I ran
> > !process 0 7 and i don’t see any call stacks leading to
> > KeBugCheckEx(). Pls. suggest…
>
> No, this was a background system thread. If it was a memory overwrite,
> that kind of thing is very, very difficult to chase down. The first
> thing I would do is enable Driver Verifier on your driver, making sure
> that Special Pool is turned on.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

6

It’s also possible that some structure is not initialized completely, or something like that.

You can disassemble the function (‘uf nt!CcFlushCache’) and check where the bad value in eax came from (a function parameter, or a field in some struct etc). Or you could set a breakpoint on this address and see what’s in eax when things work normally.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of SRG
Sent: Thursday, December 09, 2010 4:16 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows 2003 server reboots continously

No, this was a background system thread. If it was a memory overwrite,
that kind of thing is very, very difficult to chase down. The first
thing I would do is enable Driver Verifier on your driver, making sure
that Special Pool is turned on.
Driver verifier is enabled in the dump. So look for paged pool /nonpaged pool tags?

On Thu, Dec 9, 2010 at 2:33 PM, Tim Roberts > wrote:

> >What kind of a driver are you writing? This looks like a file system
> >driver is dereferencing a null pointer. That usually means your driver
> >has overwritten memory somewhere.
>
> I am just trying to analyze the rootcause, I am not the actual
> developer of the drivers:) We do have Filesystem drivers but not sure
> how to proceed further. How to get to the failing call stack? I ran
> !process 0 7 and i don’t see any call stacks leading to
> KeBugCheckEx(). Pls. suggest…
No, this was a background system thread. If it was a memory overwrite,
that kind of thing is very, very difficult to chase down. The first
thing I would do is enable Driver Verifier on your driver, making sure
that Special Pool is turned on.

–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>

7

This turned out to be a pre existing issue with ntkrpamp.exe.

Final solution is below :slight_smile:
http://support.microsoft.com/kb/978243