Verifier problem in Vista?

OSR_Community_User · September 17, 2007, 11:58am

NTFSD Folk:

I have my minifilter set for monitoring by Verifier on a standard (non-checked) Vista system, fully patched. Occasionally, I get a
BSOD in fltmgr like below. I *think* it’s trying to output a message of some sort, but failing rather badly.

Anybody else seen anything like this? Suggestions?

Thanks,
Ken

Windows Vista Kernel Version 6000 UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6000.16514.x86fre.vista_gdr.070627-1500
Kernel base = 0x82000000 PsLoadedModuleList = 0x82111db0
Debug session time: Mon Sep 17 11:37:15.930 2007 (GMT-4)
System Uptime: 5 days 17:22:29.213
Loading Kernel Symbols
…
…
Loading User Symbols
Loading unloaded module list
…
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
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.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: 80000003, The exception code that was not handled
Arg2: 8205514d, The address that the exception occurred at
Arg3: 833cb9b0, Exception Record Address
Arg4: 833cb6ac, Context Record Address

Debugging Details:

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

FAULTING_IP:
nt!DbgPrompt+46
8205514d cc int 3

EXCEPTION_RECORD: 833cb9b0 – (.exr ffffffff833cb9b0)
ExceptionAddress: 8205514d (nt!DbgPrompt+0x00000046)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000002
Parameter[1]: 80779060
Parameter[2]: 0000001f

CONTEXT: 833cb6ac – (.cxr ffffffff833cb6ac)
eax=00000002 ebx=833cbab4 ecx=80779060 edx=0000001f esi=80779061 edi=00000002
eip=8205514d esp=833cba78 ebp=833cba94 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:
8205514d cc int 3
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: STATUS_BREAKPOINT

BUGCHECK_STR: 0x7E

PROCESS_NAME: System

CURRENT_IRQL: 0

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

LAST_CONTROL_TRANSFER: from 80777d65 to 8205514d

STACK_TEXT:
833cba94 80777d65 80779060 833cbab4 00000002 nt!DbgPrompt+0x46
833cbcc0 807782c5 00000029 92aa9280 92accd58 fltmgr!FltpvPrintErrors+0xeb
833cbd44 82078db8 833c7af0 00000000 84c6c2d8 fltmgr!FltpvDoLostObjectCheck+0x14d
833cbd7c 82225472 833c7af0 833c0680 00000000 nt!ExpWorkerThread+0xfd
833cbdc0 8209141e 82078cbb 00000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!DbgPrompt+46
8205514d 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: 468308e9

STACK_COMMAND: .cxr 0xffffffff833cb6ac ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46

BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46

Followup: MachineOwner

Don_Burn_1 · September 17, 2007, 12:07pm

Ken,

