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

Home NTFSD
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/


File System Behavior PDF seems inconsistent about oplock breaks

Fernando_RobertoFernando_Roberto Member - All Emails Posts: 196

Hi all.

File System Behavior Overview - PDF from Microsoft
http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/file system behavior overview.pdf

The documentation contains tables that summarizes the conditions in which oplocks are broken. Everything was going fine until I reached "2.3.2 - IRP_MJ_READ", which is supposed to list the conditions a given oplock would be broken when processing IRP_MJ_READ. However, the first line of this table seems inconsistent for me when it mentions about Level 1 and Batch oplock, saying:

Broken on IRP_MJ_READ when:

  • The read operation occurs on a FILE_OBJECT with a different oplock key from the FILE_OBJECT which owns the oplock.

The question is: How can a IRP_MJ_READ request occur on a different oplock key if an exclusive oplock would break when a IRP_MJ_CREATE happens to get a different oplock key?

From my understanding, the oplock is not broken on IRP_MJ_READ, but on IRP_MJ_CREATE.

What am I missing?

Thanks in advance.


Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,300

    A Level 1 (i.e. Exclusive) oplock won't break on IRP_MJ_CREATE if there is no data access requested. It's possible for a driver to use the resulting File Object for I/O anyway, so that could cause an IRP_MJ_READ to arrive without the break on create.

    Now, I'm not sure if that's the exact or only case this is handling. Usually you just let FsRtlCheckOplock take care of these annoying details for you.

    -scott
    OSR

  • Fernando_RobertoFernando_Roberto Member - All Emails Posts: 196

    Oh... That's a good point of view.

    I was too focused on user-mode point of view and assuming a driver doing such a thing would be "breaking the rules", but it is perfectly possible.

    I'm creating a test application for oplock implementation, that will be used on a layered file system we have over here. Now I'm assuming this test application must have a kernel component to create the scenario you described.

    Does anyone know if the HLK test uses a kernel driver to test this?

    Thanks for your help!


    Fernando Roberto da Silva
    DriverEntry Kernel Development
    http://www.driverentry.com.br

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,300

    It's common enough that everyone should assume you can get reads/writes on a File Object opened without data access. Some filters even try to "play nice" and set the ReadAccess/WriteAccess fields to TRUE before sending down the I/O, which can be a mess if you're relying on these fields properly reflecting the open flags.

    The oplock tests use a minifilter but I'm not entirely sure what it does. I wouldn't be surprised if they catch this case (those tests are incredibly comprehensive).

    -scott
    OSR

  • Fernando_RobertoFernando_Roberto Member - All Emails Posts: 196

    I just saw it on the Oplock Test page below:
    https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/3d717052-7804-4de7-b097-a5e30b6bb7e5

    There is an Opkey.sys on the list of files used on this test.

    Many thanks!


    Fernando Roberto da Silva
    DriverEntry Kernel Development
    http://www.driverentry.com.br

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA