BSOD

Hi, I wrote a file system filter driver . And it will cause BSOD every several hours.
But from the kernel stack,it have no my driver’s finger . But indeed,it caused by my driver through i can’t figure it out .
It always dead in
nt!KeSetEvent+53
818f7c0f cmp byte ptr [eax+16h],bl
At this moment eax is 0.

This is one of my BSOD info .
Through it dead in different compnent and have different context, it always dead in nt!KeSetEvent+53 . My system is VISTA SP1.
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 818f7c0f, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000016

CURRENT_IRQL: 1b

FAULTING_IP:
nt!KeSetEvent+53
818f7c0f cmp byte ptr [eax+16h],bl

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: Defrag.exe

IRP_ADDRESS: ffffffc0

TRAP_FRAME: 9a05a784 – (.trap 0xffffffff9a05a784)
ErrCode = 00000000
eax=00000000 ebx=00000001 ecx=8197c3c0 edx=00000000 esi=9a059810 edi=9a059818
eip=818f7c0f esp=9a05a7f8 ebp=9a05a814 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!KeSetEvent+0x53:
818f7c0f cmp byte ptr [eax+16h],bl ds:0023:00000016=??
Resetting default scope

LAST_CONTROL_TRANSFER: from 819112d7 to 818fc514

STACK_TEXT:
9a05a344 819112d7 00000003 719a7207 00000000 nt!RtlpBreakWithStatusInstruction
9a05a394 81911dbd 00000003 00000016 818f7c0f nt!KiBugCheckDebugBreak+0x1c
9a05a764 8189ed84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
9a05a764 818f7c0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac
9a05a814 81885aef 9a059810 00000000 00000000 nt!KeSetEvent+0x53
9a05a864 81886022 00000000 9a05a890 9a05a89c nt!IopCompleteRequest+0x22b
9a05a8b8 818182f7 00000000 00000000 00000000 nt!KiDeliverApc+0xce
9a05a8d8 8181850c 86871201 00000000 868710e8 hal!HalpDispatchSoftwareInterrupt+0x49
9a05a8f4 818185b0 81881264 86871200 9a05a940 hal!HalpCheckForSoftwareInterrupt+0x64
9a05a904 8945567a 84f64f4c 84f64de0 868710e8 hal!KfLowerIrql+0x64
9a05a940 8945a06f 84f64de0 018710e8 818fffef flpydisk!FlQueueIrpToThread+0xf2
9a05a964 81900053 86871030 84f64f4c 00000000 flpydisk!FloppyDeviceControl+0x125
9a05a97c 894bf346 c000014f 00000000 86871030 nt!IofCallDriver+0x63
9a05a9cc 894c046e 86871030 9a05a9f4 00000000 Fs_Rec!FsRecGetDeviceSectorSize+0xfc
9a05a9fc 894bf0be 86bb6438 84fa33c0 86bb6438 Fs_Rec!ExFatRecFsControl+0x4c
9a05aa10 81900053 86bb6438 84fa33c0 81978e00 Fs_Rec!FsRecFsControl+0x60
9a05aa28 819e7a62 86871030 81815030 818150c0 nt!IofCallDriver+0x63
9a05aa8c 81888a3e 86871030 868c1d00 00000000 nt!IopMountVolume+0x1ce
9a05aabc 81a64498 868c1d20 9a05abe0 9a05ab78 nt!IopCheckVpbMounted+0x60
9a05ab98 81a8a2ff 86871030 00000000 93c47008 nt!IopParseDevice+0x7fe
9a05ac28 81a61fea 00000000 9a05ac80 00000040 nt!ObpLookupObjectName+0x5a8
9a05ac88 81a63ae7 002fe984 00000000 81a61301 nt!ObOpenObjectByName+0x13c
9a05acfc 81a5453d 002fe9c0 00100000 002fe984 nt!IopCreateFile+0x63b
9a05ad44 8189ba7a 002fe9c0 00100000 002fe984 nt!NtOpenFile+0x2a
9a05ad44 77979a94 002fe9c0 00100000 002fe984 nt!KiFastCallEntry+0x12a
002fe954 779787f4 76afe503 002fe9c0 00100000 ntdll!KiFastSystemCallRet
002fe958 76afe503 002fe9c0 00100000 002fe984 ntdll!ZwOpenFile+0xc
002fe9b8 0065438a 002fea48 00000000 00000000 kernel32!GetVolumeInformationW+0xbc
002fea04 00654a6f 00000000 00000000 002ff2d8 defrag!MtMgrAllUniqueIdVolumeNames::GetVolumeName+0x12f
002feab0 00658f57 002feedc 00000100 002feadc defrag!GetVolumesToDefrag+0x188
002ffad0 006595ff 00000003 00431110 00432950 defrag!wmain+0x591
002ffb14 76b14911 7ffdc000 002ffb60 7795e4b6 defrag!_initterm_e+0x163
002ffb20 7795e4b6 7ffdc000 772f5e33 00000000 kernel32!BaseThreadInitThunk+0xe
002ffb60 7795e489 00659739 7ffdc000 00000000 ntdll!__RtlUserThreadStart+0x23
002ffb78 00000000 00659739 7ffdc000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: kb

FOLLOWUP_IP:
flpydisk!FlQueueIrpToThread+f2
8945567a push esi

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: flpydisk!FlQueueIrpToThread+f2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: flpydisk

IMAGE_NAME: flpydisk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 47918f71

FAILURE_BUCKET_ID: 0xA_flpydisk!FlQueueIrpToThread+f2

BUCKET_ID: 0xA_flpydisk!FlQueueIrpToThread+f2

Followup: MachineOwner

kd> !thread
THREAD 84e7b4d8 Cid 0b6c.0cb0 Teb: 7ffdf000 Win32Thread: fe937008 RUNNING on processor 0
IRP List:
84f79698: (0006,0220) Flags: 00040070 Mdl: 00000000
84edec60: (0006,0220) Flags: 00040040 Mdl: 00000000
84f64de0: (0006,0220) Flags: 00040070 Mdl: 00000000
Not impersonating
DeviceMap 83008778
Owning Process 0 Image:
Attached Process 84e12440 Image: Defrag.exe
Wait Start TickCount 666454 Ticks: 0
Context Switch Count 32
UserTime 00:00:00.015
KernelTime 00:00:00.015
Win32 Start Address defrag!wmainCRTStartup (0x00659739)
Stack Init 9a05b000 Current 9a059610 Base 9a05b000 Limit 9a058000 Call 0
Priority 7 BasePriority 6 PriorityDecrement 0 IoPriority 1 PagePriority 3
ChildEBP RetAddr Args to Child
9a05a344 819112d7 00000003 719a7207 00000000 nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
9a05a394 81911dbd 00000003 00000016 818f7c0f nt!KiBugCheckDebugBreak+0x1c
9a05a764 8189ed84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
9a05a764 818f7c0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac (FPO: [0,0] TrapFrame @ 9a05a784)
9a05a814 81885aef 9a059810 00000000 00000000 nt!KeSetEvent+0x53
9a05a864 81886022 00000000 9a05a890 9a05a89c nt!IopCompleteRequest+0x22b
9a05a8b8 818182f7 00000000 00000000 00000000 nt!KiDeliverApc+0xce
9a05a8d8 8181850c 86871201 00000000 868710e8 hal!HalpDispatchSoftwareInterrupt+0x49 (FPO: [Non-Fpo])
9a05a8f4 818185b0 81881264 86871200 9a05a940 hal!HalpCheckForSoftwareInterrupt+0x64 (FPO: [Non-Fpo])
9a05a904 8945567a 84f64f4c 84f64de0 868710e8 hal!KfLowerIrql+0x64 (FPO: [Non-Fpo])
9a05a940 8945a06f 84f64de0 018710e8 818fffef flpydisk!FlQueueIrpToThread+0xf2 (FPO: [Non-Fpo])
9a05a964 81900053 86871030 84f64f4c 00000000 flpydisk!FloppyDeviceControl+0x125 (FPO: [Non-Fpo])
9a05a97c 894bf346 c000014f 00000000 86871030 nt!IofCallDriver+0x63
9a05a9cc 894c046e 86871030 9a05a9f4 00000000 Fs_Rec!FsRecGetDeviceSectorSize+0xfc (FPO: [Non-Fpo])
9a05a9fc 894bf0be 86bb6438 84fa33c0 86bb6438 Fs_Rec!ExFatRecFsControl+0x4c (FPO: [Non-Fpo])
9a05aa10 81900053 86bb6438 84fa33c0 81978e00 Fs_Rec!FsRecFsControl+0x60 (FPO: [Non-Fpo])
9a05aa28 819e7a62 86871030 81815030 818150c0 nt!IofCallDriver+0x63
9a05aa8c 81888a3e 86871030 868c1d00 00000000 nt!IopMountVolume+0x1ce
9a05aabc 81a64498 868c1d20 9a05abe0 9a05ab78 nt!IopCheckVpbMounted+0x60
9a05ab98 81a8a2ff 86871030 00000000 93c47008 nt!IopParseDevice+0x7fe
9a05ac28 81a61fea 00000000 9a05ac80 00000040 nt!ObpLookupObjectName+0x5a8
9a05ac88 81a63ae7 002fe984 00000000 81a61301 nt!ObOpenObjectByName+0x13c
9a05acfc 81a5453d 002fe9c0 00100000 002fe984 nt!IopCreateFile+0x63b
9a05ad44 8189ba7a 002fe9c0 00100000 002fe984 nt!NtOpenFile+0x2a
9a05ad44 77979a94 002fe9c0 00100000 002fe984 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 9a05ad64)
002fe954 779787f4 76afe503 002fe9c0 00100000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
002fe958 76afe503 002fe9c0 00100000 002fe984 ntdll!ZwOpenFile+0xc (FPO: [6,0,0])
002fe9b8 0065438a 002fea48 00000000 00000000 kernel32!GetVolumeInformationW+0xbc (FPO: [Non-Fpo])
002fea04 00654a6f 00000000 00000000 002ff2d8 defrag!MtMgrAllUniqueIdVolumeNames::GetVolumeName+0x12f (FPO: [Non-Fpo])
002feab0 00658f57 002feedc 00000100 002feadc defrag!GetVolumesToDefrag+0x188 (FPO: [Non-Fpo])
002ffad0 006595ff 00000003 00431110 00432950 defrag!wmain+0x591 (FPO: [Non-Fpo])
002ffb14 76b14911 7ffdc000 002ffb60 7795e4b6 defrag!_initterm_e+0x163 (FPO: [Non-Fpo])
002ffb20 7795e4b6 7ffdc000 772f5e33 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
002ffb60 7795e489 00659739 7ffdc000 00000000 ntdll!__RtlUserThreadStart+0x23 (FPO: [Non-Fpo])
002ffb78 00000000 00659739 7ffdc000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