DebugPrompt puts out a message then waits for a response. In this
case it is indentifying a resource you forgot to free up in your filter.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Ken Cross” wrote in message news:xxxxx@ntdev…
> NTFSD Folk:
>
> I have my minifilter set for monitoring by Verifier on a standard
> (non-checked) Vista system, fully patched. Occasionally, I get a
> BSOD in fltmgr like below. I think it’s trying to output a message of
> some sort, but failing rather badly.
>
> Anybody else seen anything like this? Suggestions?
>
> Thanks,
> Ken
>
>
>
> Windows Vista Kernel Version 6000 UP Free x86 compatible
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 6000.16514.x86fre.vista_gdr.070627-1500
> Kernel base = 0x82000000 PsLoadedModuleList = 0x82111db0
> Debug session time: Mon Sep 17 11:37:15.930 2007 (GMT-4)
> System Uptime: 5 days 17:22:29.213
> Loading Kernel Symbols
> …
> …
> Loading User Symbols
> Loading unloaded module list
> …
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
> 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.
> Some common problems are exception code 0x80000003. This means a hard
> coded breakpoint or assertion was hit, but this system was booted
> /NODEBUG. This is not supposed to happen as developers should never have
> hardcoded breakpoints in retail code, but …
> If this happens, make sure a debugger gets connected, and the
> system is booted /DEBUG. This will let us see why this breakpoint is
> happening.
> Arguments:
> Arg1: 80000003, The exception code that was not handled
> Arg2: 8205514d, The address that the exception occurred at
> Arg3: 833cb9b0, Exception Record Address
> Arg4: 833cb6ac, Context Record Address
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments
> are invalid
>
> FAULTING_IP:
> nt!DbgPrompt+46
> 8205514d cc int 3
>
> EXCEPTION_RECORD: 833cb9b0 – (.exr ffffffff833cb9b0)
> ExceptionAddress: 8205514d (nt!DbgPrompt+0x00000046)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 3
> Parameter[0]: 00000002
> Parameter[1]: 80779060
> Parameter[2]: 0000001f
>
> CONTEXT: 833cb6ac – (.cxr ffffffff833cb6ac)
> eax=00000002 ebx=833cbab4 ecx=80779060 edx=0000001f esi=80779061
> edi=00000002
> eip=8205514d esp=833cba78 ebp=833cba94 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:
> 8205514d cc int 3
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
>
> BUGCHECK_STR: 0x7E
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint
> has been reached.
>
> LAST_CONTROL_TRANSFER: from 80777d65 to 8205514d
>
> STACK_TEXT:
> 833cba94 80777d65 80779060 833cbab4 00000002 nt!DbgPrompt+0x46
> 833cbcc0 807782c5 00000029 92aa9280 92accd58 fltmgr!FltpvPrintErrors+0xeb
> 833cbd44 82078db8 833c7af0 00000000 84c6c2d8
> fltmgr!FltpvDoLostObjectCheck+0x14d
> 833cbd7c 82225472 833c7af0 833c0680 00000000 nt!ExpWorkerThread+0xfd
> 833cbdc0 8209141e 82078cbb 00000001 00000000
> nt!PspSystemThreadStartup+0x9d
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> nt!DbgPrompt+46
> 8205514d 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: 468308e9
>
> STACK_COMMAND: .cxr 0xffffffff833cb6ac ; kb
>
> FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>
> BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>
> Followup: MachineOwner
> ---------
>
>
>
>

OSR_Community_User · September 18, 2007, 12:19pm

Yeah, I figured that much out. But (1) it’s not a checked build, so (2) there’s no place to provide a response, plus (3) I’d kinda
like to know what isn’t getting freed up, and (4) it just seems rude for fltmgr to bluescreen.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, September 17, 2007 12:07 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Verifier problem in Vista?

Ken,

DebugPrompt puts out a message then waits for a response. In this
case it is indentifying a resource you forgot to free up in your filter.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Ken Cross” wrote in message news:xxxxx@ntdev…
> NTFSD Folk:
>
> I have my minifilter set for monitoring by Verifier on a standard
> (non-checked) Vista system, fully patched. Occasionally, I get a
> BSOD in fltmgr like below. I think it’s trying to output a message of
> some sort, but failing rather badly.
>
> Anybody else seen anything like this? Suggestions?
>
> Thanks,
> Ken
>
>
>
> Windows Vista Kernel Version 6000 UP Free x86 compatible
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 6000.16514.x86fre.vista_gdr.070627-1500
> Kernel base = 0x82000000 PsLoadedModuleList = 0x82111db0
> Debug session time: Mon Sep 17 11:37:15.930 2007 (GMT-4)
> System Uptime: 5 days 17:22:29.213
> Loading Kernel Symbols
>
…
> …
> Loading User Symbols
> Loading unloaded module list
> …
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
> 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.
> Some common problems are exception code 0x80000003. This means a hard
> coded breakpoint or assertion was hit, but this system was booted
> /NODEBUG. This is not supposed to happen as developers should never have
> hardcoded breakpoints in retail code, but …
> If this happens, make sure a debugger gets connected, and the
> system is booted /DEBUG. This will let us see why this breakpoint is
> happening.
> Arguments:
> Arg1: 80000003, The exception code that was not handled
> Arg2: 8205514d, The address that the exception occurred at
> Arg3: 833cb9b0, Exception Record Address
> Arg4: 833cb6ac, Context Record Address
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments
> are invalid
>
> FAULTING_IP:
> nt!DbgPrompt+46
> 8205514d cc int 3
>
> EXCEPTION_RECORD: 833cb9b0 – (.exr ffffffff833cb9b0)
> ExceptionAddress: 8205514d (nt!DbgPrompt+0x00000046)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 3
> Parameter[0]: 00000002
> Parameter[1]: 80779060
> Parameter[2]: 0000001f
>
> CONTEXT: 833cb6ac – (.cxr ffffffff833cb6ac)
> eax=00000002 ebx=833cbab4 ecx=80779060 edx=0000001f esi=80779061
> edi=00000002
> eip=8205514d esp=833cba78 ebp=833cba94 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:
> 8205514d cc int 3
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
>
> BUGCHECK_STR: 0x7E
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint
> has been reached.
>
> LAST_CONTROL_TRANSFER: from 80777d65 to 8205514d
>
> STACK_TEXT:
> 833cba94 80777d65 80779060 833cbab4 00000002 nt!DbgPrompt+0x46
> 833cbcc0 807782c5 00000029 92aa9280 92accd58 fltmgr!FltpvPrintErrors+0xeb
> 833cbd44 82078db8 833c7af0 00000000 84c6c2d8
> fltmgr!FltpvDoLostObjectCheck+0x14d
> 833cbd7c 82225472 833c7af0 833c0680 00000000 nt!ExpWorkerThread+0xfd
> 833cbdc0 8209141e 82078cbb 00000001 00000000
> nt!PspSystemThreadStartup+0x9d
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> nt!DbgPrompt+46
> 8205514d 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: 468308e9
>
> STACK_COMMAND: .cxr 0xffffffff833cb6ac ; kb
>
> FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>
> BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>
> Followup: MachineOwner
> ---------
>
>
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Don_Burn_1 · September 18, 2007, 12:22pm

Ken,

