a blue screen and it's not my fault?

NTFSD
1

Below is a bugcheck but according to the stack…it doesn’t look like it’s
my mini-drivers fault!

But.I’m skeptical of that since I just moved a bunch of variables off the
heap to a lookaside.

Now.I do have verifier running (monitoring just my driver) but it might be
making other drivers freak out somehow.

Should I just ignore this bugcheck?

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

0: kd> !analyze -v

* *

* Bugcheck Analysis *

* *

*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)

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: 80580570, The address that the exception occurred at

Arg3: f3e5ab8c, Trap Frame

Arg4: 00000000

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!CmpReportNotifyHelper+44

80580570 8b5610 mov edx,[esi+0x10]

TRAP_FRAME: f3e5ab8c – (.trap fffffffff3e5ab8c)

ErrCode = 00000000

eax=00000000 ebx=e329c440 ecx=e1036248 edx=e1036a70 esi=0000045b
edi=e1d7db60

eip=80580570 esp=f3e5ac00 ebp=f3e5ac18 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202

nt!CmpReportNotifyHelper+0x44:

80580570 8b5610 mov edx,[esi+0x10] ds:0023:0000046b=???

Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 80580524 to 80580570

STACK_TEXT:

f3e5ac18 80580524 e329c440 e1030008 00d7db60 nt!CmpReportNotifyHelper+0x44

f3e5ac40 80580176 e329c440 e1d7db60 01af74b8 nt!CmpReportNotify+0x87

f3e5acb0 8057fff7 e329c440 f3e5ad08 00000004 nt!CmSetValueKey+0x24b

f3e5ad44 804dd99f 00000854 0173f568 00000000 nt!NtSetValueKey+0x228

f3e5ad44 7c90eb94 00000854 0173f568 00000000 nt!KiFastCallEntry+0xfc

0173f4f8 7c90e7c8 77ddd796 00000854 0173f568 ntdll!KiFastSystemCallRet

0173f4fc 77ddd796 00000854 0173f568 00000000 ntdll!ZwSetValueKey+0xc

0173f540 77ddd89d 00000854 0173f568 00000004
ADVAPI32!LocalBaseRegSetValue+0x12c

0173f58c 769d50e9 00000854 769d42f8 00000000 ADVAPI32!RegSetValueExW+0x108

0173f7dc 769d4d3a 00ea6f58 00000000 0173fc70 USERENV!SaveLoggingStatus+0x146

0173fec8 769ef454 00e7d510 01076000 011dfaa8 USERENV!ProcessGPOs+0x227e

0173ffb4 7c80b50b 00e7d510 01076000 011dfaa8 USERENV!GPOThread+0x3b4

0173ffec 00000000 769d3cf1 00e7d510 00000000 kernel32!BaseThreadStart+0x37

FOLLOWUP_IP:

nt!CmpReportNotifyHelper+44

80580570 8b5610 mov edx,[esi+0x10]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!CmpReportNotifyHelper+44

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77

STACK_COMMAND: .trap fffffffff3e5ab8c ; kb

FAILURE_BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44

BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44

Followup: MachineOwner

2

With respect, it’s more’n likely your fault. :wink:

See if you can make it happen. Then see if you can make it happen without
your driver loaded. That’ll give you a hint…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
Sent: Tuesday, December 13, 2005 5:43 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] a blue screen and it’s not my fault?

Below is a bugcheck but according to the stack…it doesn’t look like it’s
my mini-drivers fault!

But.I’m skeptical of that since I just moved a bunch of variables off the
heap to a lookaside.

Now.I do have verifier running (monitoring just my driver) but it might be
making other drivers freak out somehow.

Should I just ignore this bugcheck?

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

0: kd> !analyze -v

* *

* Bugcheck Analysis *

* *

****************************************************************************
***

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)

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: 80580570, The address that the exception occurred at

Arg3: f3e5ab8c, Trap Frame

Arg4: 00000000

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!CmpReportNotifyHelper+44

80580570 8b5610 mov edx,[esi+0x10]

TRAP_FRAME: f3e5ab8c – (.trap fffffffff3e5ab8c)

ErrCode = 00000000

eax=00000000 ebx=e329c440 ecx=e1036248 edx=e1036a70 esi=0000045b
edi=e1d7db60

eip=80580570 esp=f3e5ac00 ebp=f3e5ac18 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202

nt!CmpReportNotifyHelper+0x44:

80580570 8b5610 mov edx,[esi+0x10] ds:0023:0000046b=???

Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 80580524 to 80580570

STACK_TEXT:

f3e5ac18 80580524 e329c440 e1030008 00d7db60 nt!CmpReportNotifyHelper+0x44

f3e5ac40 80580176 e329c440 e1d7db60 01af74b8 nt!CmpReportNotify+0x87

f3e5acb0 8057fff7 e329c440 f3e5ad08 00000004 nt!CmSetValueKey+0x24b

f3e5ad44 804dd99f 00000854 0173f568 00000000 nt!NtSetValueKey+0x228

f3e5ad44 7c90eb94 00000854 0173f568 00000000 nt!KiFastCallEntry+0xfc

0173f4f8 7c90e7c8 77ddd796 00000854 0173f568 ntdll!KiFastSystemCallRet

0173f4fc 77ddd796 00000854 0173f568 00000000 ntdll!ZwSetValueKey+0xc

0173f540 77ddd89d 00000854 0173f568 00000004
ADVAPI32!LocalBaseRegSetValue+0x12c

0173f58c 769d50e9 00000854 769d42f8 00000000 ADVAPI32!RegSetValueExW+0x108

0173f7dc 769d4d3a 00ea6f58 00000000 0173fc70 USERENV!SaveLoggingStatus+0x146

0173fec8 769ef454 00e7d510 01076000 011dfaa8 USERENV!ProcessGPOs+0x227e

0173ffb4 7c80b50b 00e7d510 01076000 011dfaa8 USERENV!GPOThread+0x3b4

0173ffec 00000000 769d3cf1 00e7d510 00000000 kernel32!BaseThreadStart+0x37

FOLLOWUP_IP:

nt!CmpReportNotifyHelper+44

80580570 8b5610 mov edx,[esi+0x10]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!CmpReportNotifyHelper+44

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77

STACK_COMMAND: .trap fffffffff3e5ab8c ; kb

FAILURE_BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44

BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44

Followup: MachineOwner

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

lol!
Yeah, I figure it’s me, but it happens sooooo rarely that can’t imagine how
to reproduce it.
It’s like I intercept a couple of million file operations and then boom!

I got a different one this last time…BAD_POOL_CALLER which is also
probably me, but I can’t see how since I do ONE pool allocate
(ExAllocatePoolWithTag) in the DriverEntry routine and One Free
(ExFreePoolWithTag) in the Unload routine.

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> With respect, it’s more’n likely your fault. :wink:
>
> See if you can make it happen. Then see if you can make it happen without
> your driver loaded. That’ll give you a hint…
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
> Sent: Tuesday, December 13, 2005 5:43 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] a blue screen and it’s not my fault?
>
> Below is a bugcheck but according to the stack…it doesn’t look like it’s
> my mini-drivers fault!
>
> But.I’m skeptical of that since I just moved a bunch of variables off the
> heap to a lookaside.
>
>
>
> Now.I do have verifier running (monitoring just my driver) but it might be
> making other drivers freak out somehow.
>
>
>
> Should I just ignore this bugcheck?
>
>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> 0: kd> !analyze -v
>
> * *
>
> * Bugcheck Analysis *
>
> * *
>
> *************************************************************************
>
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
>
> 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: 80580570, The address that the exception occurred at
>
> Arg3: f3e5ab8c, Trap Frame
>
> Arg4: 00000000
>
> 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!CmpReportNotifyHelper+44
>
> 80580570 8b5610 mov edx,[esi+0x10]
>
> TRAP_FRAME: f3e5ab8c – (.trap fffffffff3e5ab8c)
>
> ErrCode = 00000000
>
> eax=00000000 ebx=e329c440 ecx=e1036248 edx=e1036a70 esi=0000045b
> edi=e1d7db60
>
> eip=80580570 esp=f3e5ac00 ebp=f3e5ac18 iopl=0 nv up ei pl nz na pe nc
>
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
>
> nt!CmpReportNotifyHelper+0x44:
>
> 80580570 8b5610 mov edx,[esi+0x10] ds:0023:0000046b=???
>
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 80580524 to 80580570
>
> STACK_TEXT:
>
> f3e5ac18 80580524 e329c440 e1030008 00d7db60 nt!CmpReportNotifyHelper+0x44
>
> f3e5ac40 80580176 e329c440 e1d7db60 01af74b8 nt!CmpReportNotify+0x87
>
> f3e5acb0 8057fff7 e329c440 f3e5ad08 00000004 nt!CmSetValueKey+0x24b
>
> f3e5ad44 804dd99f 00000854 0173f568 00000000 nt!NtSetValueKey+0x228
>
> f3e5ad44 7c90eb94 00000854 0173f568 00000000 nt!KiFastCallEntry+0xfc
>
> 0173f4f8 7c90e7c8 77ddd796 00000854 0173f568 ntdll!KiFastSystemCallRet
>
> 0173f4fc 77ddd796 00000854 0173f568 00000000 ntdll!ZwSetValueKey+0xc
>
> 0173f540 77ddd89d 00000854 0173f568 00000004
> ADVAPI32!LocalBaseRegSetValue+0x12c
>
> 0173f58c 769d50e9 00000854 769d42f8 00000000 ADVAPI32!RegSetValueExW+0x108
>
> 0173f7dc 769d4d3a 00ea6f58 00000000 0173fc70
> USERENV!SaveLoggingStatus+0x146
>
> 0173fec8 769ef454 00e7d510 01076000 011dfaa8 USERENV!ProcessGPOs+0x227e
>
> 0173ffb4 7c80b50b 00e7d510 01076000 011dfaa8 USERENV!GPOThread+0x3b4
>
> 0173ffec 00000000 769d3cf1 00e7d510 00000000 kernel32!BaseThreadStart+0x37
>
>
>
> FOLLOWUP_IP:
>
> nt!CmpReportNotifyHelper+44
>
> 80580570 8b5610 mov edx,[esi+0x10]
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!CmpReportNotifyHelper+44
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrnlmp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77
>
> STACK_COMMAND: .trap fffffffff3e5ab8c ; kb
>
> FAILURE_BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44
>
> BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44
>
> Followup: MachineOwner
>
> ---------
>
>
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

4

Sounds like perhaps you have a memory scribble of some sort. Those are,
indeed, a challenge to track down and fix, but the worst of the lot
manifest as “random crashes” similar to the type you describe. In my
experience you often need to collect and analyze a number of them before
the pattern emerges.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
Sent: Tuesday, December 13, 2005 6:29 PM
To: ntfsd redirect
Subject: Re:[ntfsd] a blue screen and it’s not my fault?

lol!
Yeah, I figure it’s me, but it happens sooooo rarely that can’t imagine
how
to reproduce it.
It’s like I intercept a couple of million file operations and then boom!

I got a different one this last time…BAD_POOL_CALLER which is also
probably me, but I can’t see how since I do ONE pool allocate
(ExAllocatePoolWithTag) in the DriverEntry routine and One Free
(ExFreePoolWithTag) in the Unload routine.

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> With respect, it’s more’n likely your fault. :wink:
>
> See if you can make it happen. Then see if you can make it happen
without
> your driver loaded. That’ll give you a hint…
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
> Sent: Tuesday, December 13, 2005 5:43 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] a blue screen and it’s not my fault?
>
> Below is a bugcheck but according to the stack…it doesn’t look like
it’s
> my mini-drivers fault!
>
> But.I’m skeptical of that since I just moved a bunch of variables off
the
> heap to a lookaside.
>
>
>
> Now.I do have verifier running (monitoring just my driver) but it
might be
> making other drivers freak out somehow.
>
>
>
> Should I just ignore this bugcheck?
>
>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> 0: kd> !analyze -v
>
> * *
>
> * Bugcheck Analysis *
>
> * *
>
>
********************************************************************
> ***
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
>
> 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: 80580570, The address that the exception occurred at
>
> Arg3: f3e5ab8c, Trap Frame
>
> Arg4: 00000000
>
> 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!CmpReportNotifyHelper+44
>
> 80580570 8b5610 mov edx,[esi+0x10]
>
> TRAP_FRAME: f3e5ab8c – (.trap fffffffff3e5ab8c)
>
> ErrCode = 00000000
>
> eax=00000000 ebx=e329c440 ecx=e1036248 edx=e1036a70 esi=0000045b
> edi=e1d7db60
>
> eip=80580570 esp=f3e5ac00 ebp=f3e5ac18 iopl=0 nv up ei pl nz na pe nc
>
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
>
> nt!CmpReportNotifyHelper+0x44:
>
> 80580570 8b5610 mov edx,[esi+0x10] ds:0023:0000046b=???
>
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 80580524 to 80580570
>
> STACK_TEXT:
>
> f3e5ac18 80580524 e329c440 e1030008 00d7db60
nt!CmpReportNotifyHelper+0x44
>
> f3e5ac40 80580176 e329c440 e1d7db60 01af74b8 nt!CmpReportNotify+0x87
>
> f3e5acb0 8057fff7 e329c440 f3e5ad08 00000004 nt!CmSetValueKey+0x24b
>
> f3e5ad44 804dd99f 00000854 0173f568 00000000 nt!NtSetValueKey+0x228
>
> f3e5ad44 7c90eb94 00000854 0173f568 00000000 nt!KiFastCallEntry+0xfc
>
> 0173f4f8 7c90e7c8 77ddd796 00000854 0173f568 ntdll!KiFastSystemCallRet
>
> 0173f4fc 77ddd796 00000854 0173f568 00000000 ntdll!ZwSetValueKey+0xc
>
> 0173f540 77ddd89d 00000854 0173f568 00000004
> ADVAPI32!LocalBaseRegSetValue+0x12c
>
> 0173f58c 769d50e9 00000854 769d42f8 00000000
ADVAPI32!RegSetValueExW+0x108
>
> 0173f7dc 769d4d3a 00ea6f58 00000000 0173fc70
> USERENV!SaveLoggingStatus+0x146
>
> 0173fec8 769ef454 00e7d510 01076000 011dfaa8
USERENV!ProcessGPOs+0x227e
>
> 0173ffb4 7c80b50b 00e7d510 01076000 011dfaa8 USERENV!GPOThread+0x3b4
>
> 0173ffec 00000000 769d3cf1 00e7d510 00000000
kernel32!BaseThreadStart+0x37
>
>
>
> FOLLOWUP_IP:
>
> nt!CmpReportNotifyHelper+44
>
> 80580570 8b5610 mov edx,[esi+0x10]
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!CmpReportNotifyHelper+44
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrnlmp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77
>
> STACK_COMMAND: .trap fffffffff3e5ab8c ; kb
>
> FAILURE_BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44
>
> BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44
>
> Followup: MachineOwner
>
> ---------
>
>
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

I think I found it…I was allocating my lookaside lists in non paged memory
(D’oh!) I switched to using paged memory and so far no BSODs even though I’m
running a big stress test.

All I can figure is that the non-paged memory was getting fragmented by my
heavily used lookasides and after a while a different driver got upset

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Sounds like perhaps you have a memory scribble of some sort. Those are,
indeed, a challenge to track down and fix, but the worst of the lot
manifest as “random crashes” similar to the type you describe. In my
experience you often need to collect and analyze a number of them before
the pattern emerges.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
Sent: Tuesday, December 13, 2005 6:29 PM
To: ntfsd redirect
Subject: Re:[ntfsd] a blue screen and it’s not my fault?

lol!
Yeah, I figure it’s me, but it happens sooooo rarely that can’t imagine
how
to reproduce it.
It’s like I intercept a couple of million file operations and then boom!

I got a different one this last time…BAD_POOL_CALLER which is also
probably me, but I can’t see how since I do ONE pool allocate
(ExAllocatePoolWithTag) in the DriverEntry routine and One Free
(ExFreePoolWithTag) in the Unload routine.

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> With respect, it’s more’n likely your fault. :wink:
>
> See if you can make it happen. Then see if you can make it happen
without
> your driver loaded. That’ll give you a hint…
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
> Sent: Tuesday, December 13, 2005 5:43 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] a blue screen and it’s not my fault?
>
> Below is a bugcheck but according to the stack…it doesn’t look like
it’s
> my mini-drivers fault!
>
> But.I’m skeptical of that since I just moved a bunch of variables off
the
> heap to a lookaside.
>
>
>
> Now.I do have verifier running (monitoring just my driver) but it
might be
> making other drivers freak out somehow.
>
>
>
> Should I just ignore this bugcheck?
>
>
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> 0: kd> !analyze -v
>
> * *
>
> * Bugcheck Analysis *
>
> * *
>
>
********************************************************************
> ***
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
>
> 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: 80580570, The address that the exception occurred at
>
> Arg3: f3e5ab8c, Trap Frame
>
> Arg4: 00000000
>
> 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!CmpReportNotifyHelper+44
>
> 80580570 8b5610 mov edx,[esi+0x10]
>
> TRAP_FRAME: f3e5ab8c – (.trap fffffffff3e5ab8c)
>
> ErrCode = 00000000
>
> eax=00000000 ebx=e329c440 ecx=e1036248 edx=e1036a70 esi=0000045b
> edi=e1d7db60
>
> eip=80580570 esp=f3e5ac00 ebp=f3e5ac18 iopl=0 nv up ei pl nz na pe nc
>
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
>
> nt!CmpReportNotifyHelper+0x44:
>
> 80580570 8b5610 mov edx,[esi+0x10] ds:0023:0000046b=???
>
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 80580524 to 80580570
>
> STACK_TEXT:
>
> f3e5ac18 80580524 e329c440 e1030008 00d7db60
nt!CmpReportNotifyHelper+0x44
>
> f3e5ac40 80580176 e329c440 e1d7db60 01af74b8 nt!CmpReportNotify+0x87
>
> f3e5acb0 8057fff7 e329c440 f3e5ad08 00000004 nt!CmSetValueKey+0x24b
>
> f3e5ad44 804dd99f 00000854 0173f568 00000000 nt!NtSetValueKey+0x228
>
> f3e5ad44 7c90eb94 00000854 0173f568 00000000 nt!KiFastCallEntry+0xfc
>
> 0173f4f8 7c90e7c8 77ddd796 00000854 0173f568 ntdll!KiFastSystemCallRet
>
> 0173f4fc 77ddd796 00000854 0173f568 00000000 ntdll!ZwSetValueKey+0xc
>
> 0173f540 77ddd89d 00000854 0173f568 00000004
> ADVAPI32!LocalBaseRegSetValue+0x12c
>
> 0173f58c 769d50e9 00000854 769d42f8 00000000
ADVAPI32!RegSetValueExW+0x108
>
> 0173f7dc 769d4d3a 00ea6f58 00000000 0173fc70
> USERENV!SaveLoggingStatus+0x146
>
> 0173fec8 769ef454 00e7d510 01076000 011dfaa8
USERENV!ProcessGPOs+0x227e
>
> 0173ffb4 7c80b50b 00e7d510 01076000 011dfaa8 USERENV!GPOThread+0x3b4
>
> 0173ffec 00000000 769d3cf1 00e7d510 00000000
kernel32!BaseThreadStart+0x37
>
>
>
> FOLLOWUP_IP:
>
> nt!CmpReportNotifyHelper+44
>
> 80580570 8b5610 mov edx,[esi+0x10]
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!CmpReportNotifyHelper+44
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrnlmp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77
>
> STACK_COMMAND: .trap fffffffff3e5ab8c ; kb
>
> FAILURE_BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44
>
> BUCKET_ID: 0x8E_nt!CmpReportNotifyHelper+44
>
> Followup: MachineOwner
>
> ---------
>
>
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com