What is the most probably reason caused BSOD ?

> And it will cause BSOD every several hours.

818f7c0f cmp byte ptr [eax+16h],bl
READ_ADDRESS: 00000016
eax=00000000
Guess #1: you overwrite memory that does not belong to you and holds
that event (not your event, other driver’s). eax is screwed up.

Guess #2: defrag happens rarely, noone is interested in a floppy, so your
overwrite survives for a while, but then a defrag [which by default is
scheduled to run automatically on Vista] or something else that queries
volumes comes, and - farewell, my native shore.

Not to wait for hours, try to run GetVolumeInformationW
manually, and track all your driver memory allocations/deallocations.

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Saturday, October 04, 2008 3:44 AM
Subject: [ntfsd] BSOD

> Hi, I wrote a file system filter driver . And it will cause BSOD every
> several hours.
> But from the kernel stack,it have no my driver’s finger . But indeed,it
> caused by my driver through i can’t figure it out .
> It always dead in
> nt!KeSetEvent+53
> 818f7c0f cmp byte ptr [eax+16h],bl
> At this moment eax is 0.
>
> This is one of my BSOD info .
> Through it dead in different compnent and have different context, it
> always dead in nt!KeSetEvent+53 . My system is VISTA SP1.
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>

>
> IRQL_NOT_LESS_OR_EQUAL (a)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 00000016, memory referenced
> Arg2: 0000001b, IRQL
> Arg3: 00000000, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
> chips which support this level of status)
> Arg4: 818f7c0f, address which referenced memory
>
> Debugging Details:
> ------------------
> READ_ADDRESS: 00000016
>
> CURRENT_IRQL: 1b
>
> FAULTING_IP:
> nt!KeSetEvent+53
> 818f7c0f cmp byte ptr [eax+16h],bl
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: Defrag.exe
>
> IRP_ADDRESS: ffffffc0
>
> TRAP_FRAME: 9a05a784 – (.trap 0xffffffff9a05a784)
> ErrCode = 00000000
> eax=00000000 ebx=00000001 ecx=8197c3c0 edx=00000000 esi=9a059810
> edi=9a059818
> eip=818f7c0f esp=9a05a7f8 ebp=9a05a814 iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!KeSetEvent+0x53:
> 818f7c0f cmp byte ptr [eax+16h],bl
> ds:0023:00000016=??
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 819112d7 to 818fc514
>
> STACK_TEXT:
> 9a05a344 819112d7 00000003 719a7207 00000000
> nt!RtlpBreakWithStatusInstruction
> 9a05a394 81911dbd 00000003 00000016 818f7c0f nt!KiBugCheckDebugBreak+0x1c
> 9a05a764 8189ed84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
> 9a05a764 818f7c0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac
> 9a05a814 81885aef 9a059810 00000000 00000000 nt!KeSetEvent+0x53
> 9a05a864 81886022 00000000 9a05a890 9a05a89c nt!IopCompleteRequest+0x22b
> 9a05a8b8 818182f7 00000000 00000000 00000000 nt!KiDeliverApc+0xce
> 9a05a8d8 8181850c 86871201 00000000 868710e8
> hal!HalpDispatchSoftwareInterrupt+0x49
> 9a05a8f4 818185b0 81881264 86871200 9a05a940
> hal!HalpCheckForSoftwareInterrupt+0x64
> 9a05a904 8945567a 84f64f4c 84f64de0 868710e8 hal!KfLowerIrql+0x64
> 9a05a940 8945a06f 84f64de0 018710e8 818fffef
> flpydisk!FlQueueIrpToThread+0xf2
> 9a05a964 81900053 86871030 84f64f4c 00000000
> flpydisk!FloppyDeviceControl+0x125
> 9a05a97c 894bf346 c000014f 00000000 86871030 nt!IofCallDriver+0x63
> 9a05a9cc 894c046e 86871030 9a05a9f4 00000000
> Fs_Rec!FsRecGetDeviceSectorSize+0xfc
> 9a05a9fc 894bf0be 86bb6438 84fa33c0 86bb6438 Fs_Rec!ExFatRecFsControl+0x4c
> 9a05aa10 81900053 86bb6438 84fa33c0 81978e00 Fs_Rec!FsRecFsControl+0x60
> 9a05aa28 819e7a62 86871030 81815030 818150c0 nt!IofCallDriver+0x63
> 9a05aa8c 81888a3e 86871030 868c1d00 00000000 nt!IopMountVolume+0x1ce
> 9a05aabc 81a64498 868c1d20 9a05abe0 9a05ab78 nt!IopCheckVpbMounted+0x60
> 9a05ab98 81a8a2ff 86871030 00000000 93c47008 nt!IopParseDevice+0x7fe
> 9a05ac28 81a61fea 00000000 9a05ac80 00000040 nt!ObpLookupObjectName+0x5a8
> 9a05ac88 81a63ae7 002fe984 00000000 81a61301 nt!ObOpenObjectByName+0x13c
> 9a05acfc 81a5453d 002fe9c0 00100000 002fe984 nt!IopCreateFile+0x63b
> 9a05ad44 8189ba7a 002fe9c0 00100000 002fe984 nt!NtOpenFile+0x2a
> 9a05ad44 77979a94 002fe9c0 00100000 002fe984 nt!KiFastCallEntry+0x12a
> 002fe954 779787f4 76afe503 002fe9c0 00100000 ntdll!KiFastSystemCallRet
> 002fe958 76afe503 002fe9c0 00100000 002fe984 ntdll!ZwOpenFile+0xc
> 002fe9b8 0065438a 002fea48 00000000 00000000
> kernel32!GetVolumeInformationW+0xbc
> 002fea04 00654a6f 00000000 00000000 002ff2d8
> defrag!MtMgrAllUniqueIdVolumeNames::GetVolumeName+0x12f
> 002feab0 00658f57 002feedc 00000100 002feadc
> defrag!GetVolumesToDefrag+0x188
> 002ffad0 006595ff 00000003 00431110 00432950 defrag!wmain+0x591
> 002ffb14 76b14911 7ffdc000 002ffb60 7795e4b6 defrag!_initterm_e+0x163
> 002ffb20 7795e4b6 7ffdc000 772f5e33 00000000
> kernel32!BaseThreadInitThunk+0xe
> 002ffb60 7795e489 00659739 7ffdc000 00000000
> ntdll!__RtlUserThreadStart+0x23
> 002ffb78 00000000 00659739 7ffdc000 00000000
> ntdll!_RtlUserThreadStart+0x1b
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> flpydisk!FlQueueIrpToThread+f2
> 8945567a push esi
>
> SYMBOL_STACK_INDEX: a
>
> SYMBOL_NAME: flpydisk!FlQueueIrpToThread+f2
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: flpydisk
>
> IMAGE_NAME: flpydisk.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 47918f71
>
> FAILURE_BUCKET_ID: 0xA_flpydisk!FlQueueIrpToThread+f2
>
> BUCKET_ID: 0xA_flpydisk!FlQueueIrpToThread+f2
>
> Followup: MachineOwner
> ---------
>
> kd> !thread
> THREAD 84e7b4d8 Cid 0b6c.0cb0 Teb: 7ffdf000 Win32Thread: fe937008
> RUNNING on processor 0
> IRP List:
> 84f79698: (0006,0220) Flags: 00040070 Mdl: 00000000
> 84edec60: (0006,0220) Flags: 00040040 Mdl: 00000000
> 84f64de0: (0006,0220) Flags: 00040070 Mdl: 00000000
> Not impersonating
> DeviceMap 83008778
> Owning Process 0 Image:
> Attached Process 84e12440 Image: Defrag.exe
> Wait Start TickCount 666454 Ticks: 0
> Context Switch Count 32
> UserTime 00:00:00.015
> KernelTime 00:00:00.015
> Win32 Start Address defrag!wmainCRTStartup (0x00659739)
> Stack Init 9a05b000 Current 9a059610 Base 9a05b000 Limit 9a058000 Call 0
> Priority 7 BasePriority 6 PriorityDecrement 0 IoPriority 1 PagePriority 3
> ChildEBP RetAddr Args to Child
> 9a05a344 819112d7 00000003 719a7207 00000000
> nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> 9a05a394 81911dbd 00000003 00000016 818f7c0f nt!KiBugCheckDebugBreak+0x1c
> 9a05a764 8189ed84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
> 9a05a764 818f7c0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac (FPO: [0,0]
> TrapFrame @ 9a05a784)
> 9a05a814 81885aef 9a059810 00000000 00000000 nt!KeSetEvent+0x53
> 9a05a864 81886022 00000000 9a05a890 9a05a89c nt!IopCompleteRequest+0x22b
> 9a05a8b8 818182f7 00000000 00000000 00000000 nt!KiDeliverApc+0xce
> 9a05a8d8 8181850c 86871201 00000000 868710e8
> hal!HalpDispatchSoftwareInterrupt+0x49 (FPO: [Non-Fpo])
> 9a05a8f4 818185b0 81881264 86871200 9a05a940
> hal!HalpCheckForSoftwareInterrupt+0x64 (FPO: [Non-Fpo])
> 9a05a904 8945567a 84f64f4c 84f64de0 868710e8 hal!KfLowerIrql+0x64 (FPO:
> [Non-Fpo])
> 9a05a940 8945a06f 84f64de0 018710e8 818fffef
> flpydisk!FlQueueIrpToThread+0xf2 (FPO: [Non-Fpo])
> 9a05a964 81900053 86871030 84f64f4c 00000000
> flpydisk!FloppyDeviceControl+0x125 (FPO: [Non-Fpo])
> 9a05a97c 894bf346 c000014f 00000000 86871030 nt!IofCallDriver+0x63
> 9a05a9cc 894c046e 86871030 9a05a9f4 00000000
> Fs_Rec!FsRecGetDeviceSectorSize+0xfc (FPO: [Non-Fpo])
> 9a05a9fc 894bf0be 86bb6438 84fa33c0 86bb6438 Fs_Rec!ExFatRecFsControl+0x4c
> (FPO: [Non-Fpo])
> 9a05aa10 81900053 86bb6438 84fa33c0 81978e00 Fs_Rec!FsRecFsControl+0x60
> (FPO: [Non-Fpo])
> 9a05aa28 819e7a62 86871030 81815030 818150c0 nt!IofCallDriver+0x63
> 9a05aa8c 81888a3e 86871030 868c1d00 00000000 nt!IopMountVolume+0x1ce
> 9a05aabc 81a64498 868c1d20 9a05abe0 9a05ab78 nt!IopCheckVpbMounted+0x60
> 9a05ab98 81a8a2ff 86871030 00000000 93c47008 nt!IopParseDevice+0x7fe
> 9a05ac28 81a61fea 00000000 9a05ac80 00000040 nt!ObpLookupObjectName+0x5a8
> 9a05ac88 81a63ae7 002fe984 00000000 81a61301 nt!ObOpenObjectByName+0x13c
> 9a05acfc 81a5453d 002fe9c0 00100000 002fe984 nt!IopCreateFile+0x63b
> 9a05ad44 8189ba7a 002fe9c0 00100000 002fe984 nt!NtOpenFile+0x2a
> 9a05ad44 77979a94 002fe9c0 00100000 002fe984 nt!KiFastCallEntry+0x12a
> (FPO: [0,3] TrapFrame @ 9a05ad64)
> 002fe954 779787f4 76afe503 002fe9c0 00100000 ntdll!KiFastSystemCallRet
> (FPO: [0,0,0])
> 002fe958 76afe503 002fe9c0 00100000 002fe984 ntdll!ZwOpenFile+0xc (FPO:
> [6,0,0])
> 002fe9b8 0065438a 002fea48 00000000 00000000
> kernel32!GetVolumeInformationW+0xbc (FPO: [Non-Fpo])
> 002fea04 00654a6f 00000000 00000000 002ff2d8
> defrag!MtMgrAllUniqueIdVolumeNames::GetVolumeName+0x12f (FPO: [Non-Fpo])
> 002feab0 00658f57 002feedc 00000100 002feadc
> defrag!GetVolumesToDefrag+0x188 (FPO: [Non-Fpo])
> 002ffad0 006595ff 00000003 00431110 00432950 defrag!wmain+0x591 (FPO:
> [Non-Fpo])
> 002ffb14 76b14911 7ffdc000 002ffb60 7795e4b6 defrag!_initterm_e+0x163
> (FPO: [Non-Fpo])
> 002ffb20 7795e4b6 7ffdc000 772f5e33 00000000
> kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
> 002ffb60 7795e489 00659739 7ffdc000 00000000
> ntdll!__RtlUserThreadStart+0x23 (FPO: [Non-Fpo])
> 002ffb78 00000000 00659739 7ffdc000 00000000
> ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])
>
> What is the most probably reason caused BSOD ?
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

