none
NdisMGetDeviceProperty and NdisGetDeviceReservedExtension RRS feed

  • Question

  • Hi All,

    I have to store some device specific information in the funcitonal device object of my NDIS virtual miniport driver. I am not creating any explicit device object in my code.

    To achieve this, i am thinking of using the NdisMGetDeviceProperty() function to get the functional device object and then use NdisGetDeviceReservedExtension() to get device extension from the functional object. 

    NdisMGetDeviceProperty(MiniportDriverHandler, NULL, &Ctx->FDO, NULL, NULL, NULL);

    if (NdisGetDeviceReservedExtension(Ctx->FDO))

        Ctx->FDO->DeviceExtension = Ctx;

    }

    So that i can retrieve the context in the ioctl handler.

    DeviceIoctl()

    {

         Ctx = DeviceObject->DeviceExtension;
    }

    Is this correct approach?

    Thanks,



    • Edited by Boomi.s Thursday, February 13, 2020 6:13 PM
    Thursday, February 13, 2020 6:09 PM

All replies

  • No.

    What is the larger problem that you are trying to solve?

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Thursday, February 13, 2020 6:33 PM
  • Hi Brian,

    What is the problem with my approach. 

    I have to provide some ioctl to the user to register shared memory between user and kernel. In the context structure i am going to keep the MDL related to the user mode addresses as well as some sync object.

    Thursday, February 13, 2020 6:52 PM
  • The problem is that NDIS has already created its own device extension. Instead, you should put your data in your miniport's adapter context structure. That structure is for you to define and you can use it for whatever you want

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Thursday, February 13, 2020 6:56 PM
  • That is my plan. I am storing everything in my miniport adapter context structure. But in the IOCTL call i have to refer this context structure. So that i am thinking of storing in the device object extension. If device object extension is not the right place, where else i can store in order to use it in the IOCTL handler. 

    Thursday, February 13, 2020 7:01 PM
  • The supported mechanism is to use custom OIDs for communicating with an application. When you get the OID, you will also be given the adapter context

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Thursday, February 13, 2020 7:13 PM
  • Yes. Whatever you said is true. And this page https://docs.microsoft.com/en-in/windows-hardware/drivers/network/miniport-adapter-context captures the point. I will get the adapter context whenever NDIS call my miniport functons. But i need the adapter context in my ioctl handler. Can you please provide any sample code available to send custom OID from application to miniport driver.

     
    Thursday, February 13, 2020 7:25 PM
  • Also i see NdisWdfGetAdapterContextFromAdapterHandle() can be used but support for this is available only from Win10.
    Thursday, February 13, 2020 7:32 PM
  • If you insist on using IOCTLs, then call NdisRegisterDeviceEx to create your own device object, and then call NdisGetDeviceReservedExtension to get the device extension that has been set aside for your driver

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    • Proposed as answer by Brian Catlin Thursday, February 13, 2020 7:40 PM
    Thursday, February 13, 2020 7:40 PM
  • Ok Brian. Even i thought the same to have sideband communication with application. I am also thinking of using "FDO->Reserved" member to store the adapter context in order to use in the IOCTL handler. I will have this solution for some time in order to ease the development for now. Any thoughts?
    Thursday, February 13, 2020 7:59 PM
  • Why do you think it would be OK to use a field named "Reserved"? You are not allowed to touch field in any system data structure that is not specifically documented for use by driver writers

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Thursday, February 13, 2020 8:04 PM
  • That is only if you are writing your driver using WDF

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Thursday, February 13, 2020 8:05 PM
  • Even i don't like using the "Reserved" member. What about using "FileObject->FsContext" member. In my virtual NDIS miniport driver code, i will handle IRP_MJ_CREATE call then update the "FileObject->FsContext" with my adapter context. So that in my IOCTL handler i will get reference to this adapter context. This way adapter context will be unique for each instances. Any problem in handling IRP_MJ_CREATE in my virtual miniport driver? 

    The problem with the "NdisRegisterDeviceEx" approach is, there is a user mode library which i can't modify or no access. All i have is the driver code. 

    Thursday, February 13, 2020 8:40 PM
  • Look at using a driver object extension

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Thursday, February 13, 2020 8:49 PM