FS driver get a IRQL_NOT_LESS_OR_EQUAL during IRP_MJ_CREATE

NTFSD
1

I got once a IRQL_NOT_LESS_OR_EQUAL bug check during FS driver testing.
The IRQL = 0x1C. From memory dump, it appears FS driver is calling
KeSetEvent at an IRQL of 0x1c, which is illegal.
How this could happen that a filter driver on file system stack got
IRP_MJ_CREATE at IRQL = 0x1C? It confused me. Is it possible that
Something else crashed cause FS driver got request at high IRQL?
We have several testing pcs running in lab. But only got once.
Any idea?

Any suggestion will be appreciated.

Thanks

The stack trace is below:
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e1d5a, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000016

CURRENT_IRQL: 1c

FAULTING_IP:
nt!KiWaitTest+30
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: b1aed7dc – (.trap ffffffffb1aed7dc)
ErrCode = 00000000
eax=00000000 ebx=86d69930 ecx=b1aed85c edx=00000000 esi=86d69928
edi=00000000
eip=804e1d5a esp=b1aed850 ebp=b1aed86c iopl=0 vif nv up ei pl nz na pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00090203
nt!KiWaitTest+0x30:
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1
ds:0023:00000016=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 804e2708 to 804e1d5a

STACK_TEXT:
b1aed86c 804e2708 863b0ab0 86e8c950 862c7668 nt!KiWaitTest+0x30
b1aed880 b22863e3 86d69928 00000000 00000000 filter!KeSetEvent+0x5a
b1aed9f4 b2201ffe 86cecd10 863b0aa0 861174e8 filter!OpenSecureFile+0x1d6
b1aeda48 b22013f0 86cecd10 863b0aa0 86cecdc8 filter!FsdDispatch+0x650
b1aeda6c 8057eeb8 86f958e8 8673649c b1aedc04 nt!IopfCallDriver+0x31
b1aedb4c 8056e063 86f95900 00000000 867363f8 nt!IopParseDevice+0xa58
b1aedbc4 805715e8 00000000 b1aedc04 00000040 nt!ObpLookupObjectName+0x53c
b1aedc18 8057f4c3 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
b1aedc94 8057f592 0bcfe8b0 80100080 0bcfe850 nt!IopCreateFile+0x407
b1aedcf0 8057f5d5 0bcfe8b0 80100080 0bcfe850 nt!IoCreateFile+0x8e
b1aedd30 804ddf0f 0bcfe8b0 80100080 0bcfe850 nt!NtCreateFile+0x30
b1aedd30 7c90eb94 0bcfe8b0 80100080 0bcfe850 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0bcfe80c 00000000 00000000 00000000 00000000 0x7c90eb94

FOLLOWUP_IP:
filter!OpenSecureFile+1d6
b22043c6 b901000000 mov ecx,0x1

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: filter!OpenSecureFile+1d6

MODULE_NAME: filter

IMAGE_NAME: filter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41c75ea7

STACK_COMMAND: .trap ffffffffb1aed7dc ; kb

BUCKET_ID: 0xA_filter!OpenSecureFile+1d6

2

I got once a IRQL_NOT_LESS_OR_EQUAL bug check during FS driver testing.
The IRQL = 0x1C. From memory dump, it appears FS driver is calling
KeSetEvent at an IRQL of 0x1c, which is illegal.
How this could happen that a filter driver on file system stack got
IRP_MJ_CREATE at IRQL = 0x1C? It confused me. Is it possible that
something else crashed cause FS driver got request at high IRQL?
We have several testing pcs running in lab. But only got once. Any idea?

Any suggestion will be appreciated.

Thanks

The stack trace is below:
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an interrupt request level (IRQL) that is too high. This is usually caused
by drivers using improper addresses. If a kernel debugger is available get
the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e1d5a, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000016

CURRENT_IRQL: 1c

FAULTING_IP:
nt!KiWaitTest+30
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: b1aed7dc – (.trap ffffffffb1aed7dc)
ErrCode = 00000000
eax=00000000 ebx=86d69930 ecx=b1aed85c edx=00000000 esi=86d69928
edi=00000000
eip=804e1d5a esp=b1aed850 ebp=b1aed86c iopl=0 vif nv up ei pl nz na pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00090203
nt!KiWaitTest+0x30:
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1
ds:0023:00000016=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 804e2708 to 804e1d5a

STACK_TEXT:
b1aed86c 804e2708 863b0ab0 86e8c950 862c7668 nt!KiWaitTest+0x30
b1aed880 b22863e3 86d69928 00000000 00000000 filter!KeSetEvent+0x5a
b1aed9f4 b2201ffe 86cecd10 863b0aa0 861174e8 filter!OpenSecureFile+0x1d6
b1aeda48 b22013f0 86cecd10 863b0aa0 86cecdc8 filter!FsdDispatch+0x650
b1aeda6c 8057eeb8 86f958e8 8673649c b1aedc04 nt!IopfCallDriver+0x31
b1aedb4c 8056e063 86f95900 00000000 867363f8 nt!IopParseDevice+0xa58
b1aedbc4 805715e8 00000000 b1aedc04 00000040 nt!ObpLookupObjectName+0x53c
b1aedc18 8057f4c3 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
b1aedc94 8057f592 0bcfe8b0 80100080 0bcfe850 nt!IopCreateFile+0x407
b1aedcf0 8057f5d5 0bcfe8b0 80100080 0bcfe850 nt!IoCreateFile+0x8e
b1aedd30 804ddf0f 0bcfe8b0 80100080 0bcfe850 nt!NtCreateFile+0x30
b1aedd30 7c90eb94 0bcfe8b0 80100080 0bcfe850 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0bcfe80c 00000000 00000000 00000000 00000000 0x7c90eb94

FOLLOWUP_IP:
filter!OpenSecureFile+1d6
b22043c6 b901000000 mov ecx,0x1

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: filter!OpenSecureFile+1d6

MODULE_NAME: filter

IMAGE_NAME: filter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41c75ea7

STACK_COMMAND: .trap ffffffffb1aed7dc ; kb

BUCKET_ID: 0xA_filter!OpenSecureFile+1d6

3

It is the otherone, arg1 is completely invlid !

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of David Wu
Sent: Thursday, January 06, 2005 8:07 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FS driver get a IRQL_NOT_LESS_OR_EQUAL during
IRP_MJ_CREATE

I got once a IRQL_NOT_LESS_OR_EQUAL bug check during FS driver testing.
The IRQL = 0x1C. From memory dump, it appears FS driver is calling
KeSetEvent at an IRQL of 0x1c, which is illegal.
How this could happen that a filter driver on file system stack got
IRP_MJ_CREATE at IRQL = 0x1C? It confused me. Is it possible that
something else crashed cause FS driver got request at high IRQL?
We have several testing pcs running in lab. But only got once. Any idea?

Any suggestion will be appreciated.

Thanks

The stack trace is below:
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an interrupt request level (IRQL) that is too high. This is usually caused
by drivers using improper addresses. If a kernel debugger is available get
the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e1d5a, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000016

CURRENT_IRQL: 1c

FAULTING_IP:
nt!KiWaitTest+30
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: b1aed7dc – (.trap ffffffffb1aed7dc)
ErrCode = 00000000
eax=00000000 ebx=86d69930 ecx=b1aed85c edx=00000000 esi=86d69928
edi=00000000
eip=804e1d5a esp=b1aed850 ebp=b1aed86c iopl=0 vif nv up ei pl nz na pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00090203
nt!KiWaitTest+0x30:
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1
ds:0023:00000016=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 804e2708 to 804e1d5a

STACK_TEXT:
b1aed86c 804e2708 863b0ab0 86e8c950 862c7668 nt!KiWaitTest+0x30
b1aed880 b22863e3 86d69928 00000000 00000000 filter!KeSetEvent+0x5a
b1aed9f4 b2201ffe 86cecd10 863b0aa0 861174e8 filter!OpenSecureFile+0x1d6
b1aeda48 b22013f0 86cecd10 863b0aa0 86cecdc8 filter!FsdDispatch+0x650
b1aeda6c 8057eeb8 86f958e8 8673649c b1aedc04 nt!IopfCallDriver+0x31
b1aedb4c 8056e063 86f95900 00000000 867363f8 nt!IopParseDevice+0xa58
b1aedbc4 805715e8 00000000 b1aedc04 00000040 nt!ObpLookupObjectName+0x53c
b1aedc18 8057f4c3 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
b1aedc94 8057f592 0bcfe8b0 80100080 0bcfe850 nt!IopCreateFile+0x407
b1aedcf0 8057f5d5 0bcfe8b0 80100080 0bcfe850 nt!IoCreateFile+0x8e
b1aedd30 804ddf0f 0bcfe8b0 80100080 0bcfe850 nt!NtCreateFile+0x30
b1aedd30 7c90eb94 0bcfe8b0 80100080 0bcfe850 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0bcfe80c 00000000 00000000 00000000 00000000 0x7c90eb94