random thoughts…

You don’t say, but if you haven’t done so now is a good time to run under
verifier (sometimes it can be handy to verify NTFS and FLTMGR as well).

The checked build won’t do you any harm either. Beyond that - try
increasing the frequency (force the defragger to work, or beat up on
GetVolumeInformation), try on a machine with no floppy - or one with lots of
floppies…

Rod

wrote in message news:xxxxx@ntfsd…
> Hi, I wrote a file system filter driver . And it will cause BSOD every
> several hours.
> But from the kernel stack,it have no my driver’s finger . But indeed,it
> caused by my driver through i can’t figure it out .
> It always dead in
> nt!KeSetEvent+53
> 818f7c0f cmp byte ptr [eax+16h],bl
> At this moment eax is 0.
>
> This is one of my BSOD info .
> Through it dead in different compnent and have different context, it
> always dead in nt!KeSetEvent+53 . My system is VISTA SP1.
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>

>
> IRQL_NOT_LESS_OR_EQUAL (a)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 00000016, memory referenced
> Arg2: 0000001b, IRQL
> Arg3: 00000000, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
> chips which support this level of status)
> Arg4: 818f7c0f, address which referenced memory
>
> Debugging Details:
> ------------------
> READ_ADDRESS: 00000016
>
> CURRENT_IRQL: 1b
>
> FAULTING_IP:
> nt!KeSetEvent+53
> 818f7c0f cmp byte ptr [eax+16h],bl
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: Defrag.exe
>
> IRP_ADDRESS: ffffffc0
>
> TRAP_FRAME: 9a05a784 – (.trap 0xffffffff9a05a784)
> ErrCode = 00000000
> eax=00000000 ebx=00000001 ecx=8197c3c0 edx=00000000 esi=9a059810
> edi=9a059818
> eip=818f7c0f esp=9a05a7f8 ebp=9a05a814 iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!KeSetEvent+0x53:
> 818f7c0f cmp byte ptr [eax+16h],bl
> ds:0023:00000016=??
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 819112d7 to 818fc514
>
> STACK_TEXT:
> 9a05a344 819112d7 00000003 719a7207 00000000
> nt!RtlpBreakWithStatusInstruction
> 9a05a394 81911dbd 00000003 00000016 818f7c0f nt!KiBugCheckDebugBreak+0x1c
> 9a05a764 8189ed84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
> 9a05a764 818f7c0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac
> 9a05a814 81885aef 9a059810 00000000 00000000 nt!KeSetEvent+0x53
> 9a05a864 81886022 00000000 9a05a890 9a05a89c nt!IopCompleteRequest+0x22b
> 9a05a8b8 818182f7 00000000 00000000 00000000 nt!KiDeliverApc+0xce
> 9a05a8d8 8181850c 86871201 00000000 868710e8
> hal!HalpDispatchSoftwareInterrupt+0x49
> 9a05a8f4 818185b0 81881264 86871200 9a05a940
> hal!HalpCheckForSoftwareInterrupt+0x64
> 9a05a904 8945567a 84f64f4c 84f64de0 868710e8 hal!KfLowerIrql+0x64
> 9a05a940 8945a06f 84f64de0 018710e8 818fffef
> flpydisk!FlQueueIrpToThread+0xf2
> 9a05a964 81900053 86871030 84f64f4c 00000000
> flpydisk!FloppyDeviceControl+0x125
> 9a05a97c 894bf346 c000014f 00000000 86871030 nt!IofCallDriver+0x63
> 9a05a9cc 894c046e 86871030 9a05a9f4 00000000
> Fs_Rec!FsRecGetDeviceSectorSize+0xfc
> 9a05a9fc 894bf0be 86bb6438 84fa33c0 86bb6438 Fs_Rec!ExFatRecFsControl+0x4c
> 9a05aa10 81900053 86bb6438 84fa33c0 81978e00 Fs_Rec!FsRecFsControl+0x60
> 9a05aa28 819e7a62 86871030 81815030 818150c0 nt!IofCallDriver+0x63
> 9a05aa8c 81888a3e 86871030 868c1d00 00000000 nt!IopMountVolume+0x1ce
> 9a05aabc 81a64498 868c1d20 9a05abe0 9a05ab78 nt!IopCheckVpbMounted+0x60
> 9a05ab98 81a8a2ff 86871030 00000000 93c47008 nt!IopParseDevice+0x7fe
> 9a05ac28 81a61fea 00000000 9a05ac80 00000040 nt!ObpLookupObjectName+0x5a8
> 9a05ac88 81a63ae7 002fe984 00000000 81a61301 nt!ObOpenObjectByName+0x13c
> 9a05acfc 81a5453d 002fe9c0 00100000 002fe984 nt!IopCreateFile+0x63b
> 9a05ad44 8189ba7a 002fe9c0 00100000 002fe984 nt!NtOpenFile+0x2a
> 9a05ad44 77979a94 002fe9c0 00100000 002fe984 nt!KiFastCallEntry+0x12a
> 002fe954 779787f4 76afe503 002fe9c0 00100000 ntdll!KiFastSystemCallRet
> 002fe958 76afe503 002fe9c0 00100000 002fe984 ntdll!ZwOpenFile+0xc
> 002fe9b8 0065438a 002fea48 00000000 00000000
> kernel32!GetVolumeInformationW+0xbc
> 002fea04 00654a6f 00000000 00000000 002ff2d8
> defrag!MtMgrAllUniqueIdVolumeNames::GetVolumeName+0x12f
> 002feab0 00658f57 002feedc 00000100 002feadc
> defrag!GetVolumesToDefrag+0x188
> 002ffad0 006595ff 00000003 00431110 00432950 defrag!wmain+0x591
> 002ffb14 76b14911 7ffdc000 002ffb60 7795e4b6 defrag!_initterm_e+0x163
> 002ffb20 7795e4b6 7ffdc000 772f5e33 00000000
> kernel32!BaseThreadInitThunk+0xe
> 002ffb60 7795e489 00659739 7ffdc000 00000000
> ntdll!__RtlUserThreadStart+0x23
> 002ffb78 00000000 00659739 7ffdc000 00000000
> ntdll!_RtlUserThreadStart+0x1b
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> flpydisk!FlQueueIrpToThread+f2
> 8945567a push esi
>
> SYMBOL_STACK_INDEX: a
>
> SYMBOL_NAME: flpydisk!FlQueueIrpToThread+f2
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: flpydisk
>
> IMAGE_NAME: flpydisk.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 47918f71
>
> FAILURE_BUCKET_ID: 0xA_flpydisk!FlQueueIrpToThread+f2
>
> BUCKET_ID: 0xA_flpydisk!FlQueueIrpToThread+f2
>
> Followup: MachineOwner
> ---------
>
> kd> !thread
> THREAD 84e7b4d8 Cid 0b6c.0cb0 Teb: 7ffdf000 Win32Thread: fe937008
> RUNNING on processor 0
> IRP List:
> 84f79698: (0006,0220) Flags: 00040070 Mdl: 00000000
> 84edec60: (0006,0220) Flags: 00040040 Mdl: 00000000
> 84f64de0: (0006,0220) Flags: 00040070 Mdl: 00000000
> Not impersonating
> DeviceMap 83008778
> Owning Process 0 Image:
> Attached Process 84e12440 Image: Defrag.exe
> Wait Start TickCount 666454 Ticks: 0
> Context Switch Count 32
> UserTime 00:00:00.015
> KernelTime 00:00:00.015
> Win32 Start Address defrag!wmainCRTStartup (0x00659739)
> Stack Init 9a05b000 Current 9a059610 Base 9a05b000 Limit 9a058000 Call 0
> Priority 7 BasePriority 6 PriorityDecrement 0 IoPriority 1 PagePriority 3
> ChildEBP RetAddr Args to Child
> 9a05a344 819112d7 00000003 719a7207 00000000
> nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> 9a05a394 81911dbd 00000003 00000016 818f7c0f nt!KiBugCheckDebugBreak+0x1c
> 9a05a764 8189ed84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
> 9a05a764 818f7c0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac (FPO: [0,0]
> TrapFrame @ 9a05a784)
> 9a05a814 81885aef 9a059810 00000000 00000000 nt!KeSetEvent+0x53
> 9a05a864 81886022 00000000 9a05a890 9a05a89c nt!IopCompleteRequest+0x22b
> 9a05a8b8 818182f7 00000000 00000000 00000000 nt!KiDeliverApc+0xce
> 9a05a8d8 8181850c 86871201 00000000 868710e8
> hal!HalpDispatchSoftwareInterrupt+0x49 (FPO: [Non-Fpo])
> 9a05a8f4 818185b0 81881264 86871200 9a05a940
> hal!HalpCheckForSoftwareInterrupt+0x64 (FPO: [Non-Fpo])
> 9a05a904 8945567a 84f64f4c 84f64de0 868710e8 hal!KfLowerIrql+0x64 (FPO:
> [Non-Fpo])
> 9a05a940 8945a06f 84f64de0 018710e8 818fffef
> flpydisk!FlQueueIrpToThread+0xf2 (FPO: [Non-Fpo])
> 9a05a964 81900053 86871030 84f64f4c 00000000
> flpydisk!FloppyDeviceControl+0x125 (FPO: [Non-Fpo])
> 9a05a97c 894bf346 c000014f 00000000 86871030 nt!IofCallDriver+0x63
> 9a05a9cc 894c046e 86871030 9a05a9f4 00000000
> Fs_Rec!FsRecGetDeviceSectorSize+0xfc (FPO: [Non-Fpo])
> 9a05a9fc 894bf0be 86bb6438 84fa33c0 86bb6438 Fs_Rec!ExFatRecFsControl+0x4c
> (FPO: [Non-Fpo])
> 9a05aa10 81900053 86bb6438 84fa33c0 81978e00 Fs_Rec!FsRecFsControl+0x60
> (FPO: [Non-Fpo])
> 9a05aa28 819e7a62 86871030 81815030 818150c0 nt!IofCallDriver+0x63
> 9a05aa8c 81888a3e 86871030 868c1d00 00000000 nt!IopMountVolume+0x1ce
> 9a05aabc 81a64498 868c1d20 9a05abe0 9a05ab78 nt!IopCheckVpbMounted+0x60
> 9a05ab98 81a8a2ff 86871030 00000000 93c47008 nt!IopParseDevice+0x7fe
> 9a05ac28 81a61fea 00000000 9a05ac80 00000040 nt!ObpLookupObjectName+0x5a8
> 9a05ac88 81a63ae7 002fe984 00000000 81a61301 nt!ObOpenObjectByName+0x13c
> 9a05acfc 81a5453d 002fe9c0 00100000 002fe984 nt!IopCreateFile+0x63b
> 9a05ad44 8189ba7a 002fe9c0 00100000 002fe984 nt!NtOpenFile+0x2a
> 9a05ad44 77979a94 002fe9c0 00100000 002fe984 nt!KiFastCallEntry+0x12a
> (FPO: [0,3] TrapFrame @ 9a05ad64)
> 002fe954 779787f4 76afe503 002fe9c0 00100000 ntdll!KiFastSystemCallRet
> (FPO: [0,0,0])
> 002fe958 76afe503 002fe9c0 00100000 002fe984 ntdll!ZwOpenFile+0xc (FPO:
> [6,0,0])
> 002fe9b8 0065438a 002fea48 00000000 00000000
> kernel32!GetVolumeInformationW+0xbc (FPO: [Non-Fpo])
> 002fea04 00654a6f 00000000 00000000 002ff2d8
> defrag!MtMgrAllUniqueIdVolumeNames::GetVolumeName+0x12f (FPO: [Non-Fpo])
> 002feab0 00658f57 002feedc 00000100 002feadc
> defrag!GetVolumesToDefrag+0x188 (FPO: [Non-Fpo])
> 002ffad0 006595ff 00000003 00431110 00432950 defrag!wmain+0x591 (FPO:
> [Non-Fpo])
> 002ffb14 76b14911 7ffdc000 002ffb60 7795e4b6 defrag!_initterm_e+0x163
> (FPO: [Non-Fpo])
> 002ffb20 7795e4b6 7ffdc000 772f5e33 00000000
> kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
> 002ffb60 7795e489 00659739 7ffdc000 00000000
> ntdll!__RtlUserThreadStart+0x23 (FPO: [Non-Fpo])
> 002ffb78 00000000 00659739 7ffdc000 00000000
> ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])
>
> What is the most probably reason caused BSOD ?
>
>

