Checking for STATUS_DEVICE_NOT_READY on a DFS share?

NTFSD
1

I have a client who has set up an DFS share and when he does a folder rename on this share, my mini-filter crashes. I can?t reproduce this here in the office and code looks right, at least to me. All the dumps point to the same location a FltGetDestinationFileNameInformation call.

According to the dump:
BugCheck 27, {baad00a3, b3ce7f44, b3ce7c40, b6a23a5f}

I?m getting a RDBSS_BUG_CHECK_NTEXECPT with a A3, which looks like STATUS_DEVICE_NOT_READY.

Talking with the customer, the DFS share is actually on another domain than the login domain and while that maybe causing some problems here, I?m more interested in how in the world to I catch this state before I attempt to get the rename information.

Am I even analyzing this dump correctly?

Thank you,

Gene

Here is the dump.
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

RDR_FILE_SYSTEM (27)
If you see RxExceptionFilter on the stack then the 2nd and 3rd parameters are the
exception record and context record. Do a .cxr on the 3rd parameter and then kb to
obtain a more informative stack trace.
The high 16 bits of the first parameter is the RDBSS bugcheck code, which is defined
as follows:
RDBSS_BUG_CHECK_CACHESUP = 0xca550000,
RDBSS_BUG_CHECK_CLEANUP = 0xc1ee0000,
RDBSS_BUG_CHECK_CLOSE = 0xc10e0000,
RDBSS_BUG_CHECK_NTEXCEPT = 0xbaad0000,
Arguments:
Arg1: baad00a3
Arg2: b3ce7f44
Arg3: b3ce7c40
Arg4: b6a23a5f

Debugging Details:

EXCEPTION_RECORD: b3ce7f44 – (.exr 0xffffffffb3ce7f44)
ExceptionAddress: b6a23a5f (rdbss!RxIsThisACscAgentOpen+0x00000038)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000008
Attempt to read from address 00000008

CONTEXT: b3ce7c40 – (.cxr 0xffffffffb3ce7c40)
eax=00000000 ebx=b6a23a80 ecx=00000009 edx=00000000 esi=00000008 edi=b6a23a80
eip=b6a23a5f esp=b3ce800c ebp=b3ce801c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
rdbss!RxIsThisACscAgentOpen+0x38:
b6a23a5f f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]
Resetting default scope

CUSTOMER_CRASH_COUNT: 2

PROCESS_NAME: NotesBU.exe

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

READ_ADDRESS: 00000008

BUGCHECK_STR: 0x27

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from b6a2b431 to b6a23a5f

STACK_TEXT:
b3ce801c b6a2b431 8a04d888 8a7f6d80 b3ce80c0 rdbss!RxIsThisACscAgentOpen+0x38
b3ce803c b6a2bbf7 00000000 b3ce806c b3ce807c rdbss!RxInitializeVNetRootParameters+0x282
b3ce809c b6a2e6cd 8a7f6c60 b3ce80c0 00000004 rdbss!RxFindOrConstructVirtualNetRoot+0xdc
b3ce80d0 b6a2ae15 8a04d888 8a681bf0 b3ce8120 rdbss!RxCanonicalizeNameAndObtainNetRoot+0x197
b3ce8134 b6a20d51 8a04d888 8a681bc0 b6a298a8 rdbss!RxCommonCreate+0x2c3
b3ce81cc b6a2acc2 b6a298a8 8a384000 8a38409c rdbss!RxFsdCommonDispatch+0x353
b3ce81f4 b69ac317 8a532b10 8a384000 8a384008 rdbss!RxFsdDispatch+0xda
b3ce8214 804e13d9 00000000 01384008 b3ce8330 mrxsmb!MRxSmbFsdDispatch+0x134
b3ce8224 f786ab2a b3ce8330 89eaa930 89eaa98c nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be wrong.
b3ce8264 f784e6ea b3ce8330 8a3840c0 8a68f6c8 mfehidk+0x25b2a
b3ce8288 f784ee91 00000002 8a3840c0 8a681bc0 mfehidk+0x96ea
b3ce8320 f7869d87 cccccccc 8a8cfa48 8a4ed3a0 mfehidk+0x9e91
b3ce8348 804e13d9 8a4ed3a0 8a384008 8a384008 mfehidk+0x24d87
b3ce8358 f747de9b 00000000 8a384008 8a3840e4 nt!IopfCallDriver+0x31
b3ce837c f748a754 b3ce839c 8a6d6ee8 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b3ce83b8 804e13d9 8a6d6ee8 8a384008 8a681bc0 fltmgr!FltpCreate+0x26a
b3ce83c8 f7419540 89eadc8c 89eadc88 00000000 nt!IopfCallDriver+0x31
b3ce83fc f741a8fa 89eadc88 f740e088 89eadc88 Mup!DnrRedirectFileOpen+0x443
b3ce845c f741b81a 01eadc88 0078005e 8a384108 Mup!DnrNameResolve+0x53c
b3ce848c f7415d3d 8a40d180 8a384008 8a8cfd40 Mup!DnrStartNameResolution+0x292
b3ce84fc f7413fd6 8a40d180 8a8cfc88 8a384008 Mup!DfsCommonCreate+0x237
b3ce8544 f7414076 8a8cfc88 8a384008 8a384018 Mup!DfsFsdCreate+0xe0
b3ce859c 804e13d9 8a8cfc88 8a384008 8a384008 Mup!MupCreate+0xbc
b3ce85ac 8057bbed 8a8cfc70 8a05dae4 b3ce8744 nt!IopfCallDriver+0x31
b3ce868c 8056d03b 8a8cfc88 00000000 8a05da40 nt!IopParseDevice+0xa12
b3ce8704 80570358 00000000 b3ce8744 00000240 nt!ObpLookupObjectName+0x53c
b3ce8758 8057c246 00000000 00000000 38400800 nt!ObOpenObjectByName+0xea
b3ce87d4 80584cc8 8a5b4620 00100000 b3ce886c nt!IopCreateFile+0x407
b3ce881c f7490c77 8a5b4620 00100000 b3ce886c nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b3ce88c4 f7490fe5 00000000 00000000 b3ce895c fltmgr!FltpExpandFilePathWorker+0x117
b3ce88dc f74914c1 8a5b45d8 00000000 8a5b45d8 fltmgr!FltpExpandFilePath+0x19
b3ce8910 f7491509 8a5b45d8 8a5b45d8 b3ce8a60 fltmgr!FltpGetOpenedDestinationFileName+0x2b9
b3ce8920 f7491695 8a5b45d8 8a677064 b3ce8b7c fltmgr!FltpGetNormalizedDestinationFileName+0x13
b3ce8a60 b513e8ac 8a35f3c8 89ead650 00000000 fltmgr!FltGetDestinationFileNameInformation+0x12b
b3ce8b3c b513fa2e 8a677064 b3ce8b7c 8a35f584 SoxAudit!AddEntryForPreNonCreatesPaths+0xdc [c:\development\main\filemaster\bssaudit\filter\bssaudit.c @ 1706]
b3ce8b5c f747b888 8a677064 b3ce8b7c b3ce8bac SoxAudit!PreSetInformation+0x62 [c:\development\main\filemaster\bssaudit\filter\bssaudit.c @ 3076]
b3ce8bbc f747d2a0 00ce8c04 00000000 b3ce8c04 fltmgr!FltpPerformPreCallbacks+0x2d4
b3ce8bd0 f747dc48 b3ce8c04 00000000 8a6d6ee8 fltmgr!FltpPassThroughInternal+0x32
b3ce8bec f747e059 b3ce8c00 00000000 8a900280 fltmgr!FltpPassThrough+0x1c2
b3ce8c1c 804e13d9 8a6d6ee8 89f8c888 89f8c9ac fltmgr!FltpDispatch+0x10d
b3ce8c2c f741c30e 89ead650 8a8cf030 89f8c888 nt!IopfCallDriver+0x31
b3ce8c70 f741c409 8a8a3728 89f8c888 89ead650 Mup!DfsCommonSetInformation+0xa3
b3ce8cb0 804e13d9 8a8cfc88 89f8c888 00000000 Mup!DfsFsdSetInformation+0x63
b3ce8cc0 805db2c4 b3ce8d64 0012d160 8057f4e5 nt!IopfCallDriver+0x31
b3ce8d48 804dd99f 00000128 0012d1d4 001c5d50 nt!NtSetInformationFile+0x533
b3ce8d48 7c90e514 00000128 0012d1d4 001c5d50 nt!KiFastCallEntry+0xfc
0012d218 00000000 00000000 00000000 00000000 0x7c90e514

