Strange BSOD

NTDEV
1

Hi all,

I have a strange problem. I attached the driver Verifyer to my mini filter and now get a
*** Fatal System Error: 0x000000c9 (0x00000005,0x8196EF18,0x00000000,0x00000001)

I do understand what this error means, but I can't make sense of why and where this happens.

The Stack looks like this:

nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
nt!KiBugCheckDebugBreak+0x19 (FPO: [Non-Fpo])
nt!KeBugCheck2+0x574 (FPO: [Non-Fpo])
nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo])
nt!IovCallDriver+0xe1 (FPO: [Non-Fpo])
nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo])
nt!IopXxxControlFile+0x611 (FPO: [Non-Fpo])
nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])
nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f9812d64)
ntdll!KiFastSystemCallRet (FPO: [0,0,0])
ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0])
FLTLIB!FilterpDeviceIoControl+0xcc (FPO: [Non-Fpo])
FLTLIB!FilterSendMessage+0x23 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be wrong.
dipStressD+0x95f8b
dipStressD+0x776aa
dipStressD+0xaf142
dipStressD+0xaeefd
kernel32!BaseProcessStart+0x23 (FPO: [Non-Fpo])

As you can see, my dipStressD App tries to send a Filter message, but it looks like as if the bug occurs befor the message reaches my minifilter. Can this be some sideeffect of something Im doing wrong in the Message Receiving Function ? Or should I look somewhere else ?

Greetings,
Marcus

2

!analyze -v helps a lot.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, November 24, 2006 12:54 PM
Subject: [ntdev] Strange BSOD

> Hi all,
>
> I have a strange problem. I attached the driver Verifyer to my mini filter
and now get a
> *** Fatal System Error: 0x000000c9
(0x00000005,0x8196EF18,0x00000000,0x00000001)
>
> I do understand what this error means, but I can’t make sense of why and
where this happens.
>
> The Stack looks like this:
> --------------------
> nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> nt!KiBugCheckDebugBreak+0x19 (FPO: [Non-Fpo])
> nt!KeBugCheck2+0x574 (FPO: [Non-Fpo])
> nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo])
> nt!IovCallDriver+0xe1 (FPO: [Non-Fpo])
> nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo])
> nt!IopXxxControlFile+0x611 (FPO: [Non-Fpo])
> nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])
> nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f9812d64)
> ntdll!KiFastSystemCallRet (FPO: [0,0,0])
> ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0])
> FLTLIB!FilterpDeviceIoControl+0xcc (FPO: [Non-Fpo])
> FLTLIB!FilterSendMessage+0x23 (FPO: [Non-Fpo])
> WARNING: Stack unwind information not available. Following frames may be
wrong.
> dipStressD+0x95f8b
> dipStressD+0x776aa
> dipStressD+0xaf142
> dipStressD+0xaeefd
> kernel32!BaseProcessStart+0x23 (FPO: [Non-Fpo])
> ----------------------------
>
> As you can see, my dipStressD App tries to send a Filter message, but it
looks like as if the bug occurs befor the message reaches my minifilter. Can
this be some sideeffect of something Im doing wrong in the Message Receiving
Function ? Or should I look somewhere else ?
>
> Greetings,
> Marcus
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Ok, I found out that my problem was, that i got an exception between an Acquire/ReleaseMutex, which raises IRQL to APC_LEVEL, then, when returning, the FltLib faulted.

4

>

As you can see, my dipStressD App tries to send a Filter message, but
it looks like as if the bug occurs befor the message reaches my
minifilter.

Looks can be deceiving. You are in IovCallDriver after call your dispatch routine. You have already run through your dispatch routine and come back to IovCallDriver with IRQL at 1 when it should have been 0.

Can this be some sideeffect of something Im doing wrong in
the Message Receiving Function ? Or should I look somewhere else ?

You you have disabled APCs and left them that way.