Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Clarify WdfRequestRetrieveIn/OutputBuffer gives same buffer address?

DriverThomasDriverThomas Member Posts: 14

Hi,

during debugging I've experienced that the pairs WdfRequestRetrieveIn/OutputBuffer retrieve the same buffer's address. Which confuses me.
Im calling these one after the other during handling an ioctl within a queue using buffered I/O.

Side effect is e.g. when zeroing out the output buffer, the information from the input buffer is lost, too...

Is this intended? Or am I doing sth. wrong?

Thanks, Thomas

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718

    By design. Input and output are the same buffer in buffered IO (type 3), see

    https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/defining-i-o-control-codes
    https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/buffer-descriptions-for-i-o-control-codes

    What are you doing wrong? You should validate and capture all of the input buffer locally before touching the output buffer.

    d
  • DriverThomasDriverThomas Member Posts: 14

    Thank you very much. Ive simply overlooked that. It is explicit described in your second link. So the naming (RetrieveIn/OutputBuffer) is actually misleading. At least for buffered I/O. With knowing that handling of this behaviour is easy, though.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,403

    It's not misleading. If you want to read data coming IN, use InputBuffer. If you want to send data out, use OutputBuffer. That way, should you ever need to change the buffering in the future, it will work.

    Side note, this has ALWAYS been true for METHOD_BUFFERED ioctls. KMDF makes it easier to forget this and overwrite your input data.

    Actually, I will retract my comment that it's not misleading. The names "input buffer" and "output buffer" have always been misleading. They should have been called "buffer 1" and "buffer 2" from the beginning. Nothing in the ioctl mechanism enforces a direction on either one.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,575

    The confusion is over the fact that the 'input' and 'output' buffers are in fact the same buffer. That confusion has been present since the initial release of NT and likely goes back to its DEC VMS predecessor. It is blindingly easy to miss the fact that it is the same buffer. Just to further confuse things, UMDF undoes this and provides two buffers. (Arguably KMDF ought to do this as well.)

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Writing WDF Drivers TBD 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online