FltMgr only calls this if it thinks you have WinDBG attached and you
have the Verifier on. In that case I don’t think asking for a response is
that bad.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Ken Cross” wrote in message news:xxxxx@ntdev…
> Yeah, I figured that much out. But (1) it’s not a checked build, so (2)
> there’s no place to provide a response, plus (3) I’d kinda
> like to know what isn’t getting freed up, and (4) it just seems rude for
> fltmgr to bluescreen.
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Monday, September 17, 2007 12:07 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Verifier problem in Vista?
>
> Ken,
>
> DebugPrompt puts out a message then waits for a response. In this
> case it is indentifying a resource you forgot to free up in your filter.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “Ken Cross” wrote in message news:xxxxx@ntdev…
>> NTFSD Folk:
>>
>> I have my minifilter set for monitoring by Verifier on a standard
>> (non-checked) Vista system, fully patched. Occasionally, I get a
>> BSOD in fltmgr like below. I think it’s trying to output a message of
>> some sort, but failing rather badly.
>>
>> Anybody else seen anything like this? Suggestions?
>>
>> Thanks,
>> Ken
>>
>>
>>
>> Windows Vista Kernel Version 6000 UP Free x86 compatible
>> Product: WinNt, suite: TerminalServer SingleUserTS
>> Built by: 6000.16514.x86fre.vista_gdr.070627-1500
>> Kernel base = 0x82000000 PsLoadedModuleList = 0x82111db0
>> Debug session time: Mon Sep 17 11:37:15.930 2007 (GMT-4)
>> System Uptime: 5 days 17:22:29.213
>> Loading Kernel Symbols
>>
> …
>> …
>> Loading User Symbols
>> Loading unloaded module list
>> …
>> kd> !analyze -v
>> *****
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>
>>
>> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
>> 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.
>> Some common problems are exception code 0x80000003. This means a hard
>> coded breakpoint or assertion was hit, but this system was booted
>> /NODEBUG. This is not supposed to happen as developers should never
>> have
>> hardcoded breakpoints in retail code, but …
>> If this happens, make sure a debugger gets connected, and the
>> system is booted /DEBUG. This will let us see why this breakpoint is
>> happening.
>> Arguments:
>> Arg1: 80000003, The exception code that was not handled
>> Arg2: 8205514d, The address that the exception occurred at
>> Arg3: 833cb9b0, Exception Record Address
>> Arg4: 833cb6ac, Context Record Address
>>
>> Debugging Details:
>> ------------------
>>
>>
>> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more
>> arguments
>> are invalid
>>
>> FAULTING_IP:
>> nt!DbgPrompt+46
>> 8205514d cc int 3
>>
>> EXCEPTION_RECORD: 833cb9b0 – (.exr ffffffff833cb9b0)
>> ExceptionAddress: 8205514d (nt!DbgPrompt+0x00000046)
>> ExceptionCode: 80000003 (Break instruction exception)
>> ExceptionFlags: 00000000
>> NumberParameters: 3
>> Parameter[0]: 00000002
>> Parameter[1]: 80779060
>> Parameter[2]: 0000001f
>>
>> CONTEXT: 833cb6ac – (.cxr ffffffff833cb6ac)
>> eax=00000002 ebx=833cbab4 ecx=80779060 edx=0000001f esi=80779061
>> edi=00000002
>> eip=8205514d esp=833cba78 ebp=833cba94 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:
>> 8205514d cc int 3
>> Resetting default scope
>>
>> CUSTOMER_CRASH_COUNT: 1
>>
>> DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
>>
>> BUGCHECK_STR: 0x7E
>>
>> PROCESS_NAME: System
>>
>> CURRENT_IRQL: 0
>>
>> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A
>> breakpoint
>> has been reached.
>>
>> LAST_CONTROL_TRANSFER: from 80777d65 to 8205514d
>>
>> STACK_TEXT:
>> 833cba94 80777d65 80779060 833cbab4 00000002 nt!DbgPrompt+0x46
>> 833cbcc0 807782c5 00000029 92aa9280 92accd58
>> fltmgr!FltpvPrintErrors+0xeb
>> 833cbd44 82078db8 833c7af0 00000000 84c6c2d8
>> fltmgr!FltpvDoLostObjectCheck+0x14d
>> 833cbd7c 82225472 833c7af0 833c0680 00000000 nt!ExpWorkerThread+0xfd
>> 833cbdc0 8209141e 82078cbb 00000001 00000000
>> nt!PspSystemThreadStartup+0x9d
>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>
>>
>> FOLLOWUP_IP:
>> nt!DbgPrompt+46
>> 8205514d 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: 468308e9
>>
>> STACK_COMMAND: .cxr 0xffffffff833cb6ac ; kb
>>
>> FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>>
>> BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>>
>> Followup: MachineOwner
>> ---------
>>
>>
>>
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

OSR_Community_User · September 18, 2007, 1:21pm

Don:

I agree that it would seem reasonable IF WinDBG was attached. It isn’t (it’s just a vanilla install). Apparently Verifier makes it
think it is somehow.

As much as anything, I just wanted to let the rest of the community know…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 18, 2007 12:21 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Verifier problem in Vista?

Ken,

