SharedCacheMap getting set to zero.....

NTFSD
1

In our file system, we have seen a few instances of the following scenario:

A) Initialize a (PFILE_OBJECT)VirtualVolumeFile shared cache map with
CcInitializeCacheMap().

B) Verify that VirtualVolumeFile->SectionObjectPointer->SharedCacheMap is
non-NULL.

C) After some unknown (long) set of operations, SharedCacheMap is NULL,
resulting in a
page fault when the file system code calls into a Windows routine that
accesses the
SharedCacheMap, such as CcGetActiveVacb().
VirtualVolumeFile->SectionObjectPointer->DataSectionObject is (apparently)
still valid - or at least non-zero.

Clearly, something is happening to zero out the SharedCacheMap; we’re
wondering if it’s a side effect of something we’re doing with the Cache
Manager that we don’t know about.

Where does the Cache Manager (i.e., what CM calls) tear down the cache map
(clearly, CcUnititalizeCacheMap() is one of them, but we’re pretty sure
we’re not calling it during the processing in question, and I believe it
would invalidate the DataSectionObject if it was called)? Is this something
that can only happen as a consequence of us requesting it? Or will the cache
manager take this action during some error processing paths?

It’s entirely possible that we’re whacking the SharedCacheMap pointer
somewhere in our code, but it isn’t likely. This is happening only on x64
machines, FWIW.

This doesn’t happen often enough that the easy ways to debug it (i.e., a
watch point on SharedCacheMap) are very easy to accomplish, so we’re looking
for other obscure paths that might lead us here.

Thanks!..dave

2

> VirtualVolumeFile->SectionObjectPointer->DataSectionObject is

VirtualVolumeFile->SectionObjectPointer->(apparently)
still valid - or at least non-zero.

should have read

VirtualVolumeFile->SectionObjectPointer->DataSectionObject is (apparently)
still valid - or at least non-zero.

Duh…dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Beaver
Sent: Friday, April 21, 2006 1:29 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] SharedCacheMap getting set to zero…

In our file system, we have seen a few instances of the following scenario:

A) Initialize a (PFILE_OBJECT)VirtualVolumeFile shared cache map with
CcInitializeCacheMap().

B) Verify that VirtualVolumeFile->SectionObjectPointer->SharedCacheMap is
non-NULL.

C) After some unknown (long) set of operations, SharedCacheMap is NULL,
resulting in a page fault when the file system code calls into a Windows
routine that accesses the SharedCacheMap, such as CcGetActiveVacb().
VirtualVolumeFile->SectionObjectPointer->DataSectionObject is
VirtualVolumeFile->SectionObjectPointer->(apparently)
still valid - or at least non-zero.

Clearly, something is happening to zero out the SharedCacheMap; we’re
wondering if it’s a side effect of something we’re doing with the Cache
Manager that we don’t know about.

Where does the Cache Manager (i.e., what CM calls) tear down the cache map
(clearly, CcUnititalizeCacheMap() is one of them, but we’re pretty sure
we’re not calling it during the processing in question, and I believe it
would invalidate the DataSectionObject if it was called)? Is this something
that can only happen as a consequence of us requesting it? Or will the cache
manager take this action during some error processing paths?

It’s entirely possible that we’re whacking the SharedCacheMap pointer
somewhere in our code, but it isn’t likely. This is happening only on x64
machines, FWIW.

This doesn’t happen often enough that the easy ways to debug it (i.e., a
watch point on SharedCacheMap) are very easy to accomplish, so we’re looking
for other obscure paths that might lead us here.

Thanks!..dave

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

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

3

Dave,
I have a memory of seeing SharedCacheMap go to null during a call to
CcUninitializeCacheMap when the cache hasn’t seen any activity on the file
object yet (despite having chosen this FO as the representative one). In my
situation it was easy to diagnose and easy to fix so I just marked it up an
another CacheManager quirk and forgot about it so I may not have the details
exactly right, but this might help…

/rod

4

Thanks, Rod. In our case, we’re pretty sure we’re NOT calling
CcUninitializeCacheMap in the time between we initialize the file object and
the time it bugchecks with the SharedCacheMap being zero.

But only pretty sure. That’s why we’re trying to figure out if there’s any
other time the cache manager will zero the pointer.

…dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Saturday, April 22, 2006 9:06 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] SharedCacheMap getting set to zero…

Dave,
I have a memory of seeing SharedCacheMap go to null during a call to
CcUninitializeCacheMap when the cache hasn’t seen any activity on the file
object yet (despite having chosen this FO as the representative one). In my
situation it was easy to diagnose and easy to fix so I just marked it up an
another CacheManager quirk and forgot about it so I may not have the details
exactly right, but this might help…

/rod

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

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

5

“ba w4” on a SharedCacheMap pointer will help.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “David Beaver”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, April 22, 2006 12:29 AM
Subject: [ntfsd] SharedCacheMap getting set to zero…

> In our file system, we have seen a few instances of the following scenario:
>
> A) Initialize a (PFILE_OBJECT)VirtualVolumeFile shared cache map with
> CcInitializeCacheMap().
>
> B) Verify that VirtualVolumeFile->SectionObjectPointer->SharedCacheMap is
> non-NULL.
>
> C) After some unknown (long) set of operations, SharedCacheMap is NULL,
> resulting in a
> page fault when the file system code calls into a Windows routine that
> accesses the
> SharedCacheMap, such as CcGetActiveVacb().
> VirtualVolumeFile->SectionObjectPointer->DataSectionObject is (apparently)
> still valid - or at least non-zero.
>
> Clearly, something is happening to zero out the SharedCacheMap; we’re
> wondering if it’s a side effect of something we’re doing with the Cache
> Manager that we don’t know about.
>
> Where does the Cache Manager (i.e., what CM calls) tear down the cache map
> (clearly, CcUnititalizeCacheMap() is one of them, but we’re pretty sure
> we’re not calling it during the processing in question, and I believe it
> would invalidate the DataSectionObject if it was called)? Is this something
> that can only happen as a consequence of us requesting it? Or will the cache
> manager take this action during some error processing paths?
>
> It’s entirely possible that we’re whacking the SharedCacheMap pointer
> somewhere in our code, but it isn’t likely. This is happening only on x64
> machines, FWIW.
>
> This doesn’t happen often enough that the easy ways to debug it (i.e., a
> watch point on SharedCacheMap) are very easy to accomplish, so we’re looking
> for other obscure paths that might lead us here.
>
> Thanks!..dave
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

6

The biggest problem with access breakpoint is that they change timing
considerably - thus, if this is some sort of timing problem (or
something that happens rarely) then this won’t help much (and I’m
assuming Dave has already tried something as obvious as an access
breakpoint - he’s been working file systems on NT longer than I have and
these days that’s saying something…)

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Sunday, April 23, 2006 8:20 PM
To: ntfsd redirect
Subject: Re: [ntfsd] SharedCacheMap getting set to zero…

“ba w4” on a SharedCacheMap pointer will help.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “David Beaver”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, April 22, 2006 12:29 AM
Subject: [ntfsd] SharedCacheMap getting set to zero…

> In our file system, we have seen a few instances of the following
scenario:
>
> A) Initialize a (PFILE_OBJECT)VirtualVolumeFile shared cache map with
> CcInitializeCacheMap().
>
> B) Verify that VirtualVolumeFile->SectionObjectPointer->SharedCacheMap
is
> non-NULL.
>
> C) After some unknown (long) set of operations, SharedCacheMap is
NULL,
> resulting in a
> page fault when the file system code calls into a Windows routine that
> accesses the
> SharedCacheMap, such as CcGetActiveVacb().
> VirtualVolumeFile->SectionObjectPointer->DataSectionObject is
(apparently)
> still valid - or at least non-zero.
>
> Clearly, something is happening to zero out the SharedCacheMap; we’re
> wondering if it’s a side effect of something we’re doing with the
Cache
> Manager that we don’t know about.
>
> Where does the Cache Manager (i.e., what CM calls) tear down the cache
map
> (clearly, CcUnititalizeCacheMap() is one of them, but we’re pretty
sure
> we’re not calling it during the processing in question, and I believe
it
> would invalidate the DataSectionObject if it was called)? Is this
something
> that can only happen as a consequence of us requesting it? Or will the
cache
> manager take this action during some error processing paths?
>
> It’s entirely possible that we’re whacking the SharedCacheMap pointer
> somewhere in our code, but it isn’t likely. This is happening only on
x64
> machines, FWIW.
>
> This doesn’t happen often enough that the easy ways to debug it (i.e.,
a
> watch point on SharedCacheMap) are very easy to accomplish, so we’re
looking
> for other obscure paths that might lead us here.
>
> Thanks!..dave
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

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

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

7

Yeah, we’re trying that (actually, ba w4 “kd; g”, and we’re looking to make
the whole thing a little more specific than that, even). But this happens
very infrequently, and we’ve usually got a bunch of volume files (some of
our tests run to more than 100 volumes, one per). So this is a trifle
tedious…

thanks…dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Sunday, April 23, 2006 5:20 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] SharedCacheMap getting set to zero…

“ba w4” on a SharedCacheMap pointer will help.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “David Beaver”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, April 22, 2006 12:29 AM
Subject: [ntfsd] SharedCacheMap getting set to zero…

> In our file system, we have seen a few instances of the following
scenario:
>
> A) Initialize a (PFILE_OBJECT)VirtualVolumeFile shared cache map with
> CcInitializeCacheMap().
>
> B) Verify that VirtualVolumeFile->SectionObjectPointer->SharedCacheMap is
> non-NULL.
>
> C) After some unknown (long) set of operations, SharedCacheMap is NULL,
> resulting in a
> page fault when the file system code calls into a Windows routine that
> accesses the
> SharedCacheMap, such as CcGetActiveVacb().
> VirtualVolumeFile->SectionObjectPointer->DataSectionObject is (apparently)
> still valid - or at least non-zero.
>
> Clearly, something is happening to zero out the SharedCacheMap; we’re
> wondering if it’s a side effect of something we’re doing with the Cache
> Manager that we don’t know about.
>
> Where does the Cache Manager (i.e., what CM calls) tear down the cache map
> (clearly, CcUnititalizeCacheMap() is one of them, but we’re pretty sure
> we’re not calling it during the processing in question, and I believe it
> would invalidate the DataSectionObject if it was called)? Is this
something
> that can only happen as a consequence of us requesting it? Or will the
cache
> manager take this action during some error processing paths?
>
> It’s entirely possible that we’re whacking the SharedCacheMap pointer
> somewhere in our code, but it isn’t likely. This is happening only on x64
> machines, FWIW.
>
> This doesn’t happen often enough that the easy ways to debug it (i.e., a
> watch point on SharedCacheMap) are very easy to accomplish, so we’re
looking
> for other obscure paths that might lead us here.
>
> Thanks!..dave
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

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

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

8

CcPurgeCacheSection may tear down Private and Shared cache maps if it is
called with
the last parameter( i.e. UninitializeCacheMaps ) set to TRUE, because it
calls CcUninitializeCacheMap for all file objects with the valid Private
Cache Map.

“David Beaver” wrote in message news:xxxxx@ntfsd…
> In our file system, we have seen a few instances of the following
> scenario:
>
> A) Initialize a (PFILE_OBJECT)VirtualVolumeFile shared cache map with
> CcInitializeCacheMap().
>
> B) Verify that VirtualVolumeFile->SectionObjectPointer->SharedCacheMap is
> non-NULL.
>
> C) After some unknown (long) set of operations, SharedCacheMap is NULL,
> resulting in a
> page fault when the file system code calls into a Windows routine that
> accesses the
> SharedCacheMap, such as CcGetActiveVacb().
> VirtualVolumeFile->SectionObjectPointer->DataSectionObject is (apparently)
> still valid - or at least non-zero.
>
> Clearly, something is happening to zero out the SharedCacheMap; we’re
> wondering if it’s a side effect of something we’re doing with the Cache
> Manager that we don’t know about.
>
> Where does the Cache Manager (i.e., what CM calls) tear down the cache map
> (clearly, CcUnititalizeCacheMap() is one of them, but we’re pretty sure
> we’re not calling it during the processing in question, and I believe it
> would invalidate the DataSectionObject if it was called)? Is this
> something
> that can only happen as a consequence of us requesting it? Or will the
> cache
> manager take this action during some error processing paths?
>
> It’s entirely possible that we’re whacking the SharedCacheMap pointer
> somewhere in our code, but it isn’t likely. This is happening only on x64
> machines, FWIW.
>
> This doesn’t happen often enough that the easy ways to debug it (i.e., a
> watch point on SharedCacheMap) are very easy to accomplish, so we’re
> looking
> for other obscure paths that might lead us here.
>
> Thanks!..dave
>
>

9

Thanks, I’d forgotten about that one, but we never use CcPurgeCacheSection
with the last parameter set to TRUE (I just cheeked the code again to make
sure that’s still true).

…dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Monday, April 24, 2006 5:13 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] SharedCacheMap getting set to zero…

CcPurgeCacheSection may tear down Private and Shared cache maps if it is
called with the last parameter( i.e. UninitializeCacheMaps ) set to TRUE,
because it calls CcUninitializeCacheMap for all file objects with the valid
Private Cache Map.

“David Beaver” wrote in message news:xxxxx@ntfsd…
> In our file system, we have seen a few instances of the following
> scenario:
>
> A) Initialize a (PFILE_OBJECT)VirtualVolumeFile shared cache map with
> CcInitializeCacheMap().
>
> B) Verify that VirtualVolumeFile->SectionObjectPointer->SharedCacheMap
> is non-NULL.
>
> C) After some unknown (long) set of operations, SharedCacheMap is
> NULL, resulting in a page fault when the file system code calls into a
> Windows routine that accesses the SharedCacheMap, such as
> CcGetActiveVacb().
> VirtualVolumeFile->SectionObjectPointer->DataSectionObject is
> VirtualVolumeFile->SectionObjectPointer->(apparently)
> still valid - or at least non-zero.
>
> Clearly, something is happening to zero out the SharedCacheMap; we’re
> wondering if it’s a side effect of something we’re doing with the
> Cache Manager that we don’t know about.
>
> Where does the Cache Manager (i.e., what CM calls) tear down the cache
> map (clearly, CcUnititalizeCacheMap() is one of them, but we’re pretty
> sure we’re not calling it during the processing in question, and I
> believe it would invalidate the DataSectionObject if it was called)?
> Is this something that can only happen as a consequence of us
> requesting it? Or will the cache manager take this action during some
> error processing paths?
>
> It’s entirely possible that we’re whacking the SharedCacheMap pointer
> somewhere in our code, but it isn’t likely. This is happening only on
> x64 machines, FWIW.
>
> This doesn’t happen often enough that the easy ways to debug it (i.e.,
> a watch point on SharedCacheMap) are very easy to accomplish, so we’re
> looking for other obscure paths that might lead us here.
>
> Thanks!..dave
>
>

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

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