FOLLOWUP_IP:
rdbss!RxIsThisACscAgentOpen+38
b6a23a5f f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: rdbss!RxIsThisACscAgentOpen+38

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: rdbss

IMAGE_NAME: rdbss.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48025ee6

STACK_COMMAND: .cxr 0xffffffffb3ce7c40 ; kb

FAILURE_BUCKET_ID: 0x27_rdbss!RxIsThisACscAgentOpen+38

BUCKET_ID: 0x27_rdbss!RxIsThisACscAgentOpen+38

Followup: MachineOwner

2

If you can, I’d start by getting the customer to turn off McAfee. There is
no reason in what you provide to assume that McAfee has anything to do with
this, but its one less variable to debug against. DFS is painful enough
without having the ogre of interop hanging over your shoulder…

I’d also look at the names that FltMgr is using when it issues the create to
MUP, and then what MUP has passed down (via fltmgr) to RDR…

Rod.

wrote in message news:xxxxx@ntfsd…
>I have a client who has set up an DFS share and when he does a folder
>rename on this share, my mini-filter crashes. I can?t reproduce this here
>in the office and code looks right, at least to me. All the dumps point to
>the same location a FltGetDestinationFileNameInformation call.
>
> According to the dump:
> BugCheck 27, {baad00a3, b3ce7f44, b3ce7c40, b6a23a5f}
>
> I?m getting a RDBSS_BUG_CHECK_NTEXECPT with a A3, which looks like
> STATUS_DEVICE_NOT_READY.
>
> Talking with the customer, the DFS share is actually on another domain
> than the login domain and while that maybe causing some problems here, I?m
> more interested in how in the world to I catch this state before I attempt
> to get the rename information.
>
> Am I even analyzing this dump correctly?
>
> Thank you,
>
> Gene
>
> Here is the dump.
> 1: kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> RDR_FILE_SYSTEM (27)
> If you see RxExceptionFilter on the stack then the 2nd and 3rd
> parameters are the
> exception record and context record. Do a .cxr on the 3rd parameter and
> then kb to
> obtain a more informative stack trace.
> The high 16 bits of the first parameter is the RDBSS bugcheck code,
> which is defined
> as follows:
> RDBSS_BUG_CHECK_CACHESUP = 0xca550000,
> RDBSS_BUG_CHECK_CLEANUP = 0xc1ee0000,
> RDBSS_BUG_CHECK_CLOSE = 0xc10e0000,
> RDBSS_BUG_CHECK_NTEXCEPT = 0xbaad0000,
> Arguments:
> Arg1: baad00a3
> Arg2: b3ce7f44
> Arg3: b3ce7c40
> Arg4: b6a23a5f
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_RECORD: b3ce7f44 – (.exr 0xffffffffb3ce7f44)
> ExceptionAddress: b6a23a5f (rdbss!RxIsThisACscAgentOpen+0x00000038)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000000
> Parameter[1]: 00000008
> Attempt to read from address 00000008
>
> CONTEXT: b3ce7c40 – (.cxr 0xffffffffb3ce7c40)
> eax=00000000 ebx=b6a23a80 ecx=00000009 edx=00000000 esi=00000008
> edi=b6a23a80
> eip=b6a23a5f esp=b3ce800c ebp=b3ce801c iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> rdbss!RxIsThisACscAgentOpen+0x38:
> b6a23a5f f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]
> Resetting default scope
>
> CUSTOMER_CRASH_COUNT: 2
>
> PROCESS_NAME: NotesBU.exe
>
> ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
> memory at 0x%08lx. The memory could not be %s.
>
> READ_ADDRESS: 00000008
>
> BUGCHECK_STR: 0x27
>
> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>
> LAST_CONTROL_TRANSFER: from b6a2b431 to b6a23a5f
>
> STACK_TEXT:
> b3ce801c b6a2b431 8a04d888 8a7f6d80 b3ce80c0
> rdbss!RxIsThisACscAgentOpen+0x38
> b3ce803c b6a2bbf7 00000000 b3ce806c b3ce807c
> rdbss!RxInitializeVNetRootParameters+0x282
> b3ce809c b6a2e6cd 8a7f6c60 b3ce80c0 00000004
> rdbss!RxFindOrConstructVirtualNetRoot+0xdc
> b3ce80d0 b6a2ae15 8a04d888 8a681bf0 b3ce8120
> rdbss!RxCanonicalizeNameAndObtainNetRoot+0x197
> b3ce8134 b6a20d51 8a04d888 8a681bc0 b6a298a8 rdbss!RxCommonCreate+0x2c3
> b3ce81cc b6a2acc2 b6a298a8 8a384000 8a38409c
> rdbss!RxFsdCommonDispatch+0x353
> b3ce81f4 b69ac317 8a532b10 8a384000 8a384008 rdbss!RxFsdDispatch+0xda
> b3ce8214 804e13d9 00000000 01384008 b3ce8330
> mrxsmb!MRxSmbFsdDispatch+0x134
> b3ce8224 f786ab2a b3ce8330 89eaa930 89eaa98c nt!IopfCallDriver+0x31
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> b3ce8264 f784e6ea b3ce8330 8a3840c0 8a68f6c8 mfehidk+0x25b2a
> b3ce8288 f784ee91 00000002 8a3840c0 8a681bc0 mfehidk+0x96ea
> b3ce8320 f7869d87 cccccccc 8a8cfa48 8a4ed3a0 mfehidk+0x9e91
> b3ce8348 804e13d9 8a4ed3a0 8a384008 8a384008 mfehidk+0x24d87
> b3ce8358 f747de9b 00000000 8a384008 8a3840e4 nt!IopfCallDriver+0x31
> b3ce837c f748a754 b3ce839c 8a6d6ee8 00000000
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
> b3ce83b8 804e13d9 8a6d6ee8 8a384008 8a681bc0 fltmgr!FltpCreate+0x26a
> b3ce83c8 f7419540 89eadc8c 89eadc88 00000000 nt!IopfCallDriver+0x31
> b3ce83fc f741a8fa 89eadc88 f740e088 89eadc88 Mup!DnrRedirectFileOpen+0x443
> b3ce845c f741b81a 01eadc88 0078005e 8a384108 Mup!DnrNameResolve+0x53c
> b3ce848c f7415d3d 8a40d180 8a384008 8a8cfd40
> Mup!DnrStartNameResolution+0x292
> b3ce84fc f7413fd6 8a40d180 8a8cfc88 8a384008 Mup!DfsCommonCreate+0x237
> b3ce8544 f7414076 8a8cfc88 8a384008 8a384018 Mup!DfsFsdCreate+0xe0
> b3ce859c 804e13d9 8a8cfc88 8a384008 8a384008 Mup!MupCreate+0xbc
> b3ce85ac 8057bbed 8a8cfc70 8a05dae4 b3ce8744 nt!IopfCallDriver+0x31
> b3ce868c 8056d03b 8a8cfc88 00000000 8a05da40 nt!IopParseDevice+0xa12
> b3ce8704 80570358 00000000 b3ce8744 00000240 nt!ObpLookupObjectName+0x53c
> b3ce8758 8057c246 00000000 00000000 38400800 nt!ObOpenObjectByName+0xea
> b3ce87d4 80584cc8 8a5b4620 00100000 b3ce886c nt!IopCreateFile+0x407
> b3ce881c f7490c77 8a5b4620 00100000 b3ce886c
> nt!IoCreateFileSpecifyDeviceObjectHint+0x52
> b3ce88c4 f7490fe5 00000000 00000000 b3ce895c
> fltmgr!FltpExpandFilePathWorker+0x117
> b3ce88dc f74914c1 8a5b45d8 00000000 8a5b45d8
> fltmgr!FltpExpandFilePath+0x19
> b3ce8910 f7491509 8a5b45d8 8a5b45d8 b3ce8a60
> fltmgr!FltpGetOpenedDestinationFileName+0x2b9
> b3ce8920 f7491695 8a5b45d8 8a677064 b3ce8b7c
> fltmgr!FltpGetNormalizedDestinationFileName+0x13
> b3ce8a60 b513e8ac 8a35f3c8 89ead650 00000000
> fltmgr!FltGetDestinationFileNameInformation+0x12b
> b3ce8b3c b513fa2e 8a677064 b3ce8b7c 8a35f584
> SoxAudit!AddEntryForPreNonCreatesPaths+0xdc
> [c:\development\main\filemaster\bssaudit\filter\bssaudit.c @ 1706]
> b3ce8b5c f747b888 8a677064 b3ce8b7c b3ce8bac
> SoxAudit!PreSetInformation+0x62
> [c:\development\main\filemaster\bssaudit\filter\bssaudit.c @ 3076]
> b3ce8bbc f747d2a0 00ce8c04 00000000 b3ce8c04
> fltmgr!FltpPerformPreCallbacks+0x2d4
> b3ce8bd0 f747dc48 b3ce8c04 00000000 8a6d6ee8
> fltmgr!FltpPassThroughInternal+0x32
> b3ce8bec f747e059 b3ce8c00 00000000 8a900280 fltmgr!FltpPassThrough+0x1c2
> b3ce8c1c 804e13d9 8a6d6ee8 89f8c888 89f8c9ac fltmgr!FltpDispatch+0x10d
> b3ce8c2c f741c30e 89ead650 8a8cf030 89f8c888 nt!IopfCallDriver+0x31
> b3ce8c70 f741c409 8a8a3728 89f8c888 89ead650
> Mup!DfsCommonSetInformation+0xa3
> b3ce8cb0 804e13d9 8a8cfc88 89f8c888 00000000 Mup!DfsFsdSetInformation+0x63
> b3ce8cc0 805db2c4 b3ce8d64 0012d160 8057f4e5 nt!IopfCallDriver+0x31
> b3ce8d48 804dd99f 00000128 0012d1d4 001c5d50 nt!NtSetInformationFile+0x533
> b3ce8d48 7c90e514 00000128 0012d1d4 001c5d50 nt!KiFastCallEntry+0xfc
> 0012d218 00000000 00000000 00000000 00000000 0x7c90e514
>
>
> FOLLOWUP_IP:
> rdbss!RxIsThisACscAgentOpen+38
> b6a23a5f f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: rdbss!RxIsThisACscAgentOpen+38
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: rdbss
>
> IMAGE_NAME: rdbss.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 48025ee6
>
> STACK_COMMAND: .cxr 0xffffffffb3ce7c40 ; kb
>
> FAILURE_BUCKET_ID: 0x27_rdbss!RxIsThisACscAgentOpen+38
>
> BUCKET_ID: 0x27_rdbss!RxIsThisACscAgentOpen+38
>
> Followup: MachineOwner
> ---------
>
>

3

Thank you Rod.

I would like to explore every option I can think of before I ask the customer to crash his machine again.

Looking at the code, maybe there is was a simple oversight, but since I can’t reproduce the problem…most it’s a shot in the dark.

Let me run this by you.

This is the call that is causing the exception (I removed the error checking code to make it easier to read)

PFLT_FILE_NAME_INFORMATION renameInfo;
PFILE_OBJECT pFileInfo;

pFileInfo = FltObjects->FileObject;
status = FltGetDestinationFileNameInformation(FltObjects->Instance,
pFileInfo,
pRenameInfo->RootDirectory,
pRenameInfo->FileName,
pRenameInfo->FileNameLength,
FLT_FILE_NAME_NORMALIZED,
&renameInfo);

Notice that there wasn’t a ‘FLT_FILE_NAME_QUERY_DEFAULT’

I’m sure that when I wrote it, I thought ‘oh that’s the default’ and didn’t explicitly add it and then when it passed QA and even shipped, I didn’t even THINK twice to revisit it.

I’ve already changed to code to include the ‘query method’

status = FltGetDestinationFileNameInformation(FltObjects->Instance,
pFileInfo,
pRenameInfo->RootDirectory,
pRenameInfo->FileName,
pRenameInfo->FileNameLength,
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT,
&renameInfo);

