Still struggling with pFCB->Resource being 0xBBBBBBBB

Hi,

since two of the most valuable contributors of the NTFsd list are already
(or still ?) awake today, I thought I’d throw in yet another brainbreaker.

I’ve posted a question here earlier this week about getting the FCB from
FileObject->FsContext, and trying to acquire the pFCB->Resource. In a
specific case, the resource’s value equals 0xBBBBBBBB.

So, here is some more information.

The strange value for the resource is already detected in the main ‘hook’
routine for the filter driver. The driver is attached to all available
DosDevices (\DosDevice\A: etc.) and to \Device\LanManRedirector. An IRP
(IRP_MJ_CREATE) comes in on the following DeviceObject (so this is in the
IRP_MJ_CREATE path, not on completion):

DeviceObject 8221C680

Type = 00000003
Flags = 00000000
Characteristics = 00000000
DeviceType = 00000014
DeviceType = FILE_DEVICE_NETWORK_FILE_SYSTEM
HookExtension = 8221C738

Now, the FileObject in the current stack location has the following fields:

FileObject 821542E8

Type 5
Size 112
DeviceObject 82327A50
Vpb 00000000
FsContext BCCE2ED4
FsContext2 11444653
FinalStatus 00000000
RelatedFileObject 00000000
Flags 00000002
FileName
\venus.thunderstore.local\sysvol\thunderstore.local\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini
CurrentByteOffset 00000000
Waiters 0
Busy 0
LastLock 00000000
Lock 00040001
Event 00040000

So a quick inspection of the
(PFSRTL_COMMON_FCB_HEADER)FileObject->FsContext shows me the following:

FCB BCCE2ED4

pFCB->NodeTypeCode = 000000CA
pFCB->NodeByteSize = 000000CE
pFCB->Flags = 00000030
pFCB->IsFastIoPossible = 0000002F
pFCB->Flags2 = 000000CE
pFCB->Reserved = 000000BC
pFCB->Resource = BBBBBBBB
pFCB->PagingIoResource = 00000001

Is this enough information for you to tell me what is happening ? Can we
trust the FCB content enough to state that the request concerns memory
mapped I/O (based on pFCB->Flags&0x20) ? Any other hints or tips to smash
this bug ?

Thanks again,

Bartjan Wattel.


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Bartjan,

First, I’d note that there is nothing that REQUIRES a particular FSD to use
FSRTL_FCB_COMMON_HEADER (or, as they almost all do in XP, the ADVANCED
version, which just has extra fields at the end of it.) So I suppose it is
possible that you have found some interesting file system that isn’t using
the FsRtl library and hence isn’t using the common header. Or you’ve found
some interesting path for memory corruption, or you’ve found some path where
the file object isn’t being fully created (there are a few odd cases where
the I/O manager “fakes” objects, actually…)

So, to make more sense of this question, I’d want to know:

  • Which driver owns this device?
  • What does the stack look like at this point?

These may lead to a better understanding of why you are seeing this
particular combination.

Independent of the added information, what you are showing us does not look
like a common header structure to me. The file object does not point back
to the device object you initially cited (is that your device object? Or
the device object of the file system in question?) The FsContext2 value is
quite clearly garbage.

Based on the name, the system is attempting to grab policy information (hmm.
I think that’s domain policy information and not domain controller policy
information, based on the UUID in the name, but I know just enough about AD
to be dangerous.) Thus, this is probably some OS mechanism grabbing the
policy so that it can apply it. Dare I suggest it is some kernel mode
component attempting this? Or perhaps this is the FRS - this isn’t an
Active Directory server is it?

The only other thought is that RDR2 (or more likely RDBSS) is being tricky
here and storing information/data structure pointers that have nothing to do
with standard file system access. Normally I’d not suspect something like
that, but when it involves grabbing a group policy file (and the ini file at
that.)

Do you happen to have a nice kernel memory dump on this one. This could
provide some interesting memory to grovel around.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>

Sleep? Who needs to sleep. Someone I know has a T-shirt that sums it up
quite well - “I’ll sleep when I’m dead.” :wink:

-----Original Message-----
From: Bartjan Wattel [mailto:xxxxx@zeelandnet.nl]
Sent: Friday, October 26, 2001 6:01 AM
To: File Systems Developers
Subject: [ntfsd] Still struggling with pFCB->Resource being 0xBBBBBBBB

Hi,

since two of the most valuable contributors of the NTFsd list are already
(or still ?) awake today, I thought I’d throw in yet another brainbreaker.

I’ve posted a question here earlier this week about getting the FCB from
FileObject->FsContext, and trying to acquire the pFCB->Resource. In a
specific case, the resource’s value equals 0xBBBBBBBB.

So, here is some more information.

The strange value for the resource is already detected in the main ‘hook’
routine for the filter driver. The driver is attached to all available
DosDevices (\DosDevice\A: etc.) and to \Device\LanManRedirector. An IRP
(IRP_MJ_CREATE) comes in on the following DeviceObject (so this is in the
IRP_MJ_CREATE path, not on completion):

DeviceObject 8221C680

Type = 00000003
Flags = 00000000
Characteristics = 00000000
DeviceType = 00000014
DeviceType = FILE_DEVICE_NETWORK_FILE_SYSTEM
HookExtension = 8221C738

Now, the FileObject in the current stack location has the following fields:

FileObject 821542E8

Type 5
Size 112
DeviceObject 82327A50
Vpb 00000000
FsContext BCCE2ED4
FsContext2 11444653
FinalStatus 00000000
RelatedFileObject 00000000
Flags 00000002
FileName
\venus.thunderstore.local\sysvol\thunderstore.local\Policies{31B2F340-016D-
11D2-945F-00C04FB984F9}\gpt.ini
CurrentByteOffset 00000000
Waiters 0
Busy 0
LastLock 00000000
Lock 00040001
Event 00040000

So a quick inspection of the (PFSRTL_COMMON_FCB_HEADER)FileObject->FsContext
shows me the following:

FCB BCCE2ED4

pFCB->NodeTypeCode = 000000CA
pFCB->NodeByteSize = 000000CE
pFCB->Flags = 00000030
pFCB->IsFastIoPossible = 0000002F
pFCB->Flags2 = 000000CE
pFCB->Reserved = 000000BC
pFCB->Resource = BBBBBBBB
pFCB->PagingIoResource = 00000001

Is this enough information for you to tell me what is happening ? Can we
trust the FCB content enough to state that the request concerns memory
mapped I/O (based on pFCB->Flags&0x20) ? Any other hints or tips to smash
this bug ?

Thanks again,

Bartjan Wattel.


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com