Andre
Fri Mar 28 09:14:00 CDT 2008
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?
Thanks and best regards,
Andre
"Doron Holan [MSFT]" wrote:
> 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" <Andre@discussions.microsoft.com> wrote in message
> news:E4055B6F-B458-4F03-8F7E-3B1E19A507ED@microsoft.com...
> > 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,
> > Andre
> >
> >
> > "Doron Holan [MSFT]" wrote:
> >
> >> 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" <maxim@storagecraft.com> wrote in message
> >> news:uRL0H1CkIHA.1132@TK2MSFTNGP06.phx.gbl...
> >> > Use some IOCTL instead of flush buffers.
> >> >
> >> > --
> >> > Maxim Shatskih, Windows DDK MVP
> >> > StorageCraft Corporation
> >> > maxim@storagecraft.com
> >> >
http://www.storagecraft.com
> >> >
> >> > "Andre" <Andre@discussions.microsoft.com> wrote in message
> >> > news:A5284E93-E0C3-46F7-9FF7-CEB3DECE951E@microsoft.com...
> >> >> 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
> >> >>
> >> >>
> >> >> "Doron Holan [MSFT]" wrote:
> >> >>
> >> >> > 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" <Andre@discussions.microsoft.com> wrote in message
> >> >> > news:6B90D442-13E4-4700-929D-E8BBF2CC3DB9@microsoft.com...
> >> >> > > 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
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> >
> >> >> >
> >> >
> >>
> >>
>
>