FltMgr only calls this if it thinks you have WinDBG attached and you
have the Verifier on. In that case I don’t think asking for a response is
that bad.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Ken Cross” wrote in message news:xxxxx@ntdev…
> Yeah, I figured that much out. But (1) it’s not a checked build, so (2)
> there’s no place to provide a response, plus (3) I’d kinda
> like to know what isn’t getting freed up, and (4) it just seems rude for
> fltmgr to bluescreen.
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Monday, September 17, 2007 12:07 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Verifier problem in Vista?
>
> Ken,
>
> DebugPrompt puts out a message then waits for a response. In this
> case it is indentifying a resource you forgot to free up in your filter.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “Ken Cross” wrote in message news:xxxxx@ntdev…
>> NTFSD Folk:
>>
>> I have my minifilter set for monitoring by Verifier on a standard
>> (non-checked) Vista system, fully patched. Occasionally, I get a
>> BSOD in fltmgr like below. I think it’s trying to output a message of
>> some sort, but failing rather badly.
>>
>> Anybody else seen anything like this? Suggestions?
>>
>> Thanks,
>> Ken
>>
>>
>>
>> Windows Vista Kernel Version 6000 UP Free x86 compatible
>> Product: WinNt, suite: TerminalServer SingleUserTS
>> Built by: 6000.16514.x86fre.vista_gdr.070627-1500
>> Kernel base = 0x82000000 PsLoadedModuleList = 0x82111db0
>> Debug session time: Mon Sep 17 11:37:15.930 2007 (GMT-4)
>> System Uptime: 5 days 17:22:29.213
>> Loading Kernel Symbols
>>
>
…
>> …
>> Loading User Symbols
>> Loading unloaded module list
>> …
>> kd> !analyze -v
>> *****
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>
>>
>> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
>> 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.
>> Some common problems are exception code 0x80000003. This means a hard
>> coded breakpoint or assertion was hit, but this system was booted
>> /NODEBUG. This is not supposed to happen as developers should never
>> have
>> hardcoded breakpoints in retail code, but …
>> If this happens, make sure a debugger gets connected, and the
>> system is booted /DEBUG. This will let us see why this breakpoint is
>> happening.
>> Arguments:
>> Arg1: 80000003, The exception code that was not handled
>> Arg2: 8205514d, The address that the exception occurred at
>> Arg3: 833cb9b0, Exception Record Address
>> Arg4: 833cb6ac, Context Record Address
>>
>> Debugging Details:
>> ------------------
>>
>>
>> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more
>> arguments
>> are invalid
>>
>> FAULTING_IP:
>> nt!DbgPrompt+46
>> 8205514d cc int 3
>>
>> EXCEPTION_RECORD: 833cb9b0 – (.exr ffffffff833cb9b0)
>> ExceptionAddress: 8205514d (nt!DbgPrompt+0x00000046)
>> ExceptionCode: 80000003 (Break instruction exception)
>> ExceptionFlags: 00000000
>> NumberParameters: 3
>> Parameter[0]: 00000002
>> Parameter[1]: 80779060
>> Parameter[2]: 0000001f
>>
>> CONTEXT: 833cb6ac – (.cxr ffffffff833cb6ac)
>> eax=00000002 ebx=833cbab4 ecx=80779060 edx=0000001f esi=80779061
>> edi=00000002
>> eip=8205514d esp=833cba78 ebp=833cba94 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:
>> 8205514d cc int 3
>> Resetting default scope
>>
>> CUSTOMER_CRASH_COUNT: 1
>>
>> DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
>>
>> BUGCHECK_STR: 0x7E
>>
>> PROCESS_NAME: System
>>
>> CURRENT_IRQL: 0
>>
>> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A
>> breakpoint
>> has been reached.
>>
>> LAST_CONTROL_TRANSFER: from 80777d65 to 8205514d
>>
>> STACK_TEXT:
>> 833cba94 80777d65 80779060 833cbab4 00000002 nt!DbgPrompt+0x46
>> 833cbcc0 807782c5 00000029 92aa9280 92accd58
>> fltmgr!FltpvPrintErrors+0xeb
>> 833cbd44 82078db8 833c7af0 00000000 84c6c2d8
>> fltmgr!FltpvDoLostObjectCheck+0x14d
>> 833cbd7c 82225472 833c7af0 833c0680 00000000 nt!ExpWorkerThread+0xfd
>> 833cbdc0 8209141e 82078cbb 00000001 00000000
>> nt!PspSystemThreadStartup+0x9d
>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>
>>
>> FOLLOWUP_IP:
>> nt!DbgPrompt+46
>> 8205514d 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: 468308e9
>>
>> STACK_COMMAND: .cxr 0xffffffff833cb6ac ; kb
>>
>> FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>>
>> BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>>
>> Followup: MachineOwner
>> ---------
>>
>>
>>
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Don_Burn_1 · September 18, 2007, 1:44pm

Ken,