Do you think the lack of this ‘Query Method’ flag, could be causing a BSOD? The only reason that I think that the flag would make a difference is that, according to the doc, it says:

“If it is not currently safe to query the file system for the file name, FltGetDestinationFileNameInformation does nothing.”

My thinking is that if DFS is getting upset, it might be because it’s not in a ‘safe’ state and adding flag will cause the FltGetDestinationFileNameInformation to detect that DFS isn?t in a ?safe? state and will fail without a BSOD.

4

Gene,

I would like to explore every option I can think of before I ask the
customer to crash his machine again.

I can related to that…

Do you think the lack of this ‘Query Method’ flag, could be causing a
BSOD?

I don’t believe so. That flag is about “doing the right thing” when there
is some locking activity around you (for instance in the paging path) ,
equally the result of abusing it is usually a hang, not a BSOD. You pass on
both these situations…

I’m inclined to think that you might be an innocent party here (except for
the fact that the “last driver installed is always guilty”). But that is
the kind of thinking which ends up with one not trusting the compiler…

What is of interest to me is that for some reason we can gone through MUP
twice. Given that MUP is where names collect the double prefix and that
this whole operation is about name manipulation, my spider-sense is
tingling.

It may be a complete waste of time but if it were I, I would be looking at
the names of the files and in the file object down the stack:

SoxAudit!AddEntryForPreNonCreatesPaths+0xdc

What is the current name of the file object? Is it a directory or a file?
What is the contents of the rename structure? Is there a related file ? Is
there a apth in the target name?

nt!IoCreateFileSpecifyDeviceObjectHint+0x52

What is the file name that FltMgr is opening? Related or absolute? Does it
have a double prefix? Does the device specified match the target open (or is
IoCFSDH being smart?) What is FsContext/FsContext2.

fltmgr!FltpCreate+0x26a
So now, what is the file name that MUP is opening? Does it have a double
prefix? Whas it the FsContext/FsContext2 here?

mfehidk+0x24d87
Has Fltmgr just passed the create down, or is there other funky stuff
happening?

mrxsmb!MRxSmbFsdDispatch
Ditto mfehidk.

I would do this in the expectation of not finding anything interesting, but
it might help you with reproducing it. Further one of those nice Microsoft
Engineers that hang out here may have an idea…

Rod

5

The customer agreed to reproduce the defect and give me a kernel dump, so I gave him a driver that had the FLT_FILE_NAME_QUERY_DEFAULT added, just because I wanted to make sure that the symbols and everything matched up.

and…no more crash.

This customer had tried 3 previous builds of the driver, each one with minor changes on what I thought MIGHT be the problem and they all crashed at the same spot. They only code difference between the ones that crashed and the one that didn’t was this flag.

I’m not so sure that it is really fixed, so I’m going to leave the defect open for a week or so before closing it.

But I wanted to let you know and would like to say thank you for all your help.

Gene

6

Just like we expected, the crashed showed back up. I’m starting to think your right and McAfee is really causing the problem. I still have to deal with it though. Right now, I think my only option is to completely ignore operations on DFS, which is sad since we have no other problems on DFS other than this one customer.

I would rather not have to do that and any guidance would be very much appreciated.

Here is what I’ve figured out so far:

The customer is renaming the folder “H:\My Documents\Core IT\May 4th - DL” to “H:\My Documents\Core IT\May 4th - DL Test”
H is a DFS folder on a domain other then the login domain

The source filename
1: kd> ?? nameInfo
struct _FLT_FILE_NAME_INFORMATION * 0xe3ae8034
+0x000 Size : 0x40
+0x002 NamesParsed : 0xf
+0x004 Format : 1
+0x008 Name : _UNICODE_STRING “\Device\LanmanRedirector\marmite.northamerica.intra.abbott.com\users11$\DEVENBJ\My Documents\Core IT\May 4th - DL”
+0x010 Volume : _UNICODE_STRING “\Device\LanmanRedirector”
+0x018 Share : _UNICODE_STRING “\marmite.northamerica.intra.abbott.com\users11$”
+0x020 Extension : _UNICODE_STRING “”
+0x028 Stream : _UNICODE_STRING “”
+0x030 FinalComponent : _UNICODE_STRING “May 4th - DL”
+0x038 ParentDir : _UNICODE_STRING "\DEVENBJ\My Documents\Core IT"

the rename target
1: kd> ??(PFILE_RENAME_INFORMATION) Data->Iopb->Parameters.SetFileInformation.InfoBuffer
PFILE_RENAME_INFORMATION 0x89f3e9c0
+0x000 ReplaceIfExists : 0 ‘’
+0x004 RootDirectory : (null)
+0x008 FileNameLength : 0x5a
+0x00c FileName : [1] ""

89f3e9cc 5c 00 3f 00 3f 00 5c 00 48 00 3a 00 5c 00 4d 00 79 00 .?.?..H.:..M.y.
89f3e9de 20 00 44 00 6f 00 63 00 75 00 6d 00 65 00 6e 00 74 00 .D.o.c.u.m.e.n.t.
89f3e9f0 73 00 5c 00 43 00 6f 00 72 00 65 00 20 00 49 00 54 00 s..C.o.r.e. .I.T.
89f3ea02 5c 00 4d 00 61 00 79 00 20 00 34 00 74 00 68 00 20 00 .M.a.y. .4.t.h. .
89f3ea14 2d 00 20 00 44 00 4c 00 20 00 54 00 65 00 73 00 74 00 -. .D.L. .T.e.s.t.

or ??\H:\My Documents\Core IT\May 4th - DL Test

It’s a folder
No related file object

the Filter Manager is calling IoCreateFileSpecifyDeviceObjectHint and trying to open what looks to be the parent of the target name.
1: kd> ?? (POBJECT_ATTRIBUTES) 0xb25bf86c
POBJECT_ATTRIBUTES 0xb25bf86c
+0x000 Length : 0x18
+0x004 RootDirectory : (null)
+0x008 ObjectName : 0xb25bf948 _UNICODE_STRING "??\H:\My Documents\Core IT"
+0x00c Attributes : 0x240
+0x010 SecurityDescriptor : (null)
+0x014 SecurityQualityOfService : (null)

I can’t seem to find definitions from many of the functions on the stack, if anyone can point to the function definitions for MUP, I might be able to figure out where things go wonky.

Or even ones like ObOpenObjectByName, I would have thought that one would be documented.

thank you,

Gene

7

Hi all,

I am writing a Filesystem runs as service(Kernel mode) and assigns
Driver unload routine in DriverEntry.Problem is it doesn’t called at system
shutdown ??
i am not sure it shuld be called OR not at time of shutdown .

On Wed, May 13, 2009 at 9:08 PM, wrote:

> Just like we expected, the crashed showed back up. I’m starting to think
> your right and McAfee is really causing the problem. I still have to deal
> with it though. Right now, I think my only option is to completely ignore
> operations on DFS, which is sad since we have no other problems on DFS other
> than this one customer.
>
> I would rather not have to do that and any guidance would be very much
> appreciated.
>
> Here is what I’ve figured out so far:
>
> The customer is renaming the folder “H:\My Documents\Core IT\May 4th - DL”
> to “H:\My Documents\Core IT\May 4th - DL Test”
> H is a DFS folder on a domain other then the login domain
>
> The source filename
> 1: kd> ?? nameInfo
> struct _FLT_FILE_NAME_INFORMATION * 0xe3ae8034
> +0x000 Size : 0x40
> +0x002 NamesParsed : 0xf
> +0x004 Format : 1
> +0x008 Name : _UNICODE_STRING “\Device\LanmanRedirector<br>> marmite.northamerica.intra.abbott.com\users11$\DEVENBJ\My Documents\Core
> IT\May 4th - DL”
> +0x010 Volume : _UNICODE_STRING “\Device\LanmanRedirector”
> +0x018 Share : _UNICODE_STRING “<br>> marmite.northamerica.intra.abbott.com\users11$”
> +0x020 Extension : _UNICODE_STRING “”
> +0x028 Stream : _UNICODE_STRING “”
> +0x030 FinalComponent : _UNICODE_STRING “May 4th - DL”
> +0x038 ParentDir : _UNICODE_STRING "\DEVENBJ\My Documents\Core
> IT"
>
> the rename target
> 1: kd> ??(PFILE_RENAME_INFORMATION)
> Data->Iopb->Parameters.SetFileInformation.InfoBuffer
> PFILE_RENAME_INFORMATION 0x89f3e9c0
> +0x000 ReplaceIfExists : 0 ‘’
> +0x004 RootDirectory : (null)
> +0x008 FileNameLength : 0x5a
> +0x00c FileName : [1] ""
>
> 89f3e9cc 5c 00 3f 00 3f 00 5c 00 48 00 3a 00 5c 00 4d 00 79 00
> .?.?..H.:..M.y.
> 89f3e9de 20 00 44 00 6f 00 63 00 75 00 6d 00 65 00 6e 00 74 00
> .D.o.c.u.m.e.n.t.
> 89f3e9f0 73 00 5c 00 43 00 6f 00 72 00 65 00 20 00 49 00 54 00
> s..C.o.r.e. .I.T.
> 89f3ea02 5c 00 4d 00 61 00 79 00 20 00 34 00 74 00 68 00 20 00 .M.a.y.
> .4.t.h. .
> 89f3ea14 2d 00 20 00 44 00 4c 00 20 00 54 00 65 00 73 00 74 00 -. .D.L.
> .T.e.s.t.
>
> or ??\H:\My Documents\Core IT\May 4th - DL Test
>
> It’s a folder
> No related file object
>
> the Filter Manager is calling IoCreateFileSpecifyDeviceObjectHint and
> trying to open what looks to be the parent of the target name.
> 1: kd> ?? (POBJECT_ATTRIBUTES) 0xb25bf86c
> POBJECT_ATTRIBUTES 0xb25bf86c
> +0x000 Length : 0x18
> +0x004 RootDirectory : (null)
> +0x008 ObjectName : 0xb25bf948 _UNICODE_STRING "??\H:\My
> Documents\Core IT"
> +0x00c Attributes : 0x240
> +0x010 SecurityDescriptor : (null)
> +0x014 SecurityQualityOfService : (null)
>
> I can’t seem to find definitions from many of the functions on the stack,
> if anyone can point to the function definitions for MUP, I might be able to
> figure out where things go wonky.
>
> Or even ones like ObOpenObjectByName, I would have thought that one would
> be documented.
>
> thank you,
>
> Gene
>
> —
> 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
>

–

With Best Regards
Vijay Kumar