Analyzing a Minidump

NTFSD
1

Hi,

I do have a (legacy) filter-driver, that pends some IRPs to work items. A
crash occurs when I plug in a USB device (external harddrive). Unfortunately
I only have a MiniDump to solve this problem. I can see the correct stack
trace in WinDbg, but all I can see is that my filter-device is passing the
IRP down to the next device…which can’t be generally wrong I think. Can
anybody help me to examine this mini-dump in further steps?

Thanks
Frank

kd> !analyze -v

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

* *

* Bugcheck Analysis *

* *

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

NTFS_FILE_SYSTEM (24)

If you see NtfsExceptionFilter on the stack then the 2nd and 3rd

parameters are the exception record and context record. Do a .cxr

on the 3rd parameter and then kb to obtain a more informative stack

trace.

Arguments:

Arg1: 001902fe

Arg2: f9e8a60c

Arg3: f9e8a308

Arg4: f98aeab3

Debugging Details:

EXCEPTION_RECORD: f9e8a60c – (.exr fffffffff9e8a60c)

ExceptionAddress: f98aeab3 (Ntfs!NtfsDecodeFileObject+0x00000045)

ExceptionCode: c0000005 (Access violation)

ExceptionFlags: 00000000

NumberParameters: 2

Parameter[0]: 00000000

Parameter[1]: 0000002e

Attempt to read from address 0000002e

CONTEXT: f9e8a308 – (.cxr fffffffff9e8a308)

eax=00000002 ebx=f9e8a7c4 ecx=815608e0 edx=f9e8a710 esi=f9e8a720
edi=f9e8aaae

eip=f98aeab3 esp=f9e8a6d4 ebp=f9e8a6d8 iopl=0 nv up ei pl nz na pe nc

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

Ntfs!NtfsDecodeFileObject+0x45:

f98aeab3 80782c04 cmp byte ptr [eax+0x2c],0x4 ds:0023:0000002e=??

Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in “0x%08lx” verweist auf
Speicher in “0x%08lx”. Der Vorgang “%s” konnte nicht auf dem Speicher
durchgef hrt werden.

READ_ADDRESS: 0000002e

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f98c7d60 to f98aeab3

STACK_TEXT:

f9e8a6d8 f98c7d60 f9e8a7c4 815c88d8 f9e8a714 Ntfs!NtfsDecodeFileObject+0x45

f9e8a74c f98c64b4 f9e8a7c4 81600678 817db020
Ntfs!NtfsCommonQueryInformation+0x56

f9e8a7b0 f98c64ed f9e8a7c4 81600678 00000001
Ntfs!NtfsFsdDispatchSwitch+0x12a

f9e8a8d4 804e3d77 817db020 81600678 81600678 Ntfs!NtfsFsdDispatchWait+0x1c

f9e8a8e4 f995352d 8178d918 f9e8aaae f9e8aa9c nt!IopfCallDriver+0x31

f9e8a910 f994d82c 817db020 815c88d8 f9e8aaae sr!SrQueryInformationFile+0x99

f9e8a93c f994e19a 0000002e 815c88d8 f9e8aa9c sr!SrpGetFileName+0x32

f9e8abb0 f99513b5 8178d918 00000200 00000016 sr!SrpExpandDestPath+0xcc

f9e8acc4 f9951f0e 8178d918 8140c008 8145d964 sr!SrpSetRenameInfo+0x135

f9e8ace0 804e3d77 8178d918 8140c008 80561b7c sr!SrSetInformation+0x142

f9e8acf0 f7818f20 815dcd6c f9e8ad0c f7818ec2 nt!IopfCallDriver+0x31

f9e8acfc f7818ec2 8140c008 815dcd88 f9e8ad54
interceptor!KLowerDevice::Call+0x40
[C:\Programme\Compuware\DriverStudio\DriverWorks\include\klower.h @ 236]

f9e8ad0c f780c4b2 8140c008 00000001 8140c460
interceptor!CFilterDevice::PassThrough+0x62 [F:\Projekte\Monitor\Kernel
Driver\Interceptor\MyFilterDevice.cpp @ 748]

f9e8ad54 f780da4f 8145d964 f9e8ad74 f780ccaf
interceptor!CFileFilterDevice::OnWorkItem+0x1b2 [F:\Projekte\Monitor\Kernel
Driver\Interceptor\FileFilterDevice.cpp @ 1334]

f9e8ad60 f780ccaf 8145d964 815dcd88 8145d964
interceptor!CFileFilterDevice::OnWorkItemLINK+0xf
[F:\Projekte\Monitor\Kernel Driver\Interceptor\FileFilterDevice.h @ 107]

f9e8ad74 804e47fe 8145d964 00000000 817cb3c8
interceptor!KWorkItem::Dispatch+0x4f
[C:\Programme\Compuware\DriverStudio\DriverWorks\include\kworkitm.h @ 125]

f9e8adac 8057dfed 8145d964 00000000 00000000 nt!ExpWorkerThread+0x100

f9e8addc 804fa477 804e4729 00000001 00000000 nt!PspSystemThreadStartup+0x34

00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:

Ntfs!NtfsDecodeFileObject+45

f98aeab3 80782c04 cmp byte ptr [eax+0x2c],0x4

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Ntfs!NtfsDecodeFileObject+45

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eea

STACK_COMMAND: .cxr fffffffff9e8a308 ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsDecodeFileObject+45

BUCKET_ID: 0x24_Ntfs!NtfsDecodeFileObject+45

Followup: MachineOwner

2

Although I can’t tell you there the problem exactly is,
I know that bugcheck in NtfsDecodeFileObject almost
always means that you’ve passed down a file object with
a bad FCB (FileObject->FsContext) or CCB (FileObject->FsContext2).

The NtfsDecodeFileObject is the place where Ntfs.sys retrieves
the FCB, SCB, CCB, and whatever-else-CB from the file object.

From the stack shown in your crash dump analysis
and from “Attempt to read from address 0000002e”, I guess that
you are sending down a file object with uninitialized
FsContext, i.e. FileObject for a file that was not open.

L.

3

Thanks for the answer. What I don’t understand: my filter is passive…in
absence of my filter the IRP would have been reached NTFS.SYS just the same.
However, I think I don’t get around to produce and debug this problem.

Thanks anyway.

“Ladislav Zezula” schrieb im Newsbeitrag
news:xxxxx@ntfsd…
> Although I can’t tell you there the problem exactly is,
> I know that bugcheck in NtfsDecodeFileObject almost
> always means that you’ve passed down a file object with
> a bad FCB (FileObject->FsContext) or CCB (FileObject->FsContext2).
>
> The NtfsDecodeFileObject is the place where Ntfs.sys retrieves
> the FCB, SCB, CCB, and whatever-else-CB from the file object.
>
> From the stack shown in your crash dump analysis
> and from “Attempt to read from address 0000002e”, I guess that
> you are sending down a file object with uninitialized
> FsContext, i.e. FileObject for a file that was not open.
>
> L.
>
>
>

4

> Thanks for the answer. What I don’t understand: my filter is passive…in

absence of my filter the IRP would have been reached NTFS.SYS just the
same.

Well, the fact that Ntfs alone does not a crash proves
that the bug is in your filter. Or maybe there’s another filter
which causes the bugcheck.

L.