> Hi, I wrote a file system filter driver .

My compliments, this is an arduous task, many mysteries you will heva
uncovered, many difficult problems you will have solved. You have much to
contribute here, to offer to others, and I for one look forward to your
future posting.

And it will cause BSOD every several hours.
But from the kernel stack,it have no my driver’s finger . But indeed,it
caused by my driver through i can’t figure it out .

Ah, now here we are, you have found your hurdle. Yet, you write a file
system, indeed you have writen a file system. So, you have run with driver
verifier, you have run with checked build of windows? You know the ropes.
You’ve had a look at possible pool allocation around this event, and thought
about that in terms of your own pool allocations and deallocations?

Good luck; you’ve a long row to hoe yet my friend.

Thank you all.
This not not caused by defrager and GetVolumeInformationW .
Follow is another BSOD info .
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 818edc0f, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000016

CURRENT_IRQL: 1b

FAULTING_IP:
nt!KeSetEvent+53
818edc0f cmp byte ptr [eax+16h],bl

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: svchost.exe

IRP_ADDRESS: ffffffc0

TRAP_FRAME: 975466ac – (.trap 0xffffffff975466ac)
ErrCode = 00000000
eax=00000000 ebx=00000001 ecx=819723c0 edx=00000000 esi=97545700 edi=97545708
eip=818edc0f esp=97546720 ebp=9754673c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!KeSetEvent+0x53:
818edc0f cmp byte ptr [eax+16h],bl ds:0023:00000016=??
Resetting default scope

LAST_CONTROL_TRANSFER: from 819072d7 to 818f2514

STACK_TEXT:
9754626c 819072d7 00000003 f0af2700 00000000 nt!RtlpBreakWithStatusInstruction
975462bc 81907dbd 00000003 00000016 818edc0f nt!KiBugCheckDebugBreak+0x1c
9754668c 81894d84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
9754668c 818edc0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac
9754673c 8187baef 97545700 00000000 00000000 nt!KeSetEvent+0x53
9754678c 8187c022 00000000 975467b8 975467c4 nt!IopCompleteRequest+0x22b
975467e4 81863b40 00000000 00000000 00000000 nt!KiDeliverApc+0xce
975467f8 81a1b6ce 86d1a028 92653998 94283470 nt!KiCheckForKernelApcDelivery+0x24
97546814 81a7f0c6 94283470 00000000 00000000 nt!MiRelocateImageAgain+0x113
97546928 81a831d8 9754697c 0000000d 975469d0 nt!MmCreateSection+0x51d
9754699c 819d8dcc 97546a2c 0000000d 975469d0 nt!NtCreateSection+0x177
97546a18 819d8b0d 97546aec 9b9972a8 00000001 nt!PfpFileBuildReadSupport+0xe4
97546aac 819d92af 00546aec 97546be4 00000001 nt!PfpPrefetchFilesTrickle+0xdf
97546b00 819d954c 9b997000 f0af2ee8 97546bf8 nt!PfpPrefetchRequestPerform+0x295
97546b54 81a183b6 97546be4 81932801 f0af29a4 nt!PfpPrefetchRequest+0x16e
97546c18 81a31bf7 01e3fca8 00000014 81932801 nt!PfSetSuperfetchInformation+0x182
97546d50 81891a7a 0000004f 00000000 00000014 nt!NtSetSystemInformation+0x908
97546d50 770e9a94 0000004f 00000000 00000014 nt!KiFastCallEntry+0x12a
01e3fc84 770e9024 6fa61279 0000004f 01e3fca8 ntdll!KiFastSystemCallRet
01e3fc88 6fa61279 0000004f 01e3fca8 00000014 ntdll!ZwSetSystemInformation+0xc
01e3fcc0 6fa61162 01e3fcdc 024b9110 024b9110 sysmain!PfListPrefetch+0xb5
01e3fd90 6fa61398 01e3fde8 024b9110 03eaa6e8 sysmain!PfDbDatabasePrefetchPerform+0x847
01e3fdcc 6fa7070f 01e3fde8 00002332 00000000 sysmain!PfDbDatabasePrefetchEx+0xc6
01e3fe04 76e64911 024b8fd4 01e3fe50 770ce4b6 sysmain!PfSvPrefetchContextPrefetchThread+0x5b
01e3fe10 770ce4b6 024b8fd4 76f6e782 00000000 kernel32!BaseThreadInitThunk+0xe
01e3fe50 770ce489 6fa706b4 024b8fd4 00000000 ntdll!__RtlUserThreadStart+0x23
01e3fe68 00000000 6fa706b4 024b8fd4 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KeSetEvent+53
818edc0f cmp byte ptr [eax+16h],bl

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!KeSetEvent+53

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12

FAILURE_BUCKET_ID: 0xA_nt!KeSetEvent+53

BUCKET_ID: 0xA_nt!KeSetEvent+53

Followup: MachineOwner

Have you tried looking at the IRP that is being completed? It seems it
isn’t properly constructed - so there’s no event object to signal (this
is a null pointer dereference.)

Tony
OSR

> This not not caused by defrager and GetVolumeInformationW .
There was no doubt about that.
BSOD was caused by your driver.

We suggested that you call GetVolumeInformationW b/c it
provokes BSOD and makes it easier to catch without
waiting for hours.

Again: check all your memory writes.

When you put 81 byte into an 80-byte buffer, results are, well,
interesting. They look “unexplainable” (division by zero with no divisions
around etc., you name it) and BSOD is certainly one of them.

9754673c 8187baef 97545700 00000000 00000000 nt!KeSetEvent+0x53
So your 81st byte is somewhere around 97545700, I guess.

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Sunday, October 05, 2008 4:09 AM
Subject: RE:[ntfsd] BSOD

> Thank you all.
> This not not caused by defrager and GetVolumeInformationW .
> Follow is another BSOD info .
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>

