How do we get FILTER VERIFIER ERROR on Minifilter unload? (!fltkd.filter)

NTFSD
1

Hi All,

My minifilter crashes during unload witch Bugcheck code 7E with first parameter 0x80000003 in Vista. A tiny small stack trace shows it occurs somewhere in filter manager trying to print debug message.

I know there is an issue in my minifilter during unload due to dangling references to stream handle contexts. In other words, I printed out those stream handle contexts not cleaned up during instance teardown stage and there are a number of those not cleaned.

All I want is the ability to use !fltkd.filter command on the memory dump whe I get FILTER VERIFIER ERROR. But it seems like the bugcheck occurs during print attempt somewhere in fltmgr.

FYI, I use Vista free build. I tried to use checked build several times, but no success. Is that the cause of this funny symptom I’m getting?

Any suggestion would be valuable to my mental and physical health. Thanks a lot.

Regards,
Sean Park

2

Hi!

Consider posting the stack, so that people can make sense out of it.

And ya, answer to “How do we get FILTER VERIFIER ERROR on Minifilter unload?” is:
BAD PROGRAMMING… :slight_smile:

Regards,
Ayush Gupta

3

It does seem odd that in a free build Fltgr would do a DbgOutput.

I’m assuming that you cannot just attach a debugger and see what FltMgr is
trying to say to you. I’ll bet you its saying “You have some stream handle
contents still active and here are their addresses”.

R

wrote in message news:xxxxx@ntfsd…
> Hi All,
>
> My minifilter crashes during unload witch Bugcheck code 7E with first
> parameter 0x80000003 in Vista. A tiny small stack trace shows it occurs
> somewhere in filter manager trying to print debug message.
>
> I know there is an issue in my minifilter during unload due to dangling
> references to stream handle contexts. In other words, I printed out those
> stream handle contexts not cleaned up during instance teardown stage and
> there are a number of those not cleaned.
>
> All I want is the ability to use !fltkd.filter command on the memory dump
> whe I get FILTER VERIFIER ERROR. But it seems like the bugcheck occurs
> during print attempt somewhere in fltmgr.
>
> FYI, I use Vista free build. I tried to use checked build several times,
> but no success. Is that the cause of this funny symptom I’m getting?
>
> Any suggestion would be valuable to my mental and physical health. Thanks
> a lot.
>
> Regards,
> Sean Park
>

4

In my experience, you don’t need to run a full checked build just to test a minfilter. Just running with the checked filter manager from the checked build on a free build can find a lot of issues (of course, the checked and free versions of fltmgr.sys (and of the OS for that matter) must match).

Anyway, a stack trace would help a lot.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Friday, January 09, 2009 3:33 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How do we get FILTER VERIFIER ERROR on Minifilter unload? (!fltkd.filter)

It does seem odd that in a free build Fltgr would do a DbgOutput.

I’m assuming that you cannot just attach a debugger and see what FltMgr is
trying to say to you. I’ll bet you its saying “You have some stream handle
contents still active and here are their addresses”.

R

wrote in message news:xxxxx@ntfsd…
> Hi All,
>
> My minifilter crashes during unload witch Bugcheck code 7E with first
> parameter 0x80000003 in Vista. A tiny small stack trace shows it occurs
> somewhere in filter manager trying to print debug message.
>
> I know there is an issue in my minifilter during unload due to dangling
> references to stream handle contexts. In other words, I printed out those
> stream handle contexts not cleaned up during instance teardown stage and
> there are a number of those not cleaned.
>
> All I want is the ability to use !fltkd.filter command on the memory dump
> whe I get FILTER VERIFIER ERROR. But it seems like the bugcheck occurs
> during print attempt somewhere in fltmgr.
>
> FYI, I use Vista free build. I tried to use checked build several times,
> but no success. Is that the cause of this funny symptom I’m getting?
>
> Any suggestion would be valuable to my mental and physical health. Thanks
> a lot.
>
> Regards,
> Sean Park
>

—
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@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Thanks for your replies,

In short, I'd like to trace back the bug in my code related to dangling references. I'm simply using free build of Vista and Driver verifier with I/O verification turned on. As I described in my OP, I don't receive FILTER VERIFIER ERROR bugcheck during minifilter unload, which I need to start debugging. And that's the problem I've got and the point of discussion in this thread.

It seems like I don't know what everybody knows. What are the testing environment you guys have? Vista checked build? (If so, could you tell me how to set it up properly? None of the descriptions I found on the web doesn't seem to work...) My minifilter crashes about 20 sec after 'fltmc unload mydriver' got executed.

Any suggestions will be appreciated.
I'm attaching the stack trace (which I think isn't useful at all). Remember I'm just debugging locally (no firewire, usb, etc) investigating local memory dump.

Regards,
Sean Park

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: 80000003, The exception code that was not handled
Arg2: 81f12855, The address that the exception occurred at
Arg3: 853659b0, Exception Record Address
Arg4: 853656ac, Context Record Address

Debugging Details:

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

FAULTING_IP:
nt!DbgPrompt+46
81f12855 cc int 3

EXCEPTION_RECORD: 853659b0 -- (.exr 0xffffffff853659b0)
ExceptionAddress: 81f12855 (nt!DbgPrompt+0x00000046)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000002
Parameter[1]: 8295c060
Parameter[2]: 0000001f

CONTEXT: 853656ac -- (.cxr 0xffffffff853656ac)
eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061 edi=00000002
eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000212
nt!DbgPrompt+0x46:
81f12855 cc int 3
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x7E

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.

EXCEPTION_PARAMETER1: 00000002

EXCEPTION_PARAMETER2: 8295c060

EXCEPTION_PARAMETER3: 0000001f

LAST_CONTROL_TRANSFER: from 8295ad65 to 81f12855

STACK_TEXT:
85365a94 8295ad65 8295c060 85365ab4 00000002 nt!DbgPrompt+0x46
85365cc0 8295b2c5 00000029 891172b8 90defb20 fltmgr!FltpvPrintErrors+0xeb
85365d44 81e6e445 85361b18 00000000 840e5580 fltmgr!FltpvDoLostObjectCheck+0x14d
85365d7c 8200bb18 85361b18 c11f9a68 00000000 nt!ExpWorkerThread+0xfd
85365dc0 81e64a2e 81e6e348 00000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!DbgPrompt+46
81f12855 cc int 3

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!DbgPrompt+46

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 48d1b7fa

STACK_COMMAND: .cxr 0xffffffff853656ac ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46

BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46

Followup: MachineOwner

0: kd> .exr 0xffffffff853659b0
ExceptionAddress: 81f12855 (nt!DbgPrompt+0x00000046)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000002
Parameter[1]: 8295c060
Parameter[2]: 0000001f
0: kd> .cxr 0xffffffff853656ac
eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061 edi=00000002
eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000212
nt!DbgPrompt+0x46:
81f12855 cc int 3
0: kd> .cxr 0xffffffff853656ac ; kb
eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061 edi=00000002
eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000212
nt!DbgPrompt+0x46:
81f12855 cc int 3
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
85365a94 8295ad65 8295c060 85365ab4 00000002 nt!DbgPrompt+0x46
85365cc0 8295b2c5 00000029 891172b8 90defb20 fltmgr!FltpvPrintErrors+0xeb
85365d44 81e6e445 85361b18 00000000 840e5580 fltmgr!FltpvDoLostObjectCheck+0x14d
85365d7c 8200bb18 85361b18 c11f9a68 00000000 nt!ExpWorkerThread+0xfd
85365dc0 81e64a2e 81e6e348 00000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

6

You cannot debug issues like this using a dump or windbg on the same machine
as the SUT (system under test). Windbg is designed to work remote. There
are some things you can do locally, but it is much more limited. You could
use VMWare and run your driver in the VM where windbg is running in the host
machine. That works very well for file systems work, but not for real
hardware devices.

