This is more of an internal question, and I’m not at a point with full
investigation yet, but in case someone could shed some light on it.
1)There is a top level driver ( mimicking some file system driver), but it
does not use the IoRegisterFileSystem(). This driver provides all the
callbacks for -
AcquireForLazyWrite
ReleaseFromLazyWrite
AcquireForReadAhead
ReleaseFromReadAhead
and of course for fastio dispatches.
- It is also not a legacy or mini filter ( since it is not attaching nor
having notification mechanism for any future fs ).
When noone is logged on ( from the users point of view), I see a whole lot
of paging i/o for write comes from mapped-writer thread.
Now my question is eventhough it is not registered as an FS, why am I
getting this?
Next question is what could possibly go wrong if this paging write i/o’s
are returned w/out further processing ( i.e anything but STATUS_SUCCESS).
I’m worried if it could keep the system from going to totally standby mode
and it could possibly cause damage to laptop.
Also is it possible that the mapped-writer keep trying the same thing? In
fact, I did not probe all the possible fields to make sure if it is the
same request being tried over and over again, since otherwise it is not
causing problems.
Finally I’ve a filter running in there too ( basically fsfilter) and it is
not hitting there as was expected from mapped-writer ( if I understand
it).
And what causes such an activity?
thanks
-pro
> Now my question is eventhough it is not registered as an FS, why am I
getting this?
How do they related? If you have open files on this driver - then paging IO
will come.
IoRegisterFileSystem only means - “I want to participate in filtering and in
automounting to all disk volumes”.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Now my question is eventhough it is not registered as an FS, why am I
getting this?
Why does this baffle you? It is normal for FSDs( even not registered by
IoRegisterFileSystem ) to receive requests from the system.
Next question is what could possibly go wrong if this paging write i/o’s
are returned w/out further processing ( i.e anything but STATUS_SUCCESS).
If you return STATUS_SUCCESS nothing goes wrong except data lost.
If you don’t return STATUS_SUCCESS then the behavior depends on the status
code and FSD type( network FSD or not ) for some codes the attempt will be
repeated for others the “Write Failled” message will be popped up.
And what causes such an activity?
Do you mean a lot of write requests from MapPW while a file has not been
modified by any application?
If yes, then check the read routine, there is a bug which results in a dirty
flag changing for page frame descriptors, the most common error is
MmProbeAndLockPages with Modify or Write access mode.
–
Slava Imameyev, xxxxx@hotmail.com
wrote in message news:xxxxx@ntfsd…
> This is more of an internal question, and I’m not at a point with full
> investigation yet, but in case someone could shed some light on it.
>
> 1)There is a top level driver ( mimicking some file system driver), but it
> does not use the IoRegisterFileSystem(). This driver provides all the
> callbacks for -
> AcquireForLazyWrite
> ReleaseFromLazyWrite
> AcquireForReadAhead
> ReleaseFromReadAhead
>
> and of course for fastio dispatches.
>
> 2) It is also not a legacy or mini filter ( since it is not attaching nor
> having notification mechanism for any future fs ).
>
> When noone is logged on ( from the users point of view), I see a whole lot
> of paging i/o for write comes from mapped-writer thread.
>
> Now my question is eventhough it is not registered as an FS, why am I
> getting this?
>
> Next question is what could possibly go wrong if this paging write i/o’s
> are returned w/out further processing ( i.e anything but STATUS_SUCCESS).
> I’m worried if it could keep the system from going to totally standby mode
> and it could possibly cause damage to laptop.
>
> Also is it possible that the mapped-writer keep trying the same thing? In
> fact, I did not probe all the possible fields to make sure if it is the
> same request being tried over and over again, since otherwise it is not
> causing problems.
>
> Finally I’ve a filter running in there too ( basically fsfilter) and it is
> not hitting there as was expected from mapped-writer ( if I understand
> it).
>
> And what causes such an activity?
>
> thanks
> -pro
>
>
In addition to " MmProbeAndLockPages with Modify or Write access mode", I
meant, for example, the case than driver receives an MDL created by the
Memory Manger, then maps this MDL, creates new MDL for the mapped buffer and
calls MmProbeAndLockPages, it is illegal. Using MmProbeAndLockPages for
user’s buffers is legal.
–
Slava Imameyev, xxxxx@hotmail.com
“Slava Imameyev” wrote in message news:xxxxx@ntfsd…
>> Now my question is eventhough it is not registered as an FS, why am I
>> getting this?
>
> Why does this baffle you? It is normal for FSDs( even not registered by
> IoRegisterFileSystem ) to receive requests from the system.
>
>> Next question is what could possibly go wrong if this paging write i/o’s
>> are returned w/out further processing ( i.e anything but STATUS_SUCCESS).
>
> If you return STATUS_SUCCESS nothing goes wrong except data lost.
> If you don’t return STATUS_SUCCESS then the behavior depends on the status
> code and FSD type( network FSD or not ) for some codes the attempt will be
> repeated for others the “Write Failled” message will be popped up.
>
>> And what causes such an activity?
>
> Do you mean a lot of write requests from MapPW while a file has not been
> modified by any application?
> If yes, then check the read routine, there is a bug which results in a
> dirty flag changing for page frame descriptors, the most common error is
> MmProbeAndLockPages with Modify or Write access mode.
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> wrote in message news:xxxxx@ntfsd…
>> This is more of an internal question, and I’m not at a point with full
>> investigation yet, but in case someone could shed some light on it.
>>
>> 1)There is a top level driver ( mimicking some file system driver), but
>> it
>> does not use the IoRegisterFileSystem(). This driver provides all the
>> callbacks for -
>> AcquireForLazyWrite
>> ReleaseFromLazyWrite
>> AcquireForReadAhead
>> ReleaseFromReadAhead
>>
>> and of course for fastio dispatches.
>>
>> 2) It is also not a legacy or mini filter ( since it is not attaching nor
>> having notification mechanism for any future fs ).
>>
>> When noone is logged on ( from the users point of view), I see a whole
>> lot
>> of paging i/o for write comes from mapped-writer thread.
>>
>> Now my question is eventhough it is not registered as an FS, why am I
>> getting this?
>>
>> Next question is what could possibly go wrong if this paging write i/o’s
>> are returned w/out further processing ( i.e anything but STATUS_SUCCESS).
>> I’m worried if it could keep the system from going to totally standby
>> mode
>> and it could possibly cause damage to laptop.
>>
>> Also is it possible that the mapped-writer keep trying the same thing? In
>> fact, I did not probe all the possible fields to make sure if it is the
>> same request being tried over and over again, since otherwise it is not
>> causing problems.
>>
>> Finally I’ve a filter running in there too ( basically fsfilter) and it
>> is
>> not hitting there as was expected from mapped-writer ( if I understand
>> it).
>>
>> And what causes such an activity?
>>
>> thanks
>> -pro
>>
>>
>
>
>
Thanks to both of you ( Max and Slava).
Comment/answere embedded -
-pro
On 5/11/07, Slava Imameyev wrote:
> Now my question is eventhough it is not registered as an FS, why am I
> getting this?
Why does this baffle you? It is normal for FSDs( even not registered by
IoRegisterFileSystem ) to receive requests from the system.
My understanding was that MapPW will go directly to the fsd that was
registered as such.
> Next question is what could possibly go wrong if this paging write i/o’s
> are returned w/out further processing ( i.e anything but STATUS_SUCCESS).
If you return STATUS_SUCCESS nothing goes wrong except data lost.
If you don’t return STATUS_SUCCESS then the behavior depends on the status
code and FSD type( network FSD or not ) for some codes the attempt will be
repeated for others the “Write Failled” message will be popped up.
No I don’t get Write Failed, and it is not a network fsd by the std
windows filesystems. But by behavior it is a network file system in the
sense is that data is located remotely.
It is an old fs ( went thru many hands !). It basically try to go to a
dormant state when every user is logged off. When it is in dormant state,
I’ve been seeing this. Logback on as any user login, I don’t see it
anymore. So this could be the problem!. I will check back the read path.
It’s direct client is a file spoofer ( filter driver), and that goes to
dormant state ( essentially becomes a passthru when every user is logged
off), and no activity is there since I’ve activated traces.
I was thinking to obey the requests ( while in dormant state) by checking
if it is indeed a paging i/o request, but I need to understand the cause
of it being happening … By not obeying ( as it is now), I don’t see any
direct problem but it could lead to some bad side effect !!!
-pro
> In addition to " MmProbeAndLockPages with Modify or Write access mode", I
> meant, for example, the case than driver receives an MDL created by the
> Memory Manger, then maps this MDL, creates new MDL for the mapped buffer
> and
> calls MmProbeAndLockPages, it is illegal. Using MmProbeAndLockPages for
> user’s buffers is legal.
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> “Slava Imameyev” wrote in message
> news:xxxxx@ntfsd…
>>> Now my question is eventhough it is not registered as an FS, why am I
>>> getting this?
>>
>> Why does this baffle you? It is normal for FSDs( even not registered by
>> IoRegisterFileSystem ) to receive requests from the system.
>>
>>> Next question is what could possibly go wrong if this paging write
>>> i/o’s
>>> are returned w/out further processing ( i.e anything but
>>> STATUS_SUCCESS).
>>
>> If you return STATUS_SUCCESS nothing goes wrong except data lost.
>> If you don’t return STATUS_SUCCESS then the behavior depends on the
>> status
>> code and FSD type( network FSD or not ) for some codes the attempt will
>> be
>> repeated for others the “Write Failled” message will be popped up.
>>
>>> And what causes such an activity?
>>
>> Do you mean a lot of write requests from MapPW while a file has not been
>> modified by any application?
>> If yes, then check the read routine, there is a bug which results in a
>> dirty flag changing for page frame descriptors, the most common error
>> is
>> MmProbeAndLockPages with Modify or Write access mode.
>>
>> –
>> Slava Imameyev, xxxxx@hotmail.com
>>
>>
>> wrote in message news:xxxxx@ntfsd…
>>> This is more of an internal question, and I’m not at a point with full
>>> investigation yet, but in case someone could shed some light on it.
>>>
>>> 1)There is a top level driver ( mimicking some file system driver), but
>>> it
>>> does not use the IoRegisterFileSystem(). This driver provides all the
>>> callbacks for -
>>> AcquireForLazyWrite
>>> ReleaseFromLazyWrite
>>> AcquireForReadAhead
>>> ReleaseFromReadAhead
>>>
>>> and of course for fastio dispatches.
>>>
>>> 2) It is also not a legacy or mini filter ( since it is not attaching
>>> nor
>>> having notification mechanism for any future fs ).
>>>
>>> When noone is logged on ( from the users point of view), I see a whole
>>> lot
>>> of paging i/o for write comes from mapped-writer thread.
>>>
>>> Now my question is eventhough it is not registered as an FS, why am I
>>> getting this?
>>>
>>> Next question is what could possibly go wrong if this paging write
>>> i/o’s
>>> are returned w/out further processing ( i.e anything but
>>> STATUS_SUCCESS).
>>> I’m worried if it could keep the system from going to totally standby
>>> mode
>>> and it could possibly cause damage to laptop.
>>>
>>> Also is it possible that the mapped-writer keep trying the same thing?
>>> In
>>> fact, I did not probe all the possible fields to make sure if it is the
>>> same request being tried over and over again, since otherwise it is not
>>> causing problems.
>>>
>>> Finally I’ve a filter running in there too ( basically fsfilter) and it
>>> is
>>> not hitting there as was expected from mapped-writer ( if I understand
>>> it).
>>>
>>> And what causes such an activity?
>>>
>>> thanks
>>> -pro
>>>
>>>
>>
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Okay, now I see the side effect ( after letting it run that way overnight).
The side effect is that the icons for user login are gone. Just the
background bitmap is there. No place to logback in. Atl+cntl+del does not
do anything. The system is not locked though.
Now it make sense to tackle this…
-pro
Thanks to both of you ( Max and Slava).
Comment/answere embedded -
-pro
On 5/11/07, Slava Imameyev wrote:
>> Now my question is eventhough it is not registered as an FS, why am I
>> getting this?
>
> Why does this baffle you? It is normal for FSDs( even not registered by
> IoRegisterFileSystem ) to receive requests from the system.
>
> My understanding was that MapPW will go directly to the fsd that was
> registered as such.
>
>
>
>> Next question is what could possibly go wrong if this paging write i/o’s
>> are returned w/out further processing ( i.e anything but
>> STATUS_SUCCESS).
>
> If you return STATUS_SUCCESS nothing goes wrong except data lost.
> If you don’t return STATUS_SUCCESS then the behavior depends on the status
> code and FSD type( network FSD or not ) for some codes the attempt will be
> repeated for others the “Write Failled” message will be popped up.
>
> No I don’t get Write Failed, and it is not a network fsd by the std
> windows filesystems. But by behavior it is a network file system in the
> sense is that data is located remotely.
>
> It is an old fs ( went thru many hands !). It basically try to go to a
> dormant state when every user is logged off. When it is in dormant state,
> I’ve been seeing this. Logback on as any user login, I don’t see it
> anymore. So this could be the problem!. I will check back the read path.
>
> It’s direct client is a file spoofer ( filter driver), and that goes to
> dormant state ( essentially becomes a passthru when every user is logged
> off), and no activity is there since I’ve activated traces.
>
> I was thinking to obey the requests ( while in dormant state) by checking
> if it is indeed a paging i/o request, but I need to understand the cause
> of it being happening … By not obeying ( as it is now), I don’t see any
> direct problem but it could lead to some bad side effect !!!
>
>
> -pro
>
>
>
>
>> In addition to " MmProbeAndLockPages with Modify or Write access mode",
>> I
>> meant, for example, the case than driver receives an MDL created by the
>> Memory Manger, then maps this MDL, creates new MDL for the mapped buffer
>> and
>> calls MmProbeAndLockPages, it is illegal. Using MmProbeAndLockPages for
>> user’s buffers is legal.
>>
>> –
>> Slava Imameyev, xxxxx@hotmail.com
>>
>>
>> “Slava Imameyev” wrote in message
>> news:xxxxx@ntfsd…
>>>> Now my question is eventhough it is not registered as an FS, why am I
>>>> getting this?
>>>
>>> Why does this baffle you? It is normal for FSDs( even not registered by
>>> IoRegisterFileSystem ) to receive requests from the system.
>>>
>>>> Next question is what could possibly go wrong if this paging write
>>>> i/o’s
>>>> are returned w/out further processing ( i.e anything but
>>>> STATUS_SUCCESS).
>>>
>>> If you return STATUS_SUCCESS nothing goes wrong except data lost.
>>> If you don’t return STATUS_SUCCESS then the behavior depends on the
>>> status
>>> code and FSD type( network FSD or not ) for some codes the attempt will
>>> be
>>> repeated for others the “Write Failled” message will be popped up.
>>>
>>>> And what causes such an activity?
>>>
>>> Do you mean a lot of write requests from MapPW while a file has not
>>> been
>>> modified by any application?
>>> If yes, then check the read routine, there is a bug which results in a
>>> dirty flag changing for page frame descriptors, the most common error
>>> is
>>> MmProbeAndLockPages with Modify or Write access mode.
>>>
>>> –
>>> Slava Imameyev, xxxxx@hotmail.com
>>>
>>>
>>> wrote in message news:xxxxx@ntfsd…
>>>> This is more of an internal question, and I’m not at a point with full
>>>> investigation yet, but in case someone could shed some light on it.
>>>>
>>>> 1)There is a top level driver ( mimicking some file system driver),
>>>> but
>>>> it
>>>> does not use the IoRegisterFileSystem(). This driver provides all the
>>>> callbacks for -
>>>> AcquireForLazyWrite
>>>> ReleaseFromLazyWrite
>>>> AcquireForReadAhead
>>>> ReleaseFromReadAhead
>>>>
>>>> and of course for fastio dispatches.
>>>>
>>>> 2) It is also not a legacy or mini filter ( since it is not attaching
>>>> nor
>>>> having notification mechanism for any future fs ).
>>>>
>>>> When noone is logged on ( from the users point of view), I see a whole
>>>> lot
>>>> of paging i/o for write comes from mapped-writer thread.
>>>>
>>>> Now my question is eventhough it is not registered as an FS, why am I
>>>> getting this?
>>>>
>>>> Next question is what could possibly go wrong if this paging write
>>>> i/o’s
>>>> are returned w/out further processing ( i.e anything but
>>>> STATUS_SUCCESS).
>>>> I’m worried if it could keep the system from going to totally standby
>>>> mode
>>>> and it could possibly cause damage to laptop.
>>>>
>>>> Also is it possible that the mapped-writer keep trying the same thing?
>>>> In
>>>> fact, I did not probe all the possible fields to make sure if it is
>>>> the
>>>> same request being tried over and over again, since otherwise it is
>>>> not
>>>> causing problems.
>>>>
>>>> Finally I’ve a filter running in there too ( basically fsfilter) and
>>>> it
>>>> is
>>>> not hitting there as was expected from mapped-writer ( if I understand
>>>> it).
>>>>
>>>> And what causes such an activity?
>>>>
>>>> thanks
>>>> -pro
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@garlic.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@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>