bugcheck F5 in filter manager

NTFSD
1

Hi,

I am debugging an issue with a mini filter driver, and found several times the following bugcheck:

FLTMGR_FILE_SYSTEM (f5)
An unrecoverable failure occured inside the filter manager.
Arguments:
Arg1: 00000068, The reason for the failure
Arg2: 9ae76c68
Arg3: 9ae76c94
Arg4: 00000000

Debugging Details:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_RC

BUGCHECK_STR: 0xF5

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 83b82d23 to 818acfcb

STACK_TEXT:
9c821aa8 83b82d23 000000f5 00000068 9ae76c68 nt!KeBugCheckEx+0x1e
9c821ac4 83b5d03c 9ae76c94 82ccbc60 9453a2cb fltmgr!FltReleaseFileNameInformation+0x43
9c821ae8 83b6a18b 881e7918 00000008 00000000 fileinfo!FIStreamCleanup+0x94
9c821b04 83b6a358 881e78e8 881e78e8 9c821b28 fltmgr!DoFreeContext+0x45
9c821b14 83b7a651 881e78e8 9308f9f0 9308f9c8 fltmgr!DoReleaseContext+0x42
9c821b28 83b863b5 9308f9f4 9308f9f0 ffffffff fltmgr!FltpDeleteContextList+0xd1
9c821b48 83b865d6 9308f9c8 9308f9cc a01700f8 fltmgr!CleanupStreamListCtrl+0x1b
9c821b5c 819f8bfc 9308f9cc 9c82a0d4 818e0b30 fltmgr!DeleteStreamListCtrlCallback+0x5a
9c821b94 8396bd79 a01700f8 00000000 a01700f8 nt!FsRtlTeardownPerStreamContexts+0xd4
9c821bb0 8397e1ad 00000705 a0170008 a0170030 Ntfs!NtfsDeleteScb+0x1f2
9c821bc8 838f8c9b 946cfcf8 a01700f8 00000000 Ntfs!NtfsRemoveScb+0xc2
9c821be4 8398aed4 946cfcf8 a0170008 00000000 Ntfs!NtfsPrepareFcbForRemoval+0x59
9c821c28 839003be 946cfcf8 a01700f8 a0170298 Ntfs!NtfsTeardownStructures+0x62
9c821c50 83986fe1 946cfcf8 a01700f8 a0170298 Ntfs!NtfsDecrementCloseCounts+0xad
9c821cb0 8396c126 946cfcf8 a01700f8 a0170008 Ntfs!NtfsCommonClose+0x4d9
9c821d44 8186b8aa 00000000 00000000 933b5d78 Ntfs!NtfsFspClose+0x117
9c821d7c 819afbfd 00000000 9c82a680 00000000 nt!ExpWorkerThread+0xfd
9c821dc0 8189a396 8186b7ad 80000000 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
fileinfo!FIStreamCleanup+94
83b5d03c b8dcb1b583 mov eax,offset fileinfo!FIGlobals+0x1c (83b5b1dc)

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: fileinfo!FIStreamCleanup+94

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: fileinfo

IMAGE_NAME: fileinfo.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4549ae1f

FAILURE_BUCKET_ID: 0xF5_fileinfo!FIStreamCleanup+94

BUCKET_ID: 0xF5_fileinfo!FIStreamCleanup+94

Followup: MachineOwner

The documentation in WinDbg says:
Parameter 1 - 0x68
Parameter 2 - Handle for the object.
Parameter 3 - 0
Parameter 4 - NTSTATUS code returned by ObReferenceObjectByHandle.
Cause of error - Unexpected failure referencing an object.

However, each of the dump I have checked differs from this description. As far as I could figure out, the actual usage of parameters is:
Parameter 1 - 0x68
Parameter 2 - it seems to be always Parameter 3 - 0x2C
Parameter 3 - pointer to a FLT_FILE_NAME_INFORMATION structure
Parameter 4 - it seems to be always 0

I also tried to see why FltReleaseFileNameInformation raises a BugCheck. It seems that the filter manager prepends the file name info structure with 0x2C bytes, and on the last DWORD of it (so, immediatly before the place where Parameter 3 points) there shall always be 0x1E000, however, on in the case of the dump I just analysed was 0x18000. Probably some flags are out of their normal value.

dt fltmgr!_FLT_FILE_NAME_INFORMATION 9ae76c94
+0x000 Size : 0x40
+0x002 NamesParsed : 0xf
+0x004 Format : 1
+0x008 Name : _UNICODE_STRING “\Device\HarddiskVolume3\w2\test\12 (106).vxe”
+0x010 Volume : _UNICODE_STRING “\Device\HarddiskVolume3”
+0x018 Share : _UNICODE_STRING “”
+0x020 Extension : _UNICODE_STRING “vxe”
+0x028 Stream : _UNICODE_STRING “”
+0x030 FinalComponent : _UNICODE_STRING “12 (106).vxe”
+0x038 ParentDir : _UNICODE_STRING "\w2\test"

dd 9ae76c90
9ae76c90 00018000 000f0040 00000001 00580058
…

Any suggestions? Where could I look for the cause of problem or a description of this particular bugcheck code?

thank you very much,

Sandor Lukacs
Virus Analyst, SOFTWIN
www.bitdefender.com

2

Sandor,

(so, immediatly before the place where Parameter 3 points) there shall
always be 0x1E000, however, on in the
case of the dump I just analysed was 0x18000

the code you’re referring to is a test operation

test dword ptr [eax+28h],1E000h

which does not test for equality, but does an “and” of the two. Since in
your case dest-mem contains 0x18000 the operation leads to a “jne
(bugcheck)”. In a normal case [eax+28h] contains zero.

Perhaps you are causing a reference mismatch somewhere in your driver.
Verifier? Checked build?

Regards
Frank

3

frank wrote:

Sandor,

> (so, immediatly before the place where Parameter 3 points) there shall
> always be 0x1E000, however, on in the
> case of the dump I just analysed was 0x18000
>

the code you’re referring to is a test operation

test dword ptr [eax+28h],1E000h

which does not test for equality, but does an “and” of the two. Since in
your case dest-mem contains 0x18000 the operation leads to a “jne
(bugcheck)”. In a normal case [eax+28h] contains zero.

That’s correct, thank you, I was misreading it.

Perhaps you are causing a reference mismatch somewhere in your driver.
Verifier? Checked build?

It might be mismatched reference, but I am already hunting it down for
two days and
I found no problems on code reviews, tests, logs etc. Driver Verifier
catches nothing,
and I still didn’t get to test it on checked build (this is next on my
list if code review
and all other ideas fail…).

Do you have any clue why the actual parameters in the dump and their
description
in WinDbg’s help differ? Might be just an out-of-date help, or I’m wrong?

thank you, have a nice day,

Sandor Lukacs
Virus Analyst, SOFTWIN

Regards
Frank

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

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

4

Sandor.

The current doc of bugcheck code F5 is definitely wrong.
FltReleaseFileNameInformation does something like this:

83f2fd0f 6a00 push 0
83f2fd11 8d482c lea ecx,[eax+2Ch]
83f2fd14 51 push ecx
83f2fd15 50 push eax
83f2fd16 6a68 push 68h
83f2fd18 68f5000000 push 0F5h
83f2fd1d ff15fcf1f183 call dword ptr [fltmgr!_imp__KeBugCheckEx
(83f1f1fc)]

where F5 is the bugcheck code, 68 is arg1, “eax”
(PFLT_FILE_NAME_INFORMATION-2c) is arg2, “ecx” (PFLT_FILE_NAME_INFORMATION)
is arg3 and 0 is arg4

I have no idea what FltManager is probing there and I bet they’ve changed
the meaning of 0x68 in Vista.

Good luck!
Frank

“Sandor LUKACS” schrieb im Newsbeitrag
news:xxxxx@ntfsd…
> frank wrote:
>> Sandor,
>>
>>
>>> (so, immediatly before the place where Parameter 3 points) there shall
>>> always be 0x1E000, however, on in the
>>> case of the dump I just analysed was 0x18000
>>>
>>
>> the code you’re referring to is a test operation
>>
>> test dword ptr [eax+28h],1E000h
>>
>> which does not test for equality, but does an “and” of the two. Since in
>> your case dest-mem contains 0x18000 the operation leads to a “jne
>> (bugcheck)”. In a normal case [eax+28h] contains zero.
>>
>>
> That’s correct, thank you, I was misreading it.
>> Perhaps you are causing a reference mismatch somewhere in your driver.
>> Verifier? Checked build?
>>
> It might be mismatched reference, but I am already hunting it down for two
> days and
> I found no problems on code reviews, tests, logs etc. Driver Verifier
> catches nothing,
> and I still didn’t get to test it on checked build (this is next on my
> list if code review
> and all other ideas fail…).
>
> Do you have any clue why the actual parameters in the dump and their
> description
> in WinDbg’s help differ? Might be just an out-of-date help, or I’m wrong?
>
> thank you, have a nice day,
>
> Sandor Lukacs
> Virus Analyst, SOFTWIN
>
>> Regards
>> Frank
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@bitdefender.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>