FltGetRequestorProcessId exception

NTFSD
1

Some of you might remember I’m trying to get a filename after having missed
the IRP_MJ_CREATE.

In my PostOp callback, once I decide that the operation coming through is
one that I need a name for, I call:

FltDoCompletionProcessingWhenSafe(Data, FltObjects, CompletionContext,
Flags, LongTermNameLookupCallback, &ignored);

Basically calling my LongTermNameLookupCallback callback when I’m guaranteed
IRQL <= APC_LEVEL (and if the callback can’t be called for some reason,
that’s OK)

Inside the callback, I’m calling FltGetRequestorProcessId(Data) and getting
an exception. The stack shows:

nt!PsGetProcessId
fltmgr!FltGetRequestorProcessId+0x17
FSMFx64!LongTermNameLookupCallback+0x66
fltmgr!FltpSafeCompletionWorker+0xa9
nt!ExpWorkerThread+0x11a

The exception 0xc0000005 – nt!PsGetProcessId is trying to access memory it
can’t.

According to everything I’ve read, FltGetRequestorProcessId should be safe
(it requires IRQL <= DISPATCH_LEVEL). Is there some rule-exception when
calling from a worker thread?

Or do I need to somehow add a reference to the PFLT_CALLBACK_DATA variable
before calling FltDoCompletionProcessingWhenSafe? (I assumed it would take
care of this internally).

Note that I never call FltDoCompletionProcessingWhenSafe on:
* a non-IRP request
* if 0 != (IRP_PAGING_IO & Data->Iopb->IrpFlags) (ie on a paging request)
* if the FLTFL_POST_OPERATION_DRAINING bit is set

Kind of stumped… Thanks for any ideas

Doug

2

Hi Doug,

As far as I can tell you’re doing everything right. FltDoCompletionProcessingWhenSafe does not require you to reference the CALLBACK_DATA. PsGetProcessId is a very simple function. Could you please post the memory address it’s trying to reference ?

Also, is it always failing ?

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

3

Hi Alex –

The exception happens 100% of the time. I’m attaching the whole !analyze -v
output in case you’re interested in seeing anything else.

One other thing: When I comment out the call to get the process ID, I get a
crash with the following stack:
fltmgr!FltpCompleteCompletionNode+0x2d
fltmgr!FltCompletePendedPostOperation+0x82
fltmgr!FltpSafeCompletionWorker+0xba
nt!ExpWorkerThread+0x11a
t!PspSystemThreadStartup+0x57
nt!KiStartSystemThread+0x16

ERROR_CODE: (NTSTATUS) 0xc0000005
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80001c8d080
0000000000000010
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

So apparently a NULL pointer is involved, though I’m not sure where or how
– I don’t manipulate any incoming objects or pointers at all.

Doug

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: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80001a8d328, The address that the exception occurred at
Arg3: fffffa60019c79d8, Exception Record Address
Arg4: fffffa60019c73b0, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!PsGetProcessId+0
fffff800`01a8d328 488b81e0000000 mov rax,qword ptr [rcx+0E0h]

EXCEPTION_RECORD: fffffa60019c79d8 – (.exr 0xfffffa60019c79d8)
ExceptionAddress: fffff80001a8d328 (nt!PsGetProcessId)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

CONTEXT: fffffa60019c73b0 – (.cxr 0xfffffa60019c73b0)
rax=6500000438850f31 rbx=fffffa60085f0208 rcx=6500000438850f31
rdx=0000000000000000 rsi=fffffa60019c7cb0 rdi=fffffa800aeea010
rip=fffff80001a8d328 rsp=fffffa60019c7c18 rbp=fffffa800847f050
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffffa8006cc1768 r12=fffffa800b626350 r13=0000000000000001
r14=0000000000000000 r15=fffffa60005efcc0
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00010202
nt!PsGetProcessId:
fffff80001a8d328 488b81e0000000 mov rax,qword ptr [rcx+0E0h] ds:002b:6500000438851011=???
Resetting default scope

CUSTOMER_CRASH_COUNT: 4

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80001c79080
ffffffffffffffff

BUGCHECK_STR: 0x7E

LAST_CONTROL_TRANSFER: from fffffa6000a90127 to fffff80001a8d328

STACK_TEXT:
fffffa60019c7c18 fffffa6000a90127 : fffffa8006cfd720 fffff80001be28a0
fffffa8000000001 fffff80001aaf9ee : nt!PsGetProcessId
fffffa60019c7c20 fffffa60085ed086 : fffffa60085f0208 0000000000000000
fffffa60005ec7f0 fffff80001abe43a : fltmgr!FltGetRequestorProcessId+0x17
fffffa60019c7c50 fffffa6000ab7db9 : fffffa800b708b90 0000000000000000
fffffa60085ed028 0000000000000000 :
FSMFx64!LongTermNameLookupCallback+0x5e
[c:\dev36\proj\servermoncfg\fsmonitor\fsminifilter\filter\fsmf.c @ 623]
fffffa60019c7c90 fffff80001ab1366 : fffffa6000ab7d10 fffff80001be28a0
fffffa8006cfd720 fffffa800b6262a0 : fltmgr!FltpSafeCompletionWorker+0xa9
fffffa60019c7cf0 fffff80001cc8fd3 : fffffa800b626320 0000000000000000
fffffa8006cfd720 0000000000000080 : nt!ExpWorkerThread+0x11a
fffffa60019c7d50 fffff80001ade816 : fffffa60005ec180 fffffa8006cfd720
fffffa60005f5d40 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa60019c7d80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

FOLLOWUP_IP:
FileSightMFx64!LongTermNameLookupCallback+5e
[c:\dev36\proj\servermoncfg\fsmonitor\fsminifilter\filter\fsmf.c @ 623]
fffffa60`085ed086 ?? ???

*** NOTE: The faulting source below is off by just a couple of lines – this
code happens just before the call to FltGetRequestorProcessId
FAULTING_SOURCE_CODE:
619: {
620:
recordList->LogRecord.Operations[0].Data = fsi.EndOfFile;
621:
recordList->LogRecord.bDirectory = fsi.Directory ? 1 : 0;
622: }

623:
recordList->LogRecord.Operations[0].OpType = RECORD_OPTYPE_OPEN;
624:
break;
625: }
626: }
627: }
628:

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: FSMFx64!LongTermNameLookupCallback+5e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: FSMFx64

IMAGE_NAME: FSMFx64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 49f096bd

STACK_COMMAND: .cxr 0xfffffa60019c73b0 ; kb

FAILURE_BUCKET_ID: X64_0x7E_FSMFx64!LongTermNameLookupCallback+5e

BUCKET_ID: X64_0x7E_FSMFx64!LongTermNameLookupCallback+5e

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-363879-
xxxxx@lists.osr.com] On Behalf Of Alexandru Carp
Sent: Thursday, April 23, 2009 10:52 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetRequestorProcessId exception

Hi Doug,

As far as I can tell you’re doing everything right.
FltDoCompletionProcessingWhenSafe does not require you to reference the
CALLBACK_DATA. PsGetProcessId is a very simple function. Could you
please post the memory address it’s trying to reference ?

Also, is it always failing ?

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

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

4

This is strange. RCX was supposed to point to the EPROCESS, but its value is 6500000438850f31.

Could you do a !fltkd.cbd on the CALLBACK_DATA pls? and then a !irp on the IRP ?

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

5

I’m wondering if there actually are additional caveats that I’m not aware
of. For example, this page:
http://msdn.microsoft.com/en-us/library/aa488546.aspx

says
“Caution To avoid deadlocks, FltDoCompletionProcessingWhenSafe cannot be
called for I/O operations that can be directly completed by a driver in the
storage stack, such as the following:” <— that’s the end, documentation
has been truncated…

Doug

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-363891-
xxxxx@lists.osr.com] On Behalf Of Doug
Sent: Thursday, April 23, 2009 1:01 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetRequestorProcessId exception

Hi Alex –

The exception happens 100% of the time. I’m attaching the whole
!analyze -v
output in case you’re interested in seeing anything else.

One other thing: When I comment out the call to get the process ID, I
get a
crash with the following stack:
fltmgr!FltpCompleteCompletionNode+0x2d
fltmgr!FltCompletePendedPostOperation+0x82
fltmgr!FltpSafeCompletionWorker+0xba
nt!ExpWorkerThread+0x11a
t!PspSystemThreadStartup+0x57
nt!KiStartSystemThread+0x16

ERROR_CODE: (NTSTATUS) 0xc0000005
READ_ADDRESS: GetPointerFromAddress: unable to read from
fffff80001c8d080
0000000000000010
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

So apparently a NULL pointer is involved, though I’m not sure where or
how
– I don’t manipulate any incoming objects or pointers at all.

Doug

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: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80001a8d328, The address that the exception occurred at
Arg3: fffffa60019c79d8, Exception Record Address
Arg4: fffffa60019c73b0, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!PsGetProcessId+0
fffff800`01a8d328 488b81e0000000 mov rax,qword ptr [rcx+0E0h]

EXCEPTION_RECORD: fffffa60019c79d8 – (.exr 0xfffffa60019c79d8)
ExceptionAddress: fffff80001a8d328 (nt!PsGetProcessId)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

CONTEXT: fffffa60019c73b0 – (.cxr 0xfffffa60019c73b0)
rax=6500000438850f31 rbx=fffffa60085f0208 rcx=6500000438850f31
rdx=0000000000000000 rsi=fffffa60019c7cb0 rdi=fffffa800aeea010
rip=fffff80001a8d328 rsp=fffffa60019c7c18 rbp=fffffa800847f050
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffffa8006cc1768 r12=fffffa800b626350 r13=0000000000000001
r14=0000000000000000 r15=fffffa60005efcc0
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00010202
nt!PsGetProcessId:
fffff80001a8d328 488b81e0000000 mov rax,qword ptr [rcx+0E0h] ds:002b:6500000438851011=???
Resetting default scope

CUSTOMER_CRASH_COUNT: 4

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced
memory at 0x%08lx. The memory could not be %s.

READ_ADDRESS: GetPointerFromAddress: unable to read from
fffff80001c79080
ffffffffffffffff

BUGCHECK_STR: 0x7E

LAST_CONTROL_TRANSFER: from fffffa6000a90127 to fffff80001a8d328

STACK_TEXT:
fffffa60019c7c18 fffffa6000a90127 : fffffa8006cfd720 fffff80001be28a0
fffffa8000000001 fffff80001aaf9ee : nt!PsGetProcessId
fffffa60019c7c20 fffffa60085ed086 : fffffa60085f0208 0000000000000000
fffffa60005ec7f0 fffff80001abe43a :
fltmgr!FltGetRequestorProcessId+0x17
fffffa60019c7c50 fffffa6000ab7db9 : fffffa800b708b90 0000000000000000
fffffa60085ed028 0000000000000000 :
FSMFx64!LongTermNameLookupCallback+0x5e
[c:\dev36\proj\servermoncfg\fsmonitor\fsminifilter\filter\fsmf.c @ 623]
fffffa60019c7c90 fffff80001ab1366 : fffffa6000ab7d10 fffff80001be28a0
fffffa8006cfd720 fffffa800b6262a0 :
fltmgr!FltpSafeCompletionWorker+0xa9
fffffa60019c7cf0 fffff80001cc8fd3 : fffffa800b626320 0000000000000000
fffffa8006cfd720 0000000000000080 : nt!ExpWorkerThread+0x11a
fffffa60019c7d50 fffff80001ade816 : fffffa60005ec180 fffffa8006cfd720
fffffa60005f5d40 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa60019c7d80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

FOLLOWUP_IP:
FileSightMFx64!LongTermNameLookupCallback+5e
[c:\dev36\proj\servermoncfg\fsmonitor\fsminifilter\filter\fsmf.c @ 623]
fffffa60`085ed086 ?? ???

*** NOTE: The faulting source below is off by just a couple of lines –
this
code happens just before the call to FltGetRequestorProcessId
FAULTING_SOURCE_CODE:
619: {
620:
recordList->LogRecord.Operations[0].Data = fsi.EndOfFile;
621:
recordList->LogRecord.bDirectory = fsi.Directory ? 1 : 0;
622: }
> 623:
recordList->LogRecord.Operations[0].OpType = RECORD_OPTYPE_OPEN;
624:
break;
625: }
626: }
627: }
628:

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: FSMFx64!LongTermNameLookupCallback+5e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: FSMFx64

IMAGE_NAME: FSMFx64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 49f096bd

STACK_COMMAND: .cxr 0xfffffa60019c73b0 ; kb

FAILURE_BUCKET_ID: X64_0x7E_FSMFx64!LongTermNameLookupCallback+5e

BUCKET_ID: X64_0x7E_FSMFx64!LongTermNameLookupCallback+5e

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-363879-
> xxxxx@lists.osr.com] On Behalf Of Alexandru Carp
> Sent: Thursday, April 23, 2009 10:52 AM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetRequestorProcessId exception
>
> Hi Doug,
>
> As far as I can tell you’re doing everything right.
> FltDoCompletionProcessingWhenSafe does not require you to reference
the
> CALLBACK_DATA. PsGetProcessId is a very simple function. Could you
> please post the memory address it’s trying to reference ?
>
> Also, is it always failing ?
>
> Regards,
> Alex.
> This posting is provided “AS IS” with no warranties, and confers no
> rights.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

6

Well, look at this thread:

http://www.osronline.com/showthread.cfm?link=151865

FltGetRequestorProcessId does not issue any IO, it just walks a couple of structure pointers.

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

7

Ugggh, sorry guys, figured it out:

I wasn’t returning the result from FltDoCompletionProcessingWhenSafe as the
result from my PostOp call – THAT must be how you indicate to the Filter
Manager not to free the FLT_CALLBACK_DATA structure yet. Now it’s working
perfectly.

And what’s really embarrassing, is I found the answer in an old question of
mine that Eric Diven answered last year
(http://www.osronline.com/showThread.CFM?link=136678 )

Sorry for the wasted bandwidth :frowning:

Doug

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-363905-
xxxxx@lists.osr.com] On Behalf Of Alexandru Carp
Sent: Thursday, April 23, 2009 3:35 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetRequestorProcessId exception

Well, look at this thread:

http://www.osronline.com/showthread.cfm?link=151865

FltGetRequestorProcessId does not issue any IO, it just walks a couple
of structure pointers.

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

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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