SYSTEM_SERVICE_EXCEPTION in FltpvVerifyPreOperationStatus()

Brandin_Claar · October 23, 2011, 6:38pm

The following bugcheck occurs while trying to read a memory mapped file using my mini-filter. It manages its own FCBs for a portion of the file hierarchy and redirects the I/O for the files to various archive files using FltCreateFile() and ZwReadFile() to access data during the filter’s create and read pre-operation callbacks. I get this when using the driver verifier. Normal reads work fine. Any idea what the next step would be in trying to figure this one out? Thanks.

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 0000000080000003, Exception code that caused the bugcheck
Arg2: fffff80001c91ad8, Address of the instruction which caused the bugcheck
Arg3: fffff8800ca21aa0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

FAULTING_IP:
nt!DebugPrompt+18
fffff800`01c91ad8 c3 ret

CONTEXT: fffff8800ca21aa0 – (.cxr 0xfffff8800ca21aa0)
.cxr 0xfffff8800ca21aa0
rax=0000000000000002 rbx=fffff88001496a80 rcx=fffff880014b9070
rdx=fffff8800ca2001f rsi=00000000000001e7 rdi=fffff880014b9090
rip=fffff80001c91ad7 rsp=fffff8800ca22488 rbp=fffffa8008558660
r8=fffff8800ca22500 r9=fffff880014b0002 r10=0000000000000000
r11=fffff8800ca224d8 r12=0000000000000004 r13=0000000000000000
r14=fffffa8008558600 r15=000000000000004a
iopl=0 nv up ei pl nz ac pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000212
nt!DebugPrompt+0x17:
fffff800`01c91ad7 cc int 3
.cxr
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: notepad.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80001d21ceb to fffff80001c91ad7

STACK_TEXT:
fffff8800ca22488 fffff80001d21ceb : fffff88001496a80 fffff80001cd5718 fffff88001496a80 00000000000001e7 : nt!DebugPrompt+0x17
fffff8800ca22490 fffff880014b94bb : 0000000000000000 0000000000000000 fffff880014b9060 0000000000000007 : nt!DbgPrompt+0x3b
fffff8800ca224e0 fffff880014ba36d : 0000000000000037 fffffa8008bbf7e0 fffffa8008831a10 0000000000000004 : fltmgr!FltpvPrintErrors+0x11b
fffff8800ca22740 fffff880014badb7 : 0000000000000001 0000000000000044 0000000000000004 fffffa8008831a10 : fltmgr!FltpvVerifyPreOperationStatus+0xad
fffff8800ca22780 fffff8800147c067 : fffff9800cb16ab0 fffff8000212b27e 0000000000000010 fffffa8008831ab0 : fltmgr!FltvPreOperation+0x237
fffff8800ca22890 fffff8800147d329 : fffff8800ca22a00 fffffa8003c0980c fffffa8003c09800 fffff8000213ea00 : fltmgr!FltpPerformPreCallbacks+0x2f7
fffff8800ca22990 fffff8800147b6c7 : fffff9800cb16ab0 fffffa8004ac4040 fffffa8007e11490 fffff80001f8340d : fltmgr!FltpPassThrough+0x2d9
fffff8800ca22a10 fffff8000213fc16 : fffff9800cb16ab0 0000000000000002 fffffa8007f18090 0000000000000000 : fltmgr!FltpDispatch+0xb7
fffff8800ca22a70 fffff80001f8340d : fffff9800cb16ab0 0000000000000001 fffffa8007f18090 fffffa8008b951b0 : nt!IovCallDriver+0x566
fffff8800ca22ad0 fffff80001c98ed3 : fffffa800884b870 fffff8800ca22ca0 000000000013da68 fffff8800ca22bc8 : nt!NtQueryDirectoryFile+0x1ad
fffff8800ca22bb0 00000000776d166a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000000013da48 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x776d166a

FOLLOWUP_IP:
nt!DebugPrompt+18
fffff800`01c91ad8 c3 ret

SYMBOL_NAME: nt!DebugPrompt+18

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

STACK_COMMAND: .cxr 0xfffff8800ca21aa0 ; kb

FAILURE_BUCKET_ID: X64_0x3B_VRF_nt!DebugPrompt+18

BUCKET_ID: X64_0x3B_VRF_nt!DebugPrompt+18

Followup: MachineOwner

rod_widdowson · October 24, 2011, 3:38am

> Arg1: 0000000080000003, Exception code that caused the bugcheck

fffff8800ca22490 [snip] : nt!DbgPrompt+0x3b fffff8800ca224e0 [snip] : fltmgr!FltpvPrintErrors+0x11b

Fltmgr has issued a debug message and there is no debugger attached. Are
you using the checked build of fltmgr? If not that would be a bug in
fltmgr.

You need to find out what fltmgr is trying to tell you and fix that. If its
reproducible the easiest thing is to run this with a debugger attached.

Alex_Carp · October 24, 2011, 3:25pm

As Rod said, you need a debugger attached whenever you’re running with driver verifier. FltpvVerifyPreOperationStatus is simply one of FLtMgr’s functions that checks that things are OK when verifier is running. If you had a debugger attached there should be a message that explains what FltMgr thinks you might be doing wrong.

THanks,
Alex.

Scott_Noone_OSR · October 26, 2011, 12:35pm

Note that, depending on your configuration, sometimes !dbgprint can be used
to recover the DbgPrints before the crash. If not, you can always troll back
through the disassembly and recover the message.

Or just repro with the debugger attached

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…

As Rod said, you need a debugger attached whenever you’re running with
driver verifier. FltpvVerifyPreOperationStatus is simply one of FLtMgr’s
functions that checks that things are OK when verifier is running. If you
had a debugger attached there should be a message that explains what FltMgr
thinks you might be doing wrong.

THanks,
Alex.

rod_widdowson · October 27, 2011, 3:25am

> As Rod said, you need a debugger attached whenever you’re running with

driver verifier

I just read this again and did a double take.

Does this mean that if you ask a customer to turn on verifier to debug an
issue they are having (say pool corruption) then FltMgr will take down the
machine in a non-obvious way if it spots something weird?

I’m completely happy with it bringing down the machine after all if you
didn’t wajnt it to you wouldn’t be running verifier, and I love the extra
tests that fltmgr does under verifier, but I’m worried that the value of
verifier as an “in the field” tool is being reduced…

Scott_Noone_OSR · October 27, 2011, 9:28am

“Rod Widdowson” wrote in message news:xxxxx@ntfsd…

Does this mean that if you ask a customer to turn on verifier to debug an
issue they are having (say pool corruption) then FltMgr will take down the
machine in a non-obvious way if it spots something weird?

That’s my understanding as well. AFAIK none of the Verifiers attempt to “do
the right thing” if the debugger isn’t attached…

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Rod Widdowson” wrote in message news:xxxxx@ntfsd…

As Rod said, you need a debugger attached whenever you’re running with
driver verifier

I just read this again and did a double take.

Does this mean that if you ask a customer to turn on verifier to debug an
issue they are having (say pool corruption) then FltMgr will take down the
machine in a non-obvious way if it spots something weird?

I’m completely happy with it bringing down the machine after all if you
didn’t wajnt it to you wouldn’t be running verifier, and I love the extra
tests that fltmgr does under verifier, but I’m worried that the value of
verifier as an “in the field” tool is being reduced…

OSR_Community_User · October 27, 2011, 11:20am

> That’s my understanding as well. AFAIK none of the Verifiers attempt to "do

the right thing" if the debugger isn’t attached…

I think that the only task of Verifier is to bugcheck in a proper way if something went wrong.

This really works fine without the debugger.

BTW - Verifier slows down DeviceIoControl a lot, so, if you have some O(N^2) code calling DeviceIoControl (or any other kernel32 functions like the mount point management which do DeviceIoControl) - then, with Verifier, this path can run for minutes. Literally so.

Surely it is better to get rid of O(N^2), but sometimes there are other features on the schedule to do

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Scott_Noone_OSR · October 27, 2011, 11:49am

“Maxim S. Shatskih” wrote in message news:xxxxx@ntfsd…

This really works fine without the debugger.

The only time it’s an issue is in a case like this, where the crash is the
result of a DbgPrompt instead of an explicit KeBugCheck. In this case you
have to be crafty enough to be able to recover the original DbgPrint
explaining the breakpoint. While we could argue about how hard this is, for
new kernel developers it can be confusing.

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

OSR_Community_User · October 27, 2011, 12:33pm

> result of a DbgPrompt instead of an explicit KeBugCheck.

Bugcheck codes and the stack are usually enough for Verifier crashes.

Actually, I nearly never use Verifier+debugger. I run the large test suite in batch mode on a machine with Verifier on, and analyze the crashes if they occur from the dumps (usually they do not ).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Scott_Noone_OSR · October 27, 2011, 2:20pm

“Maxim S. Shatskih” wrote in message news:xxxxx@ntfsd…

Bugcheck codes and the stack are usually enough for Verifier crashes.

For Driver Verifier’s C4 bugcheck code I agree, *usually* the bugcheck code
is enough to interpret what’s going on and give you a place to start.
However, in the case of a “soft” Verifier failure (such as the ones used by
Filter Manager Verifier) I’d argue it’s not so straightforward. For example,
take a look at the OP’s bugcheck code:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 0000000080000003, Exception code that caused the bugcheck
Arg2: fffff80001c91ad8, Address of the instruction which caused the bugcheck
Arg3: fffff8800ca21aa0, Address of the context record for the exception that
caused the bugcheck
Arg4: 0000000000000000, zero.

Based on that, I can’t immediately tell you the Filter Manager Verifier
failure. And brief inspection of the call stack isn’t much more helpful
because it’s coming from a generic Filter Manager wrapper function:

nt!DebugPrompt+0x17
nt!DbgPrompt+0x3b
fltmgr!FltpvPrintErrors+0x11b
fltmgr!FltpvVerifyPreOperationStatus+0xad
fltmgr!FltvPreOperation+0x237
fltmgr!FltpPerformPreCallbacks+0x2f7
fltmgr!FltpPassThrough+0x2d9

As experienced devs we tend to take for granted what it takes to decipher
this crash code:

Understanding what context records are, so that we know to use .cxr
fffff8800ca21aa0 as our starting point
Understanding that this is a DbgPrompt, therefore there a debug message
that explains the error
Understanding the x64 calling convention enough to know where to look for
the debug print string
Understanding that the “Args to Child” in the debug output aren’t
necessarily the arguments to the function
Knowing enough x64 assembly to be able to recover the original parameter
Knowing that “da” can be used to print an ASCII string

Meanwhile, if the debugger had been attached the OP would have gotten a
nice, clear (hopefully) DbgPrint explaining what the error was.

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

Alex_Carp · October 27, 2011, 3:02pm

Sorry, i didn’t mean to say that FltMgr’s verifier checks are impossible to understand by anyone under any circumstance without a debugger attached, though reading it now I do realize that my statement can be interpreted in that fashion.

From the OP i got the sense that he was running this in his own environment as opposed to a customer deployment and I also got the sense that he tried but couldn’t figure out how to get the message and hence that was my recommendation. I’m sorry i wasn’t more clear that it was just a recommendation.

Thanks,
Alex.