我利用了filemon的取文件路径，有时会蓝屏，各位帮我看看dump的分析

直接用的filemon的获取路径的方法
nt!RtlUnicodeStringToAnsiString导致蓝屏，应该是buffer内存不可读了，不知道为什么
下面是memory.dmp的分析
FAULTING_MODULE: 804d8000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4bbf96b2

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

FAULTING_IP:
nt!RtlUnicodeToMultiByteSize+1e
805da35a 0fb70a          movzx   ecx,word ptr [edx]

EXCEPTION_RECORD:  ba4ef988 -- (.exr 0xffffffffba4ef988)
ExceptionAddress: 805da35a (nt!RtlUnicodeToMultiByteSize+0x0000001e)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00044042
Attempt to read from address 00044042

CONTEXT:  ba4ef684 -- (.cxr 0xffffffffba4ef684)
eax=00000080 ebx=00000000 ecx=00000100 edx=00044042 esi=00000000 edi=87b9b970
eip=805da35a esp=ba4efa50 ebp=ba4efa58 iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
nt!RtlUnicodeToMultiByteSize+0x1e:
805da35a 0fb70a          movzx   ecx,word ptr [edx]       ds:0023:00044042=????
Resetting default scope

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x7E

LAST_CONTROL_TRANSFER:  from 805e2ae2 to 805da35a

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
ba4efa58 805e2ae2 ba4efa74 00044042 00000100 nt!RtlUnicodeToMultiByteSize+0x1e
ba4efa6c 805e337c 87b9b970 8771e018 87626470 nt!RtlxUnicodeStringToOemSize+0x18
ba4efa84 a6121a31 ba4efb14 87b9b970 00000001 nt!RtlUnicodeStringToAnsiString+0x1e
ba4efb4c a6125f18 00000001 87626470 8748e568 testfilem!FilemonGetFullPath+0x4a1 [f:\sys\filemon_test.c @ 1517]
ba4efcf0 a612691e 8748e4b0 8771e008 ba4efd48 testfilem!FilemonHookRoutine+0x138 [f:\sys\filemon_test.c @ 4336]
ba4efd00 804f019f 8748e4b0 8771e008 8771e008 testfilem!FilemonDispatch+0x2e [f:\sys\filemon_test.c @ 4776]
ba4efd48 805bc474 00626470 00000000 87626470 nt!IoBuildPartialMdl+0xed
ba4efd64 805bc8c6 87626470 00000001 80563f20 nt!NtFreeVirtualMemory+0x84f8
ba4efdac 805d0f72 00000000 00000000 00000000 nt!ObReferenceObjectByHandle+0x426
ba4efddc 8054711e 8053969a 00000000 00000000 nt!PsRemoveCreateThreadNotifyRoutine+0x214
00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x72e


FOLLOWUP_IP:
testfilem!FilemonGetFullPath+4a1 [f:\sys\filemon_test.c @ 1517]
a6121a31 85c0            test    eax,eax

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  testfilem!FilemonGetFullPath+4a1

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: testfilem

IMAGE_NAME:  testfilem.sys

STACK_COMMAND:  .cxr 0xffffffffba4ef684 ; kb

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner

        pathLen = fileName.Length + prefixLen;
        relatedFileObject = fileObject->RelatedFileObject;
    
        if( fileObject->FileName.Buffer[0] != L'\\' &&
            relatedFileObject && relatedFileObject->FileName.Length ) {
            
1517行            if( !NT_SUCCESS( RtlUnicodeStringToAnsiString( &relatedName, &relatedFileObject->FileName, TRUE ))) {

                if( hookExt->Type == NPFS )      sprintf( fullPathName, "%s: <Out of Memory>", NAMED_PIPE_PREFIX );
                else if( hookExt->Type == MSFS ) sprintf( fullPathName, "%s: <Out of Memory>", MAIL_SLOT_PREFIX );
                else                             sprintf( fullPathName, "%C: <Out of Memory>", hookExt->LogicalDrive );
                RtlFreeAnsiString( &fileName );
                return;
            }
            pathLen += relatedName.Length+1;
        }

有人吗

直接用sfilter提供的namelookup

不要用filemon了，太老了

major type 是多少？

The RelatedFileObject member is only valid during the processing of the IRP_MJ_CREATE requests.