Just FYI we rely on the FsContext field (after the create has been passed back up) being a constant value. We use the FsContext field as a file identifier when searching for our own control blocks referring to a file; it’s shared between all concurrent opens on a file.
Andy.
-----Original Message-----
From: Daniel Lovinger [mailto:xxxxx@windows.microsoft.com]
Sent: 23 October 2001 17:36
To: File Systems Developers
Subject: [ntfsd] RE: About FCB resources (Was: The strangest problem
(BSOD 0xCC))
If what you have is really a fileobject and what it is pointing to is really something which has the FSRTL_COMMON_FCB_HEADER … trivial way to check:
kd> dd
xxxxyyyy …
…
xxxx == small integer, =~ size of pool block is in (!pool)
yyyy == 050x or 070x for the case of FAT and NTFS respectively
then the header has been wiped out. Use special pool through gflags and/or the verifier to attempt to make progress.
Of course, this is entirely moot since you are looking at the fileobject before it is filled in by the filesystem. Unless you are staring at the RelatedFileObject. That said, I don’t know of anything devious that fiddles with the FsContext field so it is probably still a corruptor of some sort, though the “window” of opportunity is obviously fairly brief here since the fileobject just got rolled up. This may provide some clues.
–
_______________________________________________
FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free!
http://www.net2phone.com/cgi-bin/link.cgi?143
—
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