Handle call to FlushFileBuffers in UMDF driver

[Andre]

Hi,

I have a UMDF driver which creates a virtual serial COM port. An
application, which calls FlushFileBuffers with a handle to this COM port,
receives error 50, which indicates that this request is not supported. The
driver for the normal COM port, however, supports a call to FlushFileBuffers,
at least this call does not fail. In the KMDF serial port driver example one
can find that it handles IRP_MJ_FLUSH_BUFFERS. So I guess I need to implement
the corresponding interface in UMDF. However, I was not able to find it.
Which interface must be implemented to handle IRP_MJ_FLUSH_BUFFERS.

Thanks for any suggestions and best regards,
Andre

[Doron Holan [MSFT]]

cannot be done in UMDF, the kernel mode reflector does not reflect flush
buffers into the user mode driver host

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Andre" <An...@discussions.microsoft.com> wrote in message
news:6B90D442-13E4-4700...@microsoft.com...

[Andre]

Hi,

I tried to work around this UMDF restriction. At this I am using a KMDF
lower filter driver, which is supposed to handle the IRP_MJ_FLUSH_BUFFERS. In
the FilterEvtDeviceAdd function I have registered an IRP preprocess callback
like it is done in the KMDF serial sample:

status = WdfDeviceInitAssignWdmIrpPreprocessCallback(DeviceInit,
SerialFlush, IRP_MJ_FLUSH_BUFFERS, NULL, 0);

The return status is OK. However, the registered callback is never called. I
have used IrpTracker (from OSR) which indicates that the FLUSH_BUFFERS IRP is
completed by \Driver\WudfRd with completion status "NOT_SUPPORTED". In the
book "Developing Drivers with the WDF" (P. Orwick, G. Smith, page 503) I
found the information that the reflector passes IRPs of unsupported type to
the next-lower driver in the kernel-mode device stack.

So why does the reflector complete the IRP instead of passing it to the
filter driver?

Thanks and best regards,
Andre

[Maxim S. Shatskih]

Use some IOCTL instead of flush buffers.

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

"Andre" <An...@discussions.microsoft.com> wrote in message

news:A5284E93-E0C3-46F7...@microsoft.com...

[Doron Holan [MSFT]]

he can't, this a well known semantic on com ports and this will come from
any app which uses a com port. i would bet that you need to filter above
the reflector to see the flush.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:uRL0H1Ck...@TK2MSFTNGP06.phx.gbl...

[Andre]

Is this possible, I mean to set a filter driver above the reflector? As far
as I remember the WDK documentation mentions that the reflector must be on
top of the kernel mode device stack.

Does the reflector not pass IRPs with unsupported type down to the next
lower driver?

Regards,

[Doron Holan [MSFT]]

hmm, i forgot that the reflector really wants to be on top. if you are not
seeing the flush irp, i would guess the reflector is not fwd'ing them down

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Andre" <An...@discussions.microsoft.com> wrote in message

news:E4055B6F-B458-4F03...@microsoft.com...

[Andre]

Can you confirm that the reflector does not forward the flush irp? And if
yes, then wouldn't that be a bug in WudfRd?

When the reflector does not forward the flush irp, then it is impossible to
support the FlushFileBuffers method in a UMDF virtual COM port driver, even
if the device stack contains also a KMDF filter driver below the reflector
which could handle the irp.

I need to support the FlushFileBuffers method. So do you have any other
suggestion how I could achieve this?

[chris.a...@gmail.com]

On Mar 28, 9:14 am, Andre <An...@discussions.microsoft.com> wrote:

> When the reflector does not forward the flush irp, then it is impossible to
> support the FlushFileBuffers method in a UMDF virtual COM port driver, even
> if the device stack contains also a KMDF filter driver below the reflector
> which could handle the irp.

A lot of useful kinds of drivers are impossible in UMDF due to
restrictions that I don't really understand (doesn't support Win2k,
reflector must be on top of the stack, etc.)

If MS wants to drive adoption of UMDF, it might suit them well to
relax or work around these sorts of things, just my humble opinion...

> I need to support the FlushFileBuffers method. So do you have any other
> suggestion how I could achieve this?

Yep, start over in KMDF, sorry...

[Maxim S. Shatskih]

> A lot of useful kinds of drivers are impossible in UMDF due to
> restrictions that I don't really understand (doesn't support Win2k,
> reflector must be on top of the stack, etc.)

...not all IRP_MJ codes supported...

[chris.a...@gmail.com]

On Mar 28, 12:00 pm, "Maxim S. Shatskih" <ma...@storagecraft.com>
wrote:

> > A lot of useful kinds of drivers are impossible in UMDF due to
> > restrictions that I don't really understand (doesn't support Win2k,
> > reflector must be on top of the stack, etc.)
>
> ...not all IRP_MJ codes supported...

Well IRP_MJ_FLUSH_BUFFERS isn't supported by KMDF either, but at least
you can set a preprocess routine to pick it up.

I got the impression that UMDF does not have preprocess routines (I
never looked, admittedly, but I figure someone would have suggested it
by now).