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

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/


Before Posting...

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

CreateFile error with 1 (connect to my driver)

xwh9315xwh9315 Member Posts: 14

hey,i'm trying to modify KMDOD sample but get some trouble on it.Before DxgkInitializeDisplayOnlyDriver ,i found DxgkDispatchIoRequest,in my opinion, this should be used for IOCTL,so I created the control device and symbolic link in AddDevice,and also registered IRP_MJ_CREATE,IRP_MJ_CLOSE,IRP_MJ_CLEANUP in DriverEntry.But when I use CreateFile to open the symbolic link, it returns error code 1.
I think I can be sure that my code for creating control devices and symbolic links is completely correct (I have some related codes under WDF, but this is my first time to change the code of WDDM).
So, what might cause this error 1 (except for not registering IRP_MJ_CREATE in DriverEntry).
Thanks!

Comments

  • xwh9315xwh9315 Member Posts: 14

    i need help :( thanks

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028
    edited March 9

    DxgkInitializeDisplayOnlyDriver populates all of the dispatch callbacks into itself. All IRPs go first to the port driver, which then dispatches through the KMDDOD_INITIALIZATION_DATA callbacks. The port driver is only going to accept open requests from GDI.

    By the way, it was rude of you to follow up after 10 minutes expecting instant responses. Display drivers are a narrow specialty, and we are all volunteers.

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

  • xwh9315xwh9315 Member Posts: 14

    @Tim_Roberts said:
    DxgkInitializeDisplayOnlyDriver populates all of the dispatch callbacks into itself. All IRPs go first to the port driver, which then dispatches through the KMDDOD_INITIALIZATION_DATA callbacks. The port driver is only going to accept open requests from GDI.

    By the way, it was rude of you to follow up after 10 minutes expecting instant responses. Display drivers are a narrow specialty, and we are all volunteers.

    First of all I am sorry to reply again in ten minutes,It may be simply because I was tortured by this mistake for too long.
    And thanks for your answer,That is to say, KMDOD cannot simply use symbolic links to communicate with applications like ordinary WDM/WDF drivers, can u understand it this way?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

    Yes. Display drivers have always lives in a rather special environment, isolated from the normal driver world.

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

  • xwh9315xwh9315 Member Posts: 14

    @Tim_Roberts said:
    Yes. Display drivers have always lives in a rather special environment, isolated from the normal driver world.

    Thanks for your answer,I would like to ask specifically, if this KMDOD communicates with the application, which callback function should it use? What do I need to know about GDI? Can DXGI's api be used? Thank you!

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

    I have no idea what you mean by "which callback function should it use". Applications do not talk directly to a display driver. As always, there is an abstraction. Applications talk to GDI and Direct3D, and Direct3D talks to the KMDOD. It's exactly like old-style display drivers. When you called BitBlt, you were not talking to the display driver. You were talking to GDI. GDI then translated the parameters and called the display driver(s) on your behalf.

    What are you really trying to do here? What is the overall goal?

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

  • xwh9315xwh9315 Member Posts: 14

    @Tim_Roberts said:
    I have no idea what you mean by "which callback function should it use". Applications do not talk directly to a display driver. As always, there is an abstraction. Applications talk to GDI and Direct3D, and Direct3D talks to the KMDOD. It's exactly like old-style display drivers. When you called BitBlt, you were not talking to the display driver. You were talking to GDI. GDI then translated the parameters and called the display driver(s) on your behalf.

    What are you really trying to do here? What is the overall goal?

    Thanks for your answer。
    My goal is to change the video memory content in KMDOD to a DXGI screenshot image, so I don’t know what I should do. Do you have any good suggestions? According to what you said, should I first use DXGI to take a screenshot and then pass it to KMDOD through D3D's api?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

    Are you talking about implementing VNC kind of thing? Otherwise, I don't get it. You can display a full screen image today without any fancy APIs.

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

  • xwh9315xwh9315 Member Posts: 14

    @Tim_Roberts said:
    Are you talking about implementing VNC kind of thing? Otherwise, I don't get it. You can display a full screen image today without any fancy APIs.

    Haha,yes, I really want to implement a function similar to VNC. To be precise, I want to take a screenshot of the passthrough physical graphics card in a virtual machine. What should I do?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

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

  • xwh9315xwh9315 Member Posts: 14

    Ah,yes。I have completed a complete set of functions for taking screenshots through DXGI, maybe I have neglected and I didn’t notice where I can communicate with the DOD driver?

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!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online