Did you have something like DebugView running? This can confuse the
world enough to get this type of problem.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Ken Cross” wrote in message news:xxxxx@ntdev…
> Don:
>
> I agree that it would seem reasonable IF WinDBG was attached. It isn’t
> (it’s just a vanilla install). Apparently Verifier makes it
> think it is somehow.
>
> As much as anything, I just wanted to let the rest of the community
> know…
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Tuesday, September 18, 2007 12:21 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Verifier problem in Vista?
>
> Ken,
>
> FltMgr only calls this if it thinks you have WinDBG attached and you
> have the Verifier on. In that case I don’t think asking for a response
> is
> that bad.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “Ken Cross” wrote in message news:xxxxx@ntdev…
>> Yeah, I figured that much out. But (1) it’s not a checked build, so (2)
>> there’s no place to provide a response, plus (3) I’d kinda
>> like to know what isn’t getting freed up, and (4) it just seems rude for
>> fltmgr to bluescreen.
>>
>> Ken
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
>> Sent: Monday, September 17, 2007 12:07 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Verifier problem in Vista?
>>
>> Ken,
>>
>> DebugPrompt puts out a message then waits for a response. In this
>> case it is indentifying a resource you forgot to free up in your filter.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>> “Ken Cross” wrote in message news:xxxxx@ntdev…
>>> NTFSD Folk:
>>>
>>> I have my minifilter set for monitoring by Verifier on a standard
>>> (non-checked) Vista system, fully patched. Occasionally, I get a
>>> BSOD in fltmgr like below. I think it’s trying to output a message
>>> of
>>> some sort, but failing rather badly.
>>>
>>> Anybody else seen anything like this? Suggestions?
>>>
>>> Thanks,
>>> Ken
>>>
>>>
>>>
>>> Windows Vista Kernel Version 6000 UP Free x86 compatible
>>> Product: WinNt, suite: TerminalServer SingleUserTS
>>> Built by: 6000.16514.x86fre.vista_gdr.070627-1500
>>> Kernel base = 0x82000000 PsLoadedModuleList = 0x82111db0
>>> Debug session time: Mon Sep 17 11:37:15.930 2007 (GMT-4)
>>> System Uptime: 5 days 17:22:29.213
>>> Loading Kernel Symbols
>>>
>>
> …
>>> …
>>> Loading User Symbols
>>> Loading unloaded module list
>>> …
>>> kd> !analyze -v
>>> *****
>>>
>>>
>>> * Bugcheck Analysis
>>>
>>>
>>>
>>>
>>>
>>> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
>>> 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.
>>> Some common problems are exception code 0x80000003. This means a hard
>>> coded breakpoint or assertion was hit, but this system was booted
>>> /NODEBUG. This is not supposed to happen as developers should never
>>> have
>>> hardcoded breakpoints in retail code, but …
>>> If this happens, make sure a debugger gets connected, and the
>>> system is booted /DEBUG. This will let us see why this breakpoint is
>>> happening.
>>> Arguments:
>>> Arg1: 80000003, The exception code that was not handled
>>> Arg2: 8205514d, The address that the exception occurred at
>>> Arg3: 833cb9b0, Exception Record Address
>>> Arg4: 833cb6ac, Context Record Address
>>>
>>> Debugging Details:
>>> ------------------
>>>
>>>
>>> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more
>>> arguments
>>> are invalid
>>>
>>> FAULTING_IP:
>>> nt!DbgPrompt+46
>>> 8205514d cc int 3
>>>
>>> EXCEPTION_RECORD: 833cb9b0 – (.exr ffffffff833cb9b0)
>>> ExceptionAddress: 8205514d (nt!DbgPrompt+0x00000046)
>>> ExceptionCode: 80000003 (Break instruction exception)
>>> ExceptionFlags: 00000000
>>> NumberParameters: 3
>>> Parameter[0]: 00000002
>>> Parameter[1]: 80779060
>>> Parameter[2]: 0000001f
>>>
>>> CONTEXT: 833cb6ac – (.cxr ffffffff833cb6ac)
>>> eax=00000002 ebx=833cbab4 ecx=80779060 edx=0000001f esi=80779061
>>> edi=00000002
>>> eip=8205514d esp=833cba78 ebp=833cba94 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:
>>> 8205514d cc int 3
>>> Resetting default scope
>>>
>>> CUSTOMER_CRASH_COUNT: 1
>>>
>>> DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
>>>
>>> BUGCHECK_STR: 0x7E
>>>
>>> PROCESS_NAME: System
>>>
>>> CURRENT_IRQL: 0
>>>
>>> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A
>>> breakpoint
>>> has been reached.
>>>
>>> LAST_CONTROL_TRANSFER: from 80777d65 to 8205514d
>>>
>>> STACK_TEXT:
>>> 833cba94 80777d65 80779060 833cbab4 00000002 nt!DbgPrompt+0x46
>>> 833cbcc0 807782c5 00000029 92aa9280 92accd58
>>> fltmgr!FltpvPrintErrors+0xeb
>>> 833cbd44 82078db8 833c7af0 00000000 84c6c2d8
>>> fltmgr!FltpvDoLostObjectCheck+0x14d
>>> 833cbd7c 82225472 833c7af0 833c0680 00000000 nt!ExpWorkerThread+0xfd
>>> 833cbdc0 8209141e 82078cbb 00000001 00000000
>>> nt!PspSystemThreadStartup+0x9d
>>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>>
>>>
>>> FOLLOWUP_IP:
>>> nt!DbgPrompt+46
>>> 8205514d 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: 468308e9
>>>
>>> STACK_COMMAND: .cxr 0xffffffff833cb6ac ; kb
>>>
>>> FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>>>
>>> BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>>>
>>> Followup: MachineOwner
>>> ---------
>>>
>>>
>>>
>>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