FOLLOWUP_IP:
filter!OpenSecureFile+1d6
b22043c6 b901000000 mov ecx,0x1

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: filter!OpenSecureFile+1d6

MODULE_NAME: filter

IMAGE_NAME: filter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41c75ea7

STACK_COMMAND: .trap ffffffffb1aed7dc ; kb

BUCKET_ID: 0xA_filter!OpenSecureFile+1d6

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

More detail interpretation please. I know the memory referenced
Address arg1 is invlid. But I can not tell why.

Thanks

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Thursday, January 06, 2005 10:13 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FS driver get a IRQL_NOT_LESS_OR_EQUAL during
IRP_MJ_CREATE

It is the otherone, arg1 is completely invlid !

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of David Wu
Sent: Thursday, January 06, 2005 8:07 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FS driver get a IRQL_NOT_LESS_OR_EQUAL during IRP_MJ_CREATE

I got once a IRQL_NOT_LESS_OR_EQUAL bug check during FS driver testing. The
IRQL = 0x1C. From memory dump, it appears FS driver is calling KeSetEvent at
an IRQL of 0x1c, which is illegal. How this could happen that a filter
driver on file system stack got IRP_MJ_CREATE at IRQL = 0x1C? It confused
me. Is it possible that something else crashed cause FS driver got request
at high IRQL? We have several testing pcs running in lab. But only got once.
Any idea?

Any suggestion will be appreciated.

Thanks

The stack trace is below:
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an interrupt request level (IRQL) that is too high. This is usually caused
by drivers using improper addresses. If a kernel debugger is available get
the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e1d5a, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000016

CURRENT_IRQL: 1c

FAULTING_IP:
nt!KiWaitTest+30
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: b1aed7dc – (.trap ffffffffb1aed7dc)
ErrCode = 00000000
eax=00000000 ebx=86d69930 ecx=b1aed85c edx=00000000 esi=86d69928
edi=00000000
eip=804e1d5a esp=b1aed850 ebp=b1aed86c iopl=0 vif nv up ei pl nz na pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00090203
nt!KiWaitTest+0x30:
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1
ds:0023:00000016=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 804e2708 to 804e1d5a

STACK_TEXT:
b1aed86c 804e2708 863b0ab0 86e8c950 862c7668 nt!KiWaitTest+0x30 b1aed880
b22863e3 86d69928 00000000 00000000 filter!KeSetEvent+0x5a b1aed9f4 b2201ffe
86cecd10 863b0aa0 861174e8 filter!OpenSecureFile+0x1d6 b1aeda48 b22013f0
86cecd10 863b0aa0 86cecdc8 filter!FsdDispatch+0x650 b1aeda6c 8057eeb8
86f958e8 8673649c b1aedc04 nt!IopfCallDriver+0x31 b1aedb4c 8056e063 86f95900
00000000 867363f8 nt!IopParseDevice+0xa58 b1aedbc4 805715e8 00000000
b1aedc04 00000040 nt!ObpLookupObjectName+0x53c b1aedc18 8057f4c3 00000000
00000000 00000001 nt!ObOpenObjectByName+0xea b1aedc94 8057f592 0bcfe8b0
80100080 0bcfe850 nt!IopCreateFile+0x407 b1aedcf0 8057f5d5 0bcfe8b0 80100080
0bcfe850 nt!IoCreateFile+0x8e b1aedd30 804ddf0f 0bcfe8b0 80100080 0bcfe850
nt!NtCreateFile+0x30 b1aedd30 7c90eb94 0bcfe8b0 80100080 0bcfe850
nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0bcfe80c 00000000 00000000 00000000 00000000 0x7c90eb94

FOLLOWUP_IP:
filter!OpenSecureFile+1d6
b22043c6 b901000000 mov ecx,0x1

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: filter!OpenSecureFile+1d6

MODULE_NAME: filter

IMAGE_NAME: filter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41c75ea7

STACK_COMMAND: .trap ffffffffb1aed7dc ; kb

BUCKET_ID: 0xA_filter!OpenSecureFile+1d6

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@sbcglobal.net To
unsubscribe send a blank email to xxxxx@lists.osr.com

5

First the irql getting reported is after it was trying to access invalid
address. One of the system routines brings it up to be ready for a possible
crash dump if I could recall correctly. And of course you can find that out
using disassembly window.

My best bet is that probably the sync object is not properly initialized. Is
there by any chance the event object is set in the user mode ?, then
reference problem might be another thing to look at.

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of David Wu
Sent: Thursday, January 06, 2005 8:26 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FS driver get a IRQL_NOT_LESS_OR_EQUAL during
IRP_MJ_CREATE

More detail interpretation please. I know the memory referenced
Address arg1 is invlid. But I can not tell why.

Thanks

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Thursday, January 06, 2005 10:13 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FS driver get a IRQL_NOT_LESS_OR_EQUAL during
IRP_MJ_CREATE

It is the otherone, arg1 is completely invlid !

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of David Wu
Sent: Thursday, January 06, 2005 8:07 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FS driver get a IRQL_NOT_LESS_OR_EQUAL during IRP_MJ_CREATE

I got once a IRQL_NOT_LESS_OR_EQUAL bug check during FS driver testing. The
IRQL = 0x1C. From memory dump, it appears FS driver is calling KeSetEvent at
an IRQL of 0x1c, which is illegal. How this could happen that a filter
driver on file system stack got IRP_MJ_CREATE at IRQL = 0x1C? It confused
me. Is it possible that something else crashed cause FS driver got request
at high IRQL? We have several testing pcs running in lab. But only got once.
Any idea?

Any suggestion will be appreciated.

Thanks

The stack trace is below:
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an interrupt request level (IRQL) that is too high. This is usually caused
by drivers using improper addresses. If a kernel debugger is available get
the stack backtrace.
Arguments:
Arg1: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e1d5a, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000016

CURRENT_IRQL: 1c

FAULTING_IP:
nt!KiWaitTest+30
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: b1aed7dc – (.trap ffffffffb1aed7dc)
ErrCode = 00000000
eax=00000000 ebx=86d69930 ecx=b1aed85c edx=00000000 esi=86d69928
edi=00000000
eip=804e1d5a esp=b1aed850 ebp=b1aed86c iopl=0 vif nv up ei pl nz na pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00090203
nt!KiWaitTest+0x30:
804e1d5a 6683781601 cmp word ptr [eax+0x16],0x1
ds:0023:00000016=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 804e2708 to 804e1d5a

STACK_TEXT:
b1aed86c 804e2708 863b0ab0 86e8c950 862c7668 nt!KiWaitTest+0x30 b1aed880
b22863e3 86d69928 00000000 00000000 filter!KeSetEvent+0x5a b1aed9f4 b2201ffe
86cecd10 863b0aa0 861174e8 filter!OpenSecureFile+0x1d6 b1aeda48 b22013f0
86cecd10 863b0aa0 86cecdc8 filter!FsdDispatch+0x650 b1aeda6c 8057eeb8
86f958e8 8673649c b1aedc04 nt!IopfCallDriver+0x31 b1aedb4c 8056e063 86f95900
00000000 867363f8 nt!IopParseDevice+0xa58 b1aedbc4 805715e8 00000000
b1aedc04 00000040 nt!ObpLookupObjectName+0x53c b1aedc18 8057f4c3 00000000
00000000 00000001 nt!ObOpenObjectByName+0xea b1aedc94 8057f592 0bcfe8b0
80100080 0bcfe850 nt!IopCreateFile+0x407 b1aedcf0 8057f5d5 0bcfe8b0 80100080
0bcfe850 nt!IoCreateFile+0x8e b1aedd30 804ddf0f 0bcfe8b0 80100080 0bcfe850
nt!NtCreateFile+0x30 b1aedd30 7c90eb94 0bcfe8b0 80100080 0bcfe850
nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0bcfe80c 00000000 00000000 00000000 00000000 0x7c90eb94

FOLLOWUP_IP:
filter!OpenSecureFile+1d6
b22043c6 b901000000 mov ecx,0x1

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: filter!OpenSecureFile+1d6

MODULE_NAME: filter

IMAGE_NAME: filter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41c75ea7

STACK_COMMAND: .trap ffffffffb1aed7dc ; kb

BUCKET_ID: 0xA_filter!OpenSecureFile+1d6

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@sbcglobal.net To
unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com