>
> IRQL_NOT_LESS_OR_EQUAL (a)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 00000016, memory referenced
> Arg2: 0000001b, IRQL
> Arg3: 00000000, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
> chips which support this level of status)
> Arg4: 818edc0f, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000016
>
> CURRENT_IRQL: 1b
>
> FAULTING_IP:
> nt!KeSetEvent+53
> 818edc0f cmp byte ptr [eax+16h],bl
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: svchost.exe
>
> IRP_ADDRESS: ffffffc0
>
> TRAP_FRAME: 975466ac – (.trap 0xffffffff975466ac)
> ErrCode = 00000000
> eax=00000000 ebx=00000001 ecx=819723c0 edx=00000000 esi=97545700
> edi=97545708
> eip=818edc0f esp=97546720 ebp=9754673c iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!KeSetEvent+0x53:
> 818edc0f cmp byte ptr [eax+16h],bl
> ds:0023:00000016=??
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 819072d7 to 818f2514
>
> STACK_TEXT:
> 9754626c 819072d7 00000003 f0af2700 00000000
> nt!RtlpBreakWithStatusInstruction
> 975462bc 81907dbd 00000003 00000016 818edc0f nt!KiBugCheckDebugBreak+0x1c
> 9754668c 81894d84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
> 9754668c 818edc0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac
> 9754673c 8187baef 97545700 00000000 00000000 nt!KeSetEvent+0x53
> 9754678c 8187c022 00000000 975467b8 975467c4 nt!IopCompleteRequest+0x22b
> 975467e4 81863b40 00000000 00000000 00000000 nt!KiDeliverApc+0xce
> 975467f8 81a1b6ce 86d1a028 92653998 94283470
> nt!KiCheckForKernelApcDelivery+0x24
> 97546814 81a7f0c6 94283470 00000000 00000000 nt!MiRelocateImageAgain+0x113
> 97546928 81a831d8 9754697c 0000000d 975469d0 nt!MmCreateSection+0x51d
> 9754699c 819d8dcc 97546a2c 0000000d 975469d0 nt!NtCreateSection+0x177
> 97546a18 819d8b0d 97546aec 9b9972a8 00000001
> nt!PfpFileBuildReadSupport+0xe4
> 97546aac 819d92af 00546aec 97546be4 00000001
> nt!PfpPrefetchFilesTrickle+0xdf
> 97546b00 819d954c 9b997000 f0af2ee8 97546bf8
> nt!PfpPrefetchRequestPerform+0x295
> 97546b54 81a183b6 97546be4 81932801 f0af29a4 nt!PfpPrefetchRequest+0x16e
> 97546c18 81a31bf7 01e3fca8 00000014 81932801
> nt!PfSetSuperfetchInformation+0x182
> 97546d50 81891a7a 0000004f 00000000 00000014
> nt!NtSetSystemInformation+0x908
> 97546d50 770e9a94 0000004f 00000000 00000014 nt!KiFastCallEntry+0x12a
> 01e3fc84 770e9024 6fa61279 0000004f 01e3fca8 ntdll!KiFastSystemCallRet
> 01e3fc88 6fa61279 0000004f 01e3fca8 00000014
> ntdll!ZwSetSystemInformation+0xc
> 01e3fcc0 6fa61162 01e3fcdc 024b9110 024b9110 sysmain!PfListPrefetch+0xb5
> 01e3fd90 6fa61398 01e3fde8 024b9110 03eaa6e8
> sysmain!PfDbDatabasePrefetchPerform+0x847
> 01e3fdcc 6fa7070f 01e3fde8 00002332 00000000
> sysmain!PfDbDatabasePrefetchEx+0xc6
> 01e3fe04 76e64911 024b8fd4 01e3fe50 770ce4b6
> sysmain!PfSvPrefetchContextPrefetchThread+0x5b
> 01e3fe10 770ce4b6 024b8fd4 76f6e782 00000000
> kernel32!BaseThreadInitThunk+0xe
> 01e3fe50 770ce489 6fa706b4 024b8fd4 00000000
> ntdll!__RtlUserThreadStart+0x23
> 01e3fe68 00000000 6fa706b4 024b8fd4 00000000
> ntdll!_RtlUserThreadStart+0x1b
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!KeSetEvent+53
> 818edc0f cmp byte ptr [eax+16h],bl
>
> SYMBOL_STACK_INDEX: 4
>
> SYMBOL_NAME: nt!KeSetEvent+53
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrpamp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12
>
> FAILURE_BUCKET_ID: 0xA_nt!KeSetEvent+53
>
> BUCKET_ID: 0xA_nt!KeSetEvent+53
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

We know it’s not caused by defrag, probably it’s caused by something your
running - you have written a file system.

You’ve now posted two !analyze-c here. I wonder if you’ve noticed what they
have in common, and whether or not that is a coincidence. Both stacks fault
in KeSetEvent from IoCompleteRequest. The bugcheck args Arg1,2,3 are
identical in both cases. The values in eax and ebx are identical in both
cases. I’m sure some ideas are leaping out of the page at you already - you
have written a file system.

wrote in message news:xxxxx@ntfsd…
> Thank you all.
> This not not caused by defrager and GetVolumeInformationW .
> Follow is another BSOD info .
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>

>
> IRQL_NOT_LESS_OR_EQUAL (a)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 00000016, memory referenced
> Arg2: 0000001b, IRQL
> Arg3: 00000000, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
> chips which support this level of status)
> Arg4: 818edc0f, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000016
>
> CURRENT_IRQL: 1b
>
> FAULTING_IP:
> nt!KeSetEvent+53
> 818edc0f cmp byte ptr [eax+16h],bl
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: svchost.exe
>
> IRP_ADDRESS: ffffffc0
>
> TRAP_FRAME: 975466ac – (.trap 0xffffffff975466ac)
> ErrCode = 00000000
> eax=00000000 ebx=00000001 ecx=819723c0 edx=00000000 esi=97545700
> edi=97545708
> eip=818edc0f esp=97546720 ebp=9754673c iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!KeSetEvent+0x53:
> 818edc0f cmp byte ptr [eax+16h],bl
> ds:0023:00000016=??
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 819072d7 to 818f2514
>
> STACK_TEXT:
> 9754626c 819072d7 00000003 f0af2700 00000000
> nt!RtlpBreakWithStatusInstruction
> 975462bc 81907dbd 00000003 00000016 818edc0f nt!KiBugCheckDebugBreak+0x1c
> 9754668c 81894d84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
> 9754668c 818edc0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac
> 9754673c 8187baef 97545700 00000000 00000000 nt!KeSetEvent+0x53
> 9754678c 8187c022 00000000 975467b8 975467c4 nt!IopCompleteRequest+0x22b
> 975467e4 81863b40 00000000 00000000 00000000 nt!KiDeliverApc+0xce
> 975467f8 81a1b6ce 86d1a028 92653998 94283470
> nt!KiCheckForKernelApcDelivery+0x24
> 97546814 81a7f0c6 94283470 00000000 00000000 nt!MiRelocateImageAgain+0x113
> 97546928 81a831d8 9754697c 0000000d 975469d0 nt!MmCreateSection+0x51d
> 9754699c 819d8dcc 97546a2c 0000000d 975469d0 nt!NtCreateSection+0x177
> 97546a18 819d8b0d 97546aec 9b9972a8 00000001
> nt!PfpFileBuildReadSupport+0xe4
> 97546aac 819d92af 00546aec 97546be4 00000001
> nt!PfpPrefetchFilesTrickle+0xdf
> 97546b00 819d954c 9b997000 f0af2ee8 97546bf8
> nt!PfpPrefetchRequestPerform+0x295
> 97546b54 81a183b6 97546be4 81932801 f0af29a4 nt!PfpPrefetchRequest+0x16e
> 97546c18 81a31bf7 01e3fca8 00000014 81932801
> nt!PfSetSuperfetchInformation+0x182
> 97546d50 81891a7a 0000004f 00000000 00000014
> nt!NtSetSystemInformation+0x908
> 97546d50 770e9a94 0000004f 00000000 00000014 nt!KiFastCallEntry+0x12a
> 01e3fc84 770e9024 6fa61279 0000004f 01e3fca8 ntdll!KiFastSystemCallRet
> 01e3fc88 6fa61279 0000004f 01e3fca8 00000014
> ntdll!ZwSetSystemInformation+0xc
> 01e3fcc0 6fa61162 01e3fcdc 024b9110 024b9110 sysmain!PfListPrefetch+0xb5
> 01e3fd90 6fa61398 01e3fde8 024b9110 03eaa6e8
> sysmain!PfDbDatabasePrefetchPerform+0x847
> 01e3fdcc 6fa7070f 01e3fde8 00002332 00000000
> sysmain!PfDbDatabasePrefetchEx+0xc6
> 01e3fe04 76e64911 024b8fd4 01e3fe50 770ce4b6
> sysmain!PfSvPrefetchContextPrefetchThread+0x5b
> 01e3fe10 770ce4b6 024b8fd4 76f6e782 00000000
> kernel32!BaseThreadInitThunk+0xe
> 01e3fe50 770ce489 6fa706b4 024b8fd4 00000000
> ntdll!__RtlUserThreadStart+0x23
> 01e3fe68 00000000 6fa706b4 024b8fd4 00000000
> ntdll!_RtlUserThreadStart+0x1b
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!KeSetEvent+53
> 818edc0f cmp byte ptr [eax+16h],bl
>
> SYMBOL_STACK_INDEX: 4
>
> SYMBOL_NAME: nt!KeSetEvent+53
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrpamp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12
>
> FAILURE_BUCKET_ID: 0xA_nt!KeSetEvent+53
>
> BUCKET_ID: 0xA_nt!KeSetEvent+53
>
> Followup: MachineOwner
> ---------
>
>
>

> I’m sure some ideas are leaping out of the page at you already - you have

written a file system.
Gosh, let him live, for God’s sake.

You are not obligated to use the file system that he - allegedly -
wrote.

To OP:

It’s not that Lyndon (or me, for that matter) want[s] you dead.

What he sees is an elemetary, basic error/bug that
normally is treated in 30 minutes, including 2 cigarette breaks 7 minutes
each, plus one break 16 minutes long, and I will not tell you what for,
and - drum roll, please - you state that you have completed
the most complex task in windows kernel, FS driver.

Not an FS filter, a FS driver.

Here’s his way of thinking (my guess anyway):
“People who really can do that - in about 6-12 man/months, if
you are smart, 40 years if you are not - do not ask why eax is bad.
He/she does ask, so it probably his driver is not the best driver
I ever thought of.”

Guess what? No matter how I disapprove his tone (and I do
disapprove his tone), I have zero arguments to beat (my
guess of) his logic.

I wish you luck.
You already have my guesses #1 and #2, and my guess #3
is that you will need quite a lot of it.

----- Original Message -----
From: “Lyndon J Clarke”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Sunday, October 05, 2008 12:03 PM
Subject: Re:[ntfsd] BSOD

> We know it’s not caused by defrag, probably it’s caused by something your
> running - you have written a file system.
>
> You’ve now posted two !analyze-c here. I wonder if you’ve noticed what
> they have in common, and whether or not that is a coincidence. Both stacks
> fault in KeSetEvent from IoCompleteRequest. The bugcheck args Arg1,2,3 are
> identical in both cases. The values in eax and ebx are identical in both
> cases. I’m sure some ideas are leaping out of the page at you already -
> you have written a file system.
>
> wrote in message news:xxxxx@ntfsd…
>> Thank you all.
>> This not not caused by defrager and GetVolumeInformationW .
>> Follow is another BSOD info .
>> kd> !analyze -v
>> ***
>> *
>> * Bugcheck Analysis
>> *
>>

>>
>> IRQL_NOT_LESS_OR_EQUAL (a)
>> An attempt was made to access a pageable (or completely invalid) address
>> at an
>> interrupt request level (IRQL) that is too high. This is usually
>> caused by drivers using improper addresses.
>> If a kernel debugger is available get the stack backtrace.
>> Arguments:
>> Arg1: 00000016, memory referenced
>> Arg2: 0000001b, IRQL
>> Arg3: 00000000, bitfield :
>> bit 0 : value 0 = read operation, 1 = write operation
>> bit 3 : value 0 = not an execute operation, 1 = execute operation (only
>> on chips which support this level of status)
>> Arg4: 818edc0f, address which referenced memory
>>
>> Debugging Details:
>> ------------------
>>
>>
>> READ_ADDRESS: 00000016
>>
>> CURRENT_IRQL: 1b
>>
>> FAULTING_IP:
>> nt!KeSetEvent+53
>> 818edc0f cmp byte ptr [eax+16h],bl
>>
>> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>>
>> BUGCHECK_STR: 0xA
>>
>> PROCESS_NAME: svchost.exe
>>
>> IRP_ADDRESS: ffffffc0
>>
>> TRAP_FRAME: 975466ac – (.trap 0xffffffff975466ac)
>> ErrCode = 00000000
>> eax=00000000 ebx=00000001 ecx=819723c0 edx=00000000 esi=97545700
>> edi=97545708
>> eip=818edc0f esp=97546720 ebp=9754673c iopl=0 nv up ei pl zr na
>> pe nc
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
>> nt!KeSetEvent+0x53:
>> 818edc0f cmp byte ptr [eax+16h],bl ds:0023:00000016=??
>> Resetting default scope
>>
>> LAST_CONTROL_TRANSFER: from 819072d7 to 818f2514
>>
>> STACK_TEXT:
>> 9754626c 819072d7 00000003 f0af2700 00000000
>> nt!RtlpBreakWithStatusInstruction
>> 975462bc 81907dbd 00000003 00000016 818edc0f nt!KiBugCheckDebugBreak+0x1c
>> 9754668c 81894d84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
>> 9754668c 818edc0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac
>> 9754673c 8187baef 97545700 00000000 00000000 nt!KeSetEvent+0x53
>> 9754678c 8187c022 00000000 975467b8 975467c4 nt!IopCompleteRequest+0x22b
>> 975467e4 81863b40 00000000 00000000 00000000 nt!KiDeliverApc+0xce
>> 975467f8 81a1b6ce 86d1a028 92653998 94283470
>> nt!KiCheckForKernelApcDelivery+0x24
>> 97546814 81a7f0c6 94283470 00000000 00000000
>> nt!MiRelocateImageAgain+0x113
>> 97546928 81a831d8 9754697c 0000000d 975469d0 nt!MmCreateSection+0x51d
>> 9754699c 819d8dcc 97546a2c 0000000d 975469d0 nt!NtCreateSection+0x177
>> 97546a18 819d8b0d 97546aec 9b9972a8 00000001
>> nt!PfpFileBuildReadSupport+0xe4
>> 97546aac 819d92af 00546aec 97546be4 00000001
>> nt!PfpPrefetchFilesTrickle+0xdf
>> 97546b00 819d954c 9b997000 f0af2ee8 97546bf8
>> nt!PfpPrefetchRequestPerform+0x295
>> 97546b54 81a183b6 97546be4 81932801 f0af29a4 nt!PfpPrefetchRequest+0x16e
>> 97546c18 81a31bf7 01e3fca8 00000014 81932801
>> nt!PfSetSuperfetchInformation+0x182
>> 97546d50 81891a7a 0000004f 00000000 00000014
>> nt!NtSetSystemInformation+0x908
>> 97546d50 770e9a94 0000004f 00000000 00000014 nt!KiFastCallEntry+0x12a
>> 01e3fc84 770e9024 6fa61279 0000004f 01e3fca8 ntdll!KiFastSystemCallRet
>> 01e3fc88 6fa61279 0000004f 01e3fca8 00000014
>> ntdll!ZwSetSystemInformation+0xc
>> 01e3fcc0 6fa61162 01e3fcdc 024b9110 024b9110 sysmain!PfListPrefetch+0xb5
>> 01e3fd90 6fa61398 01e3fde8 024b9110 03eaa6e8
>> sysmain!PfDbDatabasePrefetchPerform+0x847
>> 01e3fdcc 6fa7070f 01e3fde8 00002332 00000000
>> sysmain!PfDbDatabasePrefetchEx+0xc6
>> 01e3fe04 76e64911 024b8fd4 01e3fe50 770ce4b6
>> sysmain!PfSvPrefetchContextPrefetchThread+0x5b
>> 01e3fe10 770ce4b6 024b8fd4 76f6e782 00000000
>> kernel32!BaseThreadInitThunk+0xe
>> 01e3fe50 770ce489 6fa706b4 024b8fd4 00000000
>> ntdll!__RtlUserThreadStart+0x23
>> 01e3fe68 00000000 6fa706b4 024b8fd4 00000000
>> ntdll!_RtlUserThreadStart+0x1b
>>
>>
>> STACK_COMMAND: kb
>>
>> FOLLOWUP_IP:
>> nt!KeSetEvent+53
>> 818edc0f cmp byte ptr [eax+16h],bl
>>
>> SYMBOL_STACK_INDEX: 4
>>
>> SYMBOL_NAME: nt!KeSetEvent+53
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> MODULE_NAME: nt
>>
>> IMAGE_NAME: ntkrpamp.exe
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12
>>
>> FAILURE_BUCKET_ID: 0xA_nt!KeSetEvent+53
>>
>> BUCKET_ID: 0xA_nt!KeSetEvent+53
>>
>> Followup: MachineOwner
>> ---------
>>
>>
>>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Hey Alex

Well, you’re right, perhaps I could write with a better tone.

I dont know anything about how long the OP has taken writing his/her file
system driver. I’ve no reason to disbelieve that the OP is developing a file
system driver, and mistakenly thought the driver had been written. I do know
that if I were doing that, which I’m not, I haven’t yet, just a few filters,
then these seem to be the sorts of problems that I’d have to have resolved
before I could reach the state where I’d have thought that maybe, just
maybe, I’d written a file system.

So I could be way off here, but on the evdience so far this case looks to me
a bit like a pool scribbling case. I guess the first thing I’d be thinking
about is whether the code writes to free-d pool. I dont think I’ve ever
solved one of these in half an hour. I had one in an ndis driver not so long
ago, with one crash dump to work from and no reproducer, and it took me an
awful lot longer than half an hour.

Cheers, Lyndon

“Alex Shvedov” wrote in message news:xxxxx@ntfsd…
>> I’m sure some ideas are leaping out of the page at you already - you have
>> written a file system.
> Gosh, let him live, for God’s sake.
>
> You are not obligated to use the file system that he - allegedly -
> wrote.
>
> To OP:
>
> It’s not that Lyndon (or me, for that matter) want[s] you dead.
>
> What he sees is an elemetary, basic error/bug that
> normally is treated in 30 minutes, including 2 cigarette breaks 7 minutes
> each, plus one break 16 minutes long, and I will not tell you what for,
> and - drum roll, please - you state that you have completed
> the most complex task in windows kernel, FS driver.
>
> Not an FS filter, a FS driver.
>
> Here’s his way of thinking (my guess anyway):
> “People who really can do that - in about 6-12 man/months, if
> you are smart, 40 years if you are not - do not ask why eax is bad.
> He/she does ask, so it probably his driver is not the best driver
> I ever thought of.”
>
> Guess what? No matter how I disapprove his tone (and I do
> disapprove his tone), I have zero arguments to beat (my
> guess of) his logic.
>
> I wish you luck.
> You already have my guesses #1 and #2, and my guess #3
> is that you will need quite a lot of it.
>
>
>
>
>
> ----- Original Message -----
> From: “Lyndon J Clarke”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Sunday, October 05, 2008 12:03 PM
> Subject: Re:[ntfsd] BSOD
>
>
>> We know it’s not caused by defrag, probably it’s caused by something your
>> running - you have written a file system.
>>
>> You’ve now posted two !analyze-c here. I wonder if you’ve noticed what
>> they have in common, and whether or not that is a coincidence. Both
>> stacks fault in KeSetEvent from IoCompleteRequest. The bugcheck args
>> Arg1,2,3 are identical in both cases. The values in eax and ebx are
>> identical in both cases. I’m sure some ideas are leaping out of the page
>> at you already - you have written a file system.
>>
>> wrote in message news:xxxxx@ntfsd…
>>> Thank you all.
>>> This not not caused by defrager and GetVolumeInformationW .
>>> Follow is another BSOD info .
>>> kd> !analyze -v
>>> ***
>>> *
>>> * Bugcheck Analysis
>>> *
>>>

>>>
>>> IRQL_NOT_LESS_OR_EQUAL (a)
>>> An attempt was made to access a pageable (or completely invalid) address
>>> at an
>>> interrupt request level (IRQL) that is too high. This is usually
>>> caused by drivers using improper addresses.
>>> If a kernel debugger is available get the stack backtrace.
>>> Arguments:
>>> Arg1: 00000016, memory referenced
>>> Arg2: 0000001b, IRQL
>>> Arg3: 00000000, bitfield :
>>> bit 0 : value 0 = read operation, 1 = write operation
>>> bit 3 : value 0 = not an execute operation, 1 = execute operation (only
>>> on chips which support this level of status)
>>> Arg4: 818edc0f, address which referenced memory
>>>
>>> Debugging Details:
>>> ------------------
>>>
>>>
>>> READ_ADDRESS: 00000016
>>>
>>> CURRENT_IRQL: 1b
>>>
>>> FAULTING_IP:
>>> nt!KeSetEvent+53
>>> 818edc0f cmp byte ptr [eax+16h],bl
>>>
>>> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>>>
>>> BUGCHECK_STR: 0xA
>>>
>>> PROCESS_NAME: svchost.exe
>>>
>>> IRP_ADDRESS: ffffffc0
>>>
>>> TRAP_FRAME: 975466ac – (.trap 0xffffffff975466ac)
>>> ErrCode = 00000000
>>> eax=00000000 ebx=00000001 ecx=819723c0 edx=00000000 esi=97545700
>>> edi=97545708
>>> eip=818edc0f esp=97546720 ebp=9754673c iopl=0 nv up ei pl zr na
>>> pe nc
>>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
>>> nt!KeSetEvent+0x53:
>>> 818edc0f cmp byte ptr [eax+16h],bl ds:0023:00000016=??
>>> Resetting default scope
>>>
>>> LAST_CONTROL_TRANSFER: from 819072d7 to 818f2514
>>>
>>> STACK_TEXT:
>>> 9754626c 819072d7 00000003 f0af2700 00000000
>>> nt!RtlpBreakWithStatusInstruction
>>> 975462bc 81907dbd 00000003 00000016 818edc0f
>>> nt!KiBugCheckDebugBreak+0x1c
>>> 9754668c 81894d84 0000000a 00000016 0000001b nt!KeBugCheck2+0x66d
>>> 9754668c 818edc0f 0000000a 00000016 0000001b nt!KiTrap0E+0x2ac
>>> 9754673c 8187baef 97545700 00000000 00000000 nt!KeSetEvent+0x53
>>> 9754678c 8187c022 00000000 975467b8 975467c4 nt!IopCompleteRequest+0x22b
>>> 975467e4 81863b40 00000000 00000000 00000000 nt!KiDeliverApc+0xce
>>> 975467f8 81a1b6ce 86d1a028 92653998 94283470
>>> nt!KiCheckForKernelApcDelivery+0x24
>>> 97546814 81a7f0c6 94283470 00000000 00000000
>>> nt!MiRelocateImageAgain+0x113
>>> 97546928 81a831d8 9754697c 0000000d 975469d0 nt!MmCreateSection+0x51d
>>> 9754699c 819d8dcc 97546a2c 0000000d 975469d0 nt!NtCreateSection+0x177
>>> 97546a18 819d8b0d 97546aec 9b9972a8 00000001
>>> nt!PfpFileBuildReadSupport+0xe4
>>> 97546aac 819d92af 00546aec 97546be4 00000001
>>> nt!PfpPrefetchFilesTrickle+0xdf
>>> 97546b00 819d954c 9b997000 f0af2ee8 97546bf8
>>> nt!PfpPrefetchRequestPerform+0x295
>>> 97546b54 81a183b6 97546be4 81932801 f0af29a4 nt!PfpPrefetchRequest+0x16e
>>> 97546c18 81a31bf7 01e3fca8 00000014 81932801
>>> nt!PfSetSuperfetchInformation+0x182
>>> 97546d50 81891a7a 0000004f 00000000 00000014
>>> nt!NtSetSystemInformation+0x908
>>> 97546d50 770e9a94 0000004f 00000000 00000014 nt!KiFastCallEntry+0x12a
>>> 01e3fc84 770e9024 6fa61279 0000004f 01e3fca8 ntdll!KiFastSystemCallRet
>>> 01e3fc88 6fa61279 0000004f 01e3fca8 00000014
>>> ntdll!ZwSetSystemInformation+0xc
>>> 01e3fcc0 6fa61162 01e3fcdc 024b9110 024b9110 sysmain!PfListPrefetch+0xb5
>>> 01e3fd90 6fa61398 01e3fde8 024b9110 03eaa6e8
>>> sysmain!PfDbDatabasePrefetchPerform+0x847
>>> 01e3fdcc 6fa7070f 01e3fde8 00002332 00000000
>>> sysmain!PfDbDatabasePrefetchEx+0xc6
>>> 01e3fe04 76e64911 024b8fd4 01e3fe50 770ce4b6
>>> sysmain!PfSvPrefetchContextPrefetchThread+0x5b
>>> 01e3fe10 770ce4b6 024b8fd4 76f6e782 00000000
>>> kernel32!BaseThreadInitThunk+0xe
>>> 01e3fe50 770ce489 6fa706b4 024b8fd4 00000000
>>> ntdll!__RtlUserThreadStart+0x23
>>> 01e3fe68 00000000 6fa706b4 024b8fd4 00000000
>>> ntdll!_RtlUserThreadStart+0x1b
>>>
>>>
>>> STACK_COMMAND: kb
>>>
>>> FOLLOWUP_IP:
>>> nt!KeSetEvent+53
>>> 818edc0f cmp byte ptr [eax+16h],bl
>>>
>>> SYMBOL_STACK_INDEX: 4
>>>
>>> SYMBOL_NAME: nt!KeSetEvent+53
>>>
>>> FOLLOWUP_NAME: MachineOwner
>>>
>>> MODULE_NAME: nt
>>>
>>> IMAGE_NAME: ntkrpamp.exe
>>>
>>> DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12
>>>
>>> FAILURE_BUCKET_ID: 0xA_nt!KeSetEvent+53
>>>
>>> BUCKET_ID: 0xA_nt!KeSetEvent+53
>>>
>>> Followup: MachineOwner
>>> ---------
>>>
>>>
>>>
>>
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

Hi all, Thanks for your useful reply !
In my first thread I had stated that I wrote a file system filter driver ,not a file system.

I admitted that I’m a newbie in this filed ,just several month , and have little experience in debugging .
And maybe I need more time to resolve it .
Thanks again !!!

Hiya

You’re right, and I’m wrong; me bad!

If you have a pool over-run, or other pool problems, verifiier might be your
very good friend.

Here are some msft articles about verifier in case you’re not familar

http://www.microsoft.com/whdc/DevTools/tools/DrvVerifier.mspx
http://support.microsoft.com/kb/244617

The checked build can also be a good friend and should be used often. It’s
more convenient perhaps to use a partial checked build. This reference might
be useful if you’re not familiar.

http://msdn.microsoft.com/en-us/library/ms791523.aspx

If you’re writing a mini-filter as opposed to a legacy filter then using
these techniques for a checked build of fltmgr.sys as well can also be very
helpful.

For me though the strange thing is that twice you are in KeSetEvent from
IopCompleteRequest with a null pointer dereference. I wonder if there is
something systematic in what you’re doing which creates this situation.
Tony’s suggestion to look at the IRP, well, seems like a good suggestion to
me.

Good luck,
Lyndon

wrote in message news:xxxxx@ntfsd…
> Hi all, Thanks for your useful reply !
> In my first thread I had stated that I wrote a file system filter driver
> ,not a file system.
>
> I admitted that I’m a newbie in this filed ,just several month , and have
> little experience in debugging .
> And maybe I need more time to resolve it .
> Thanks again !!!
>