OSR_Community_User · September 18, 2007, 3:10pm

Nope. This has happened several times, too.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, September 18, 2007 1:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Verifier problem in Vista?

Ken,

Did you have something like DebugView running? This can confuse the
world enough to get this type of problem.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Ken Cross” wrote in message news:xxxxx@ntdev…
> Don:
>
> I agree that it would seem reasonable IF WinDBG was attached. It isn’t
> (it’s just a vanilla install). Apparently Verifier makes it
> think it is somehow.
>
> As much as anything, I just wanted to let the rest of the community
> know…
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Tuesday, September 18, 2007 12:21 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Verifier problem in Vista?
>
> Ken,
>
> FltMgr only calls this if it thinks you have WinDBG attached and you
> have the Verifier on. In that case I don’t think asking for a response
> is
> that bad.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “Ken Cross” wrote in message news:xxxxx@ntdev…
>> Yeah, I figured that much out. But (1) it’s not a checked build, so (2)
>> there’s no place to provide a response, plus (3) I’d kinda
>> like to know what isn’t getting freed up, and (4) it just seems rude for
>> fltmgr to bluescreen.
>>
>> Ken
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
>> Sent: Monday, September 17, 2007 12:07 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Verifier problem in Vista?
>>
>> Ken,
>>
>> DebugPrompt puts out a message then waits for a response. In this
>> case it is indentifying a resource you forgot to free up in your filter.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>> “Ken Cross” wrote in message news:xxxxx@ntdev…
>>> NTFSD Folk:
>>>
>>> I have my minifilter set for monitoring by Verifier on a standard
>>> (non-checked) Vista system, fully patched. Occasionally, I get a
>>> BSOD in fltmgr like below. I think it’s trying to output a message
>>> of
>>> some sort, but failing rather badly.
>>>
>>> Anybody else seen anything like this? Suggestions?
>>>
>>> Thanks,
>>> Ken
>>>
>>>
>>>
>>> Windows Vista Kernel Version 6000 UP Free x86 compatible
>>> Product: WinNt, suite: TerminalServer SingleUserTS
>>> Built by: 6000.16514.x86fre.vista_gdr.070627-1500
>>> Kernel base = 0x82000000 PsLoadedModuleList = 0x82111db0
>>> Debug session time: Mon Sep 17 11:37:15.930 2007 (GMT-4)
>>> System Uptime: 5 days 17:22:29.213
>>> Loading Kernel Symbols
>>>
>>
>
…
>>> …
>>> Loading User Symbols
>>> Loading unloaded module list
>>> …
>>> kd> !analyze -v
>>> *****
>>>
>>>
>>> * Bugcheck Analysis
>>>
>>>
>>>
>>>
>>>
>>> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
>>> 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.
>>> Some common problems are exception code 0x80000003. This means a hard
>>> coded breakpoint or assertion was hit, but this system was booted
>>> /NODEBUG. This is not supposed to happen as developers should never
>>> have
>>> hardcoded breakpoints in retail code, but …
>>> If this happens, make sure a debugger gets connected, and the
>>> system is booted /DEBUG. This will let us see why this breakpoint is
>>> happening.
>>> Arguments:
>>> Arg1: 80000003, The exception code that was not handled
>>> Arg2: 8205514d, The address that the exception occurred at
>>> Arg3: 833cb9b0, Exception Record Address
>>> Arg4: 833cb6ac, Context Record Address
>>>
>>> Debugging Details:
>>> ------------------
>>>
>>>
>>> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more
>>> arguments
>>> are invalid
>>>
>>> FAULTING_IP:
>>> nt!DbgPrompt+46
>>> 8205514d cc int 3
>>>
>>> EXCEPTION_RECORD: 833cb9b0 – (.exr ffffffff833cb9b0)
>>> ExceptionAddress: 8205514d (nt!DbgPrompt+0x00000046)
>>> ExceptionCode: 80000003 (Break instruction exception)
>>> ExceptionFlags: 00000000
>>> NumberParameters: 3
>>> Parameter[0]: 00000002
>>> Parameter[1]: 80779060
>>> Parameter[2]: 0000001f
>>>
>>> CONTEXT: 833cb6ac – (.cxr ffffffff833cb6ac)
>>> eax=00000002 ebx=833cbab4 ecx=80779060 edx=0000001f esi=80779061
>>> edi=00000002
>>> eip=8205514d esp=833cba78 ebp=833cba94 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:
>>> 8205514d cc int 3
>>> Resetting default scope
>>>
>>> CUSTOMER_CRASH_COUNT: 1
>>>
>>> DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
>>>
>>> BUGCHECK_STR: 0x7E
>>>
>>> PROCESS_NAME: System
>>>
>>> CURRENT_IRQL: 0
>>>
>>> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A
>>> breakpoint
>>> has been reached.
>>>
>>> LAST_CONTROL_TRANSFER: from 80777d65 to 8205514d
>>>
>>> STACK_TEXT:
>>> 833cba94 80777d65 80779060 833cbab4 00000002 nt!DbgPrompt+0x46
>>> 833cbcc0 807782c5 00000029 92aa9280 92accd58
>>> fltmgr!FltpvPrintErrors+0xeb
>>> 833cbd44 82078db8 833c7af0 00000000 84c6c2d8
>>> fltmgr!FltpvDoLostObjectCheck+0x14d
>>> 833cbd7c 82225472 833c7af0 833c0680 00000000 nt!ExpWorkerThread+0xfd
>>> 833cbdc0 8209141e 82078cbb 00000001 00000000
>>> nt!PspSystemThreadStartup+0x9d
>>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>>
>>>
>>> FOLLOWUP_IP:
>>> nt!DbgPrompt+46
>>> 8205514d 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: 468308e9
>>>
>>> STACK_COMMAND: .cxr 0xffffffff833cb6ac ; kb
>>>
>>> FAILURE_BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>>>
>>> BUCKET_ID: 0x7E_VRF_nt!DbgPrompt+46
>>>
>>> Followup: MachineOwner
>>> ---------
>>>
>>>
>>>
>>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Don_Burn_1 · September 18, 2007, 3:14pm

“Ken Cross” wrote in message news:xxxxx@ntdev…
> Nope. This has happened several times, too.
>

Ken,

Figured I would ask. Sounds like a real one, perhaps it is time for
the NTFSD list to start a list of all the problems we have seen in FltMgr.
It could be a useful resource, and OSR could turn it into an NT Insider
article if it wanted.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply