RE: Right value to return in a dispatch function of a hard disk filter driver when MmGetSy

Don’t worry, Mark. I think I didn’t make it clear. Following with your
references to WHQL, what are the correct tests for a driver of this kind (a
hard disk class filter driver)? We are studying which could be the best
certification for that driver and we still have doubts. We have another
similar drivers (class filter drivers), a FSFD (I guess the right
cetification is “Antivirus/File system filter driver”) and I driver which
hooks system service dispatch table. Could you give some advice around the
best tests for certify them?

Thanks in advance,

Jose Vicente.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Roddy, Mark
Enviado el: lunes, 01 de diciembre de 2003 19:10
Para: Windows System Software Devs Interest List
Asunto: [ntdev] RE: Right value to return in a dispatch function of a hard
disk filter driver when MmGetSystemAddressForMdlSafe fails

Ah my mistake, I just noticed that you are trying to do this in w2k. There
is no documented way to do the same thing. I think the best you can do in
w2k is to retry in a worker thread and hope your retry succeeds before the
paging request times out and fails. I do not believe that w2k whql will
catch this, and as the documented solution is not available in w2k, I’d
argue that you do not have to fix this in w2k.

=====================
Mark Roddy

-----Original Message-----
From: Jos? Vicente S?nchez Ortega [mailto:xxxxx@secuware.com]
Sent: Monday, December 01, 2003 12:52 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: Right value to return in a dispatch
function of a hard disk filter driver when
MmGetSystemAddressForMdlSafe fails

Forgive me for being so insistent but, how can I acomplish
this task in ***W2K***? (I understand that, in WXP, I can use
the functions that Henry Gabryjelski mentioned)

Thanks in advance.

Jose Vicente.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Roddy, Mark
Enviado el: lunes, 01 de diciembre de 2003 18:21
Para: Windows System Software Devs Interest List
Asunto: [ntdev] RE: Right value to return in a dispatch
function of a hard disk filter driver when
MmGetSystemAddressForMdlSafe fails

Re-read the original reply. MmGetSystemAddressForMdlSafe is
an allocation request for system PTEs.
MmAllocateMappingAddress and
MmMapLockedPagesWithReservedMapping can help here. They are
XP and later however.

=====================
Mark Roddy

> -----Original Message-----
> From: Jos? Vicente S?nchez Ortega [mailto:xxxxx@secuware.com]
> Sent: Monday, December 01, 2003 11:56 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] RE: Right value to return in a dispatch
function of a
> hard disk filter driver when MmGetSystemAddressForMdlSafe fails
>
> Thank you very much for your answer. I use a pre-allocated
memory pool
> in my driver in order to avoid memory allocation problems in low
> resource situations but, as I mentioned, the function which
fails is
> MmGetSystemAddressForMdlSafe not an allocation function.
The problem
> is that if this function fails, I don’t know how to map
user buffer in
> order to manipulate it as I need. I can use the set of
functions which
> you have mentioned but I still will have a problem in W2K (since my
> driver must work in that platform too) In W2K, I can pre-allocate a
> memory pool too but, how can I acomplish the task of
reserve a virtual
> address mapping range to ensure that I will always able to
map the MDL
> I receive?
>
> Best regards,
>
>
> Jose Vicente.
>
>
>
> -----Mensaje original-----
> De: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] En nombre de Henry
> Gabryjelski Enviado el: s?bado, 29 de noviembre de 2003 19:10
> Para: Windows System Software Devs Interest List
> Asunto: [ntdev] RE: Right value to return in a dispatch
function of a
> hard disk filter driver when MmGetSystemAddressForMdlSafe fails
>
>
> Unfortunately, your filter driver is now causing data corruption.
> That message means that some data which the user thinks is properly
> written was not. There is very little chance you can determine what
> data that is after the fact, and the original writer of that data is
> likely gone, so it cannot be recreated.
>
> This is why such a huge emphasis on forward progress guarantee was
> made in the storage stack for Windows XP/WS03.
> Paging requests are guaranteed never to fail due to
> insufficient resource in a “stock” Windows XP installation
> (no 3rd party stuff). The port drivers ensure they can
> handle a single-page request without resources, the class
> drivers (disk, cdrom) ensure they can handle any size request
> without resources (even if they have to pend the IO), and the
> memory manager retries paging requests that fail with
> out-of-memory errors as single-page requests.
>
> If you can find a way to prevent disk IO from failing (by
> pre-allocating in
> StartDevice() enough memory to handle a single request, and
> then serializing as needed when out-of-memory occurs). When
> using the pre-allocated request resources, use a
> pre-allocated mapping address too:
>
> MmAllocateMappingAddress() allows you to reserve a range of virtual
> address space to use in out-of-memory conditions when you absolutely
> must not fail IO, such as disk IO (WinXP and later); use the related
> functions MmMapLockedPagesWithReservedMapping(),
> MmUnmapReservedMapping(), and
> MmFreeMappingAddress() to finish the job. Please use this
> sparingly, as virtual address space is limited on 32 bit machines.
>
> This does require adding some more logic attached to each request
> you handle in the completion routine: Was the request using the
> preallocated resources? If so, you must unmap the reserved mapping
> and then check if anything else was queued to use the preallocated
> resources.
> Of course, checking the queue and leaving the preallocated
> resources for the next person requires appropriate
> synchronization (just use a spinlock – you’re already in a
> low-memory condition, so perf isn’t key).
>
> I encourage you to go that last mile to really make your driver 100%
> reliable. Data corruption is a very bad thing for customers, and
> out-of-memory conditions really do occur in the real world. (mostly
> due to drivers leaking memory, but I’ve seen at least two other
> causes in heavy loads).
>
> Good luck!
> .
>
> -----Original Message-----
> From: Nick Ryan [mailto:xxxxx@nryan.com]
> Sent: Friday, November 28, 2003 12:14 PM
> Subject: Re: Right value to return in a dispatch function of a hard
> disk filter driver when MmGetSystemAddressForMdlSafe fails
>
> No, you’re doing the correct thing. The lazy writer is attempting to
> push out dirty data from the filesystem cache to disk, and the
> paging writes are failing because of your driver. Everything is
> behaving as it should under this simulated error condition.
>
> Jos? Vicente S?nchez Ortega wrote:
>
> > Hello,
> >
> > I have developed a filter driver for hard disk class and, when I
> > activate Driver Verifier to test it (enabling the “inject faults”
> > option) I see that, for example, the function
> > MmGetSystemAddressForMdlSafe fails repeatedly when I call
it in my
> > READ and WRITE dispatch functions to map the the buffer. I’m
> > completing the IRP in that case with
STATUS_INSUFFICIENT_RESOURCES.
> > Some times, the system shows a message informing me that
the lazzy
> > writer was unable to READ/WRITE data (and the file name)
I have not
> > seen any secondary effect but I would like to know if it is
> possible
> > to return another status code or do a different process to
> avoid this
> > error (in any case the error message appears only when I
run Driver
> > Verifier)
> >
> > Thanks in advance,
> >
> >
> > Jose Vicente.
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@secuware.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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