wrote in message news:xxxxx@ntfsd…
> Thanks for your replies,
>
> In short, I’d like to trace back the bug in my code related to dangling
> references. I’m simply using free build of Vista and Driver verifier with
> I/O verification turned on. As I described in my OP, I don’t receive
> FILTER VERIFIER ERROR bugcheck during minifilter unload, which I need to
> start debugging. And that’s the problem I’ve got and the point of
> discussion in this thread.
>
> It seems like I don’t know what everybody knows. What are the testing
> environment you guys have? Vista checked build? (If so, could you tell me
> how to set it up properly? None of the descriptions I found on the web
> doesn’t seem to work…) My minifilter crashes about 20 sec after ‘fltmc
> unload mydriver’ got executed.
>
> Any suggestions will be appreciated.
> I’m attaching the stack trace (which I think isn’t useful at all).
> Remember I’m just debugging locally (no firewire, usb, etc) investigating
> local memory dump.
>
> Regards,
> Sean Park
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
> 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.
> Arguments:
> Arg1: 80000003, The exception code that was not handled
> Arg2: 81f12855, The address that the exception occurred at
> Arg3: 853659b0, Exception Record Address
> Arg4: 853656ac, Context Record Address
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments
> are invalid
>
> FAULTING_IP:
> nt!DbgPrompt+46
> 81f12855 cc int 3
>
> EXCEPTION_RECORD: 853659b0 – (.exr 0xffffffff853659b0)
> ExceptionAddress: 81f12855 (nt!DbgPrompt+0x00000046)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 3
> Parameter[0]: 00000002
> Parameter[1]: 8295c060
> Parameter[2]: 0000001f
>
> CONTEXT: 853656ac – (.cxr 0xffffffff853656ac)
> eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061
> edi=00000002
> eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000212
> nt!DbgPrompt+0x46:
> 81f12855 cc int 3
> Resetting default scope
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0x7E
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint
> has been reached.
>
> EXCEPTION_PARAMETER1: 00000002
>
> EXCEPTION_PARAMETER2: 8295c060
>
> EXCEPTION_PARAMETER3: 0000001f
>
> LAST_CONTROL_TRANSFER: from 8295ad65 to 81f12855
>
> STACK_TEXT:
> 85365a94 8295ad65 8295c060 85365ab4 00000002 nt!DbgPrompt+0x46
> 85365cc0 8295b2c5 00000029 891172b8 90defb20 fltmgr!FltpvPrintErrors+0xeb
> 85365d44 81e6e445 85361b18 00000000 840e5580
> fltmgr!FltpvDoLostObjectCheck+0x14d
> 85365d7c 8200bb18 85361b18 c11f9a68 00000000 nt!ExpWorkerThread+0xfd
> 85365dc0 81e64a2e 81e6e348 00000001 00000000
> nt!PspSystemThreadStartup+0x9d
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> nt!DbgPrompt+46
> 81f12855 cc int 3
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: nt!DbgPrompt+46
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrpamp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 48d1b7fa
>
> STACK_COMMAND: .cxr 0xffffffff853656ac ; kb
>
> FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>
> BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>
> Followup: MachineOwner
> ---------
>
> 0: kd> .exr 0xffffffff853659b0
> ExceptionAddress: 81f12855 (nt!DbgPrompt+0x00000046)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 3
> Parameter[0]: 00000002
> Parameter[1]: 8295c060
> Parameter[2]: 0000001f
> 0: kd> .cxr 0xffffffff853656ac
> eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061
> edi=00000002
> eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000212
> nt!DbgPrompt+0x46:
> 81f12855 cc int 3
> 0: kd> .cxr 0xffffffff853656ac ; kb
> eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061
> edi=00000002
> eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000212
> nt!DbgPrompt+0x46:
> 81f12855 cc int 3
> *** Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr Args to Child
> 85365a94 8295ad65 8295c060 85365ab4 00000002 nt!DbgPrompt+0x46
> 85365cc0 8295b2c5 00000029 891172b8 90defb20 fltmgr!FltpvPrintErrors+0xeb
> 85365d44 81e6e445 85361b18 00000000 840e5580
> fltmgr!FltpvDoLostObjectCheck+0x14d
> 85365d7c 8200bb18 85361b18 c11f9a68 00000000 nt!ExpWorkerThread+0xfd
> 85365dc0 81e64a2e 81e6e348 00000001 00000000
> nt!PspSystemThreadStartup+0x9d
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>

7

Thanks for your advice, David.

I started testing in real Vista because running vista in VM was too slow and there are so many hidden bugs unnoticed in VM, which eventually appears in real machine. I’ll take your advice, David.

Thanks again.

Regards,
Sean Park

8

Since I work on NDIS miniports, I prefer using a test system. I normally
use a notebook for my development environment and windbg host. I use 1394a
or serial when needed. Very little impact is made by a VM if you use VMWare
for file systems and their filters. I cannot think of any problems other
than timing/speed in that environment, however testing on real systems is
still required.

wrote in message news:xxxxx@ntfsd…
> Thanks for your advice, David.
>
> I started testing in real Vista because running vista in VM was too slow
> and there are so many hidden bugs unnoticed in VM, which eventually
> appears in real machine. I’ll take your advice, David.
>
> Thanks again.
>
> Regards,
> Sean Park
>

9

This is filter manager verifier breaking into the debugger because you
have a leaked resource somewhere. There should be a message in the
debugger telling you what command to use to get more information about
what you have leaked.

If you cannot find that use: "!fltkd.filter

8 1"

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided "AS IS" with no warranties, and confers no Rights

xxxxx@hotmail.com wrote:
> Thanks for your replies,
>
> In short, I'd like to trace back the bug in my code related to dangling references. I'm simply using free build of Vista and Driver verifier with I/O verification turned on. As I described in my OP, I don't receive FILTER VERIFIER ERROR bugcheck during minifilter unload, which I need to start debugging. And that's the problem I've got and the point of discussion in this thread.
>
> It seems like I don't know what everybody knows. What are the testing environment you guys have? Vista checked build? (If so, could you tell me how to set it up properly? None of the descriptions I found on the web doesn't seem to work...) My minifilter crashes about 20 sec after 'fltmc unload mydriver' got executed.
>
> Any suggestions will be appreciated.
> I'm attaching the stack trace (which I think isn't useful at all). Remember I'm just debugging locally (no firewire, usb, etc) investigating local memory dump.
>
> Regards,
> Sean Park
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
> 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.
> Arguments:
> Arg1: 80000003, The exception code that was not handled
> Arg2: 81f12855, The address that the exception occurred at
> Arg3: 853659b0, Exception Record Address
> Arg4: 853656ac, Context Record Address
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
>
> FAULTING_IP:
> nt!DbgPrompt+46
> 81f12855 cc int 3
>
> EXCEPTION_RECORD: 853659b0 -- (.exr 0xffffffff853659b0)
> ExceptionAddress: 81f12855 (nt!DbgPrompt+0x00000046)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 3
> Parameter[0]: 00000002
> Parameter[1]: 8295c060
> Parameter[2]: 0000001f
>
> CONTEXT: 853656ac -- (.cxr 0xffffffff853656ac)
> eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061 edi=00000002
> eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000212
> nt!DbgPrompt+0x46:
> 81f12855 cc int 3
> Resetting default scope
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0x7E
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
>
> EXCEPTION_PARAMETER1: 00000002
>
> EXCEPTION_PARAMETER2: 8295c060
>
> EXCEPTION_PARAMETER3: 0000001f
>
> LAST_CONTROL_TRANSFER: from 8295ad65 to 81f12855
>
> STACK_TEXT:
> 85365a94 8295ad65 8295c060 85365ab4 00000002 nt!DbgPrompt+0x46
> 85365cc0 8295b2c5 00000029 891172b8 90defb20 fltmgr!FltpvPrintErrors+0xeb
> 85365d44 81e6e445 85361b18 00000000 840e5580 fltmgr!FltpvDoLostObjectCheck+0x14d
> 85365d7c 8200bb18 85361b18 c11f9a68 00000000 nt!ExpWorkerThread+0xfd
> 85365dc0 81e64a2e 81e6e348 00000001 00000000 nt!PspSystemThreadStartup+0x9d
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> nt!DbgPrompt+46
> 81f12855 cc int 3
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: nt!DbgPrompt+46
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrpamp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 48d1b7fa
>
> STACK_COMMAND: .cxr 0xffffffff853656ac ; kb
>
> FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>
> BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>
> Followup: MachineOwner
> ---------
>
> 0: kd> .exr 0xffffffff853659b0
> ExceptionAddress: 81f12855 (nt!DbgPrompt+0x00000046)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 3
> Parameter[0]: 00000002
> Parameter[1]: 8295c060
> Parameter[2]: 0000001f
> 0: kd> .cxr 0xffffffff853656ac
> eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061 edi=00000002
> eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000212
> nt!DbgPrompt+0x46:
> 81f12855 cc int 3
> 0: kd> .cxr 0xffffffff853656ac ; kb
> eax=00000002 ebx=85365ab4 ecx=8295c060 edx=0000001f esi=8295c061 edi=00000002
> eip=81f12855 esp=85365a78 ebp=85365a94 iopl=0 nv up ei pl nz ac po nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000212
> nt!DbgPrompt+0x46:
> 81f12855 cc int 3
> *** Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr Args to Child
> 85365a94 8295ad65 8295c060 85365ab4 00000002 nt!DbgPrompt+0x46
> 85365cc0 8295b2c5 00000029 891172b8 90defb20 fltmgr!FltpvPrintErrors+0xeb
> 85365d44 81e6e445 85361b18 00000000 840e5580 fltmgr!FltpvDoLostObjectCheck+0x14d
> 85365d7c 8200bb18 85361b18 c11f9a68 00000000 nt!ExpWorkerThread+0xfd
> 85365dc0 81e64a2e 81e6e348 00000001 00000000 nt!PspSystemThreadStartup+0x9d
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>