Hi!
Thanks Tony! Thanks Dan! I really appreciate your help.
I think I am beginning to figure out were I am going wrong. What I am trying to do it create folders in my volume. My routines are not very optimised and map and pin data at will.
The assertion occurs when I try to pin a 0x3400 byte range and then subsequently do a CcUnpinRepinnedBcb. I am not actually using the whole range. So if I limit myself to just 0x400 bytes, the routine goes off fine.
But I still get into trouble when I create another folder. I might be ‘forgetting’ to unpin a BCB somewhere…
But I still don’t understand how pinning a large range could cause trouble. I do pin the data successfully. I also am not uninitialising the cache prematurely. The file object is the the volume stream file object and I don’t uninitialize its cache till system shutdown.
Any ideas / suggestions.
Thanks for your time!
Manoj
Daniel Lovinger wrote: Semantically, that isn’t an assert. C0000005 is STATUS_ACCESS_VIOLATION and you are getting it thrown as an exception. “First chance” (which you basically never want to bother seeing) is when the debugger breaks out as exception is being first thrown and you would see it before the callstack is walked for a handler, but the “second chance” is when no exception handler up the callstack said it could handle it. I.e., your machine is about to bluescreen on you. This is actually correct for S_A_V: handling it in some way other than crashing means you are most likely letting the machine run forward in some unknowably corrupt state. This is a bad idea.
But, the crash.
Tony’s in the right part of the forest. +70 into the BCB (in this release of Windows, etc.) is another private context structure pointer of the cache manager’s. It is what gets built/referenced on CcInitializeCacheMap and what gets dereferenced/torn-down when you CcUninitializeCacheMap. You may have a synchronization gap between this path and the one that can CcUninit this object which the Bcb is built on, usually IRP_MJ_CLEANUP. It is not legal to use Cc APIs and hold references to BCBs, etc. unless you are within a reference bounded by the CcInit/Uninit calls.
What I’d look at first is to make sure you’ve actually got a BCB in your hands. !pool it. If the tag isn’t Cc - and allocated, and allocated at a block -8 from the pointer you have in your hands (covering the pool header) - it may be a wild pointer; however, Cc also would have ripped up the BCB and returned it to the pool if the case I described above happened. Since you are in the process of taking an S_A_V exception, its unlikely the pointer at +70 is valid.
dan
–
This posting is provided “AS IS” with no warranties, and
confers no rights.
-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Wednesday, April 10, 2002 7:49 AM
To: File Systems Developers
Subject: [ntfsd] RE: CcUnpinRepinnedBcb - Assertion Failure
Manoj,
I know that in a case like this, I’d look at the code leading up to it.
Since I don’t have your exact system in front of me, I grabbed the code off
of an XP system I have under the debugger:
kd> u CcUnpinRepinnedBcb
nt!CcUnpinRepinnedBcb:
804db556 53 push ebx
804db557 56 push esi
804db558 8b74240c mov esi,[esp+0xc]
804db55c 8b4670 mov eax,[esi+0x70]
804db55f 33db xor ebx,ebx
804db561 385c2410 cmp [esp+0x10],bl
804db565 57 push edi
804db566 8b7c2418 mov edi,[esp+0x18]
kd> u
nt!CcUnpinRepinnedBcb+14:
804db56a 891f mov [edi],ebx
804db56c 0f8486000000 je nt!CcUnpinRepinnedBcb+0xa2 (804db5f8)
804db572 f6406d02 test byte ptr [eax+0x6d],0x2
Note that my eax offset is different than yours, which just tells me that
some data structure has changed size. The trick is to figure out (if
possible) which data structure it was.
EAX came from ESI+0x70. ESI came from the stack - it was 12 bytes offset
from the stack upon entry. Since there’s no EBP here, this has been “frame
pointer optimized” which would show up if you used the “kv” command in
WinDBG. On entry ESP would point to the return address, and ESP+0x4 would
point to the first parameter. Pushing two arguments onto the stack would
give us ESP+0x8 would be the return address and ESP+0xC would be the first
parameter.
SO - ESI is the first parameter of the function. And - voila! That is the
BCB itself. Of course, the disappointing thing here is that the BCB data
structure isn’t a published structure. It is a PVOID and hence opaque.
Whatever the case, EAX is loaded from the ESI register (in my code, the
DWORD field 0x70 bytes from the beginning of the structure). Since I don’th
have your system in front of me I cannot try what I’d do next - use the
"!pool " command on the EAX address (that might give me a hint as
to what the EAX register contains).
But I can guess that whatever it is doesn’t point to the right data
structure. I suspect that this is some data structure that YOU affect.
Have you, for instance, closed the file object from which you first created
the BCB (CcPinRead)?
Also, as a debugging aid, you might want to see which file this is (by
calling CcGetFileObjectFromBcb). Somehow I suspect that you are tearing
down a data structure prematurely.
Perhaps someone with more insight into how the Cache Manager is handling
BCBs (e.g., the actual definition of the BCB structure) could provide you
with more insight. In the meantime though, try looking at what YOU are
doing that is causing state to be discarded.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Hope to see you at the next OSR file systems class October 7, 2002!
-----Original Message-----
From: Manoj Paul Joseph [mailto:xxxxx@yahoo.com]
Sent: Wednesday, April 10, 2002 3:36 AM
To: File Systems Developers
Subject: [ntfsd] CcUnpinRepinnedBcb - Assertion Failure
Hi!
I am getting into trouble with the nt!CcUnpinRepinnedBcb function. I am
using the Cache manager’s Pinning interface to handle my volume’s meta data
(including directories).
To flush meta-data during file creation, I save up the BCBs after doing
a CcRepinBcb. Once I have completed the create and released the resources, I
do a CcUnpinRepinnedBcb on all the saved BCBs. I keep getting an assertion
failure everytime on a particular BCB.
This is what I see in Win Debug
---------------------------------
Access violation - code c0000005 (!!! second chance !!!)
nt!CcUnpinRepinnedBcb+1c:
80103f4e f6406902 test byte ptr [eax+0x69],0x2
---------------------------------
It doesn’t happen (the assertion) if I have just that BCB to flush.
I don’t have a checked build of Win NT and I don’t have a clue as to
what
8077f8e8 00000001 fcacd628 nt!CcUnpinRepinnedBcb+0x1c
80796528 fcd25b5e 8076fea8 ext2!Ext2FlushSavedBCBs+0xb6
80796528 8076fea8 00000001 ext2!Ext2CommonCreate+0x14ee
807929c0 8076fea8 fcacdaa0 ext2!Ext2Create+0x172
80172720 807c0e18 00000000 nt!IofCallDriver+0x37
807c0e30 00000000 fcacd998 nt!IopParseDevice+0x7cc
00000000 fcacda54 00000040 nt!ObpLookupObjectName+0x283
016be9d4 00000000 acda9001 nt!ObOpenObjectByName+0xbb
016bea0c 00100001 016be9d4 nt!IoCreateFile+0x436
016bea0c 00100001 016be9d4 nt!NtCreateFile+0x2e
016bea0c 00100001 016be9d4 nt!KiSystemService+0xc4
016bec70 00000000 00000000 ntdll!ZwCreateFile+0xb
77c40000 00001051 00001051 0x77ca11ba
77f76aa0 00000409 77cd1000 ntdll!RtlImageDirectoryEntryToData+0x21
00000000 00000000 00000000 0x16beb98
fcacdd58 fcacdd54 0042b6e0 nt!KiCallUserMode+0x4
00000002 fcacdd28 00000018 nt!KeUserModeCallback+0x9e
a02bb6e0 0000007b 0031006e win32k!SfnDWORD+0xb5
a02bb6e0 0000007b 0031006e win32k!xxxSendMes Download Yahoo! Score Tracker
for live cricket scores on your desktop — You are currently subscribed to
ntfsd as: xxxxx@osr.com To unsubscribe send a blank email to
%%email.unsub%%
—
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to %%email.unsub%%
-----------------------------------
Manoj Paul Joseph,
Master of Computer Applications (final year student),
School of Computer Science and Engineering,
Anna University,
Chennai (Madras),
India.
---------------------------------
Download Yahoo! Score Tracker for live cricket scores on your desktop