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/


UWP and accessing driver

makrurisan_makkelnmakrurisan_makkeln Member - All Emails Posts: 99
How do we access a driver under UWP. I couldnt find something like DeviceIoControl under WinRT.
Is the APi below the right one for Win10?
Device Access API
https://msdn.microsoft.com/en-us/library/windows/desktop/hh404235(v=vs.85).aspx

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,490
    You don't want to use metadata or privileged apps. You want to use a custom capability and access it through Windows.devices.custom. See https://docs.microsoft.com/en-us/windows-hardware/drivers/devapps/hardware-support-app--hsa--steps-for-driver-developers.

    Bent from my phone
    ________________________________
    From: [email protected] on behalf of [email protected]
    Sent: Tuesday, April 3, 2018 2:28:24 AM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] UWP and accessing driver

    How do we access a driver under UWP. I couldnt find something like DeviceIoControl under WinRT.
    Is the APi below the right one for Win10?
    Device Access API
    https://na01.safelinks.protection.outlook.com/?url=https://msdn.microsoft.com/en-us/library/windows/desktop/hh404235(v=vs.85).aspx&data=02|01|[email protected]|170e888326da42488c4308d599453f48|72f988bf86f141af91ab2d7cd011db47|1|0|636583445050029660&sdata=w/BszI/u8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk=&reserved=0


    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,807
    >How do we access a driver under UWP.

    I *get* that getting rid of random IOCTLs and random interactions with the hardware is a specific goal, not a side-effect... but to me, if I need to ask MSFT permission for every single IOCTL I want to implement for every single customer and every single project (and that's certainly the way I understand it's supposed to work) this is just not going to happen.

    I'd be (grudgingly) willing to jump through the hoops to use a custom capability from a UWP app if I could just generate a GUID and associate it with my Seller ID (or whatever). But asking MSFT's blessing? If that's really how this must work, I just don't see it.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Daniel_Kulas-2Daniel_Kulas-2 Member - All Emails Posts: 12
    "if I need to ask MSFT permission for every single IOCTL I want to
    implement"

    Wait, a custom capability means the ioctl's you expose to a user app?

    On Tue, Apr 3, 2018 at 8:48 AM, [email protected] wrote:

    > >How do we access a driver under UWP.
    >
    > I *get* that getting rid of random IOCTLs and random interactions with the
    > hardware is a specific goal, not a side-effect... but to me, if I need to
    > ask MSFT permission for every single IOCTL I want to implement for every
    > single customer and every single project (and that's certainly the way I
    > understand it's supposed to work) this is just not going to happen.
    >
    > I'd be (grudgingly) willing to jump through the hoops to use a custom
    > capability from a UWP app if I could just generate a GUID and associate it
    > with my Seller ID (or whatever). But asking MSFT's blessing? If that's
    > really how this must work, I just don't see it.
    >
    > Peter
    > OSR
    > @OSRDrivers
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,807
    >Wait, a custom capability means the ioctl's you expose to a user app?

    Well, you understand there ARE no IOCTLs in UWP, right? So, what we USED to do via custom IOCTLs from Win32, we are now get to do via Custom Capabilities in UWP.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,490
    A custom capability describes the security for an object and access to it. It enables access to a driver or an RPC endpoint. It does not control what you once you have access to that resource (specific IOCTLs, RPC calls, etc). I think what Peter is referring to is that

    1. You have to provide a general description of what the custom capability exposes when you ask for the capability
    2. Microsoft must sign the capability file that grants the cap to the application
    d

    From: [email protected] On Behalf Of [email protected]
    Sent: Tuesday, April 3, 2018 2:28 PM
    To: Windows System Software Devs Interest List
    Subject: Re: [ntdev] UWP and accessing driver

    "if I need to ask MSFT permission for every single IOCTL I want to implement"

    Wait, a custom capability means the ioctl's you expose to a user app?

    On Tue, Apr 3, 2018 at 8:48 AM, [email protected] > wrote:
    >How do we access a driver under UWP.

    I *get* that getting rid of random IOCTLs and random interactions with the hardware is a specific goal, not a side-effect... but to me, if I need to ask MSFT permission for every single IOCTL I want to implement for every single customer and every single project (and that's certainly the way I understand it's supposed to work) this is just not going to happen.

    I'd be (grudgingly) willing to jump through the hoops to use a custom capability from a UWP app if I could just generate a GUID and associate it with my Seller ID (or whatever). But asking MSFT's blessing? If that's really how this must work, I just don't see it.

    Peter
    OSR
    @OSRDrivers


    ---
    NTDEV is sponsored by OSR

    Visit the list online at: >

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at >

    To unsubscribe, visit the List Server section of OSR Online at >

    --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
    d
  • Jan_BottorffJan_Bottorff Member - All Emails Posts: 471
    I've read that explanation of custom capabilities, but it seems like it's a pretty poor fit for a pretty common case.

    Let's just take the example of software defined radios. Many SDR hardware devices have an API DLL than follows some public standard format. Win32 applications that want to process data from an SDR just have to call this API, and they work with any hardware. This means neither the hardware vendor nor the application vendor "owns" the API, it's a defacto standard. Frequently, the SDR interface DLL uses USB endpoints internally to talk to the hardware, although they might also have a custom kernel driver that exposes IOCTls. It's basically opaque to the application how the SDR interface works. A number of drivers I've written over the years for unusual hardware also had a user mode interface library, allowing the user-kernel boundary to be private.

    I'd like to understand how the UWP model of things works for these kinds of scenarios? The link referenced below sure seems like it talks about the custom capability being owned by a specific company, who after receiving Microsoft's blessing for the interface, has to grant permission to specific users (developers) of the custom capability.

    This is not just how SDRs work, it's how lots of things work, like for example the NA-VISA instrumentation interface, or the TWAIN scanner interface. The makers of the VISA instrumentation interface would almost certainly not want to expend engineering resources every time somebody wants to write a little application that uses the VISA interface. A HUGE part of Windows is based on interfacing between modules via DLLs, COM objects, and .Net objects. I also believe improving security is a really import goal, which is much of the motivation behind UWP.

    If in UWP it's impossible for different vendors to make modules that interact with each other, though high performance interfaces, many kinds of solutions will just never be UWP apps. I spent some time working on a UWP instrumentation data analysis program, and my experience was writing UWP apps was really painful when you wanted to use any previous interfaces.

    Jan

    From: [email protected] On Behalf Of [email protected]
    Sent: Tuesday, April 3, 2018 7:14 AM
    To: Windows System Software Devs Interest List
    Subject: Re: [ntdev] UWP and accessing driver

    You don't want to use metadata or privileged apps. You want to use a custom capability and access it through Windows.devices.custom. See https://docs.microsoft.com/en-us/windows-hardware/drivers/devapps/hardware-support-app--hsa--steps-for-driver-developers.

    Bent from my phone
    ________________________________
    From: [email protected] > on behalf of [email protected] >
    Sent: Tuesday, April 3, 2018 2:28:24 AM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] UWP and accessing driver

    How do we access a driver under UWP. I couldnt find something like DeviceIoControl under WinRT.
    Is the APi below the right one for Win10?
    Device Access API
    https://na01.safelinks.protection.outlook.com/?url=https://msdn.microsoft.com/en-us/library/windows/desktop/hh404235(v=vs.85).aspx&amp;data=02|01|[email protected]|170e888326da42488c4308d599453f48|72f988bf86f141af91ab2d7cd011db47|1|0|636583445050029660&amp;sdata=w/BszI/u8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk=&amp;reserved=0


    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,490
    It is a gap where you can?t grant access to everyone with a custom cap. We are considering addressing this in a future release.

    d

    Bent from my phone
    ________________________________
    From: [email protected] on behalf of [email protected]
    Sent: Tuesday, April 3, 2018 3:58:10 PM
    To: Windows System Software Devs Interest List
    Subject: RE: [ntdev] UWP and accessing driver

    I?ve read that explanation of custom capabilities, but it seems like it?s a pretty poor fit for a pretty common case.

    Let?s just take the example of software defined radios. Many SDR hardware devices have an API DLL than follows some public standard format. Win32 applications that want to process data from an SDR just have to call this API, and they work with any hardware. This means neither the hardware vendor nor the application vendor ?owns? the API, it?s a defacto standard. Frequently, the SDR interface DLL uses USB endpoints internally to talk to the hardware, although they might also have a custom kernel driver that exposes IOCTls. It?s basically opaque to the application how the SDR interface works. A number of drivers I?ve written over the years for unusual hardware also had a user mode interface library, allowing the user-kernel boundary to be private.

    I?d like to understand how the UWP model of things works for these kinds of scenarios? The link referenced below sure seems like it talks about the custom capability being owned by a specific company, who after receiving Microsoft?s blessing for the interface, has to grant permission to specific users (developers) of the custom capability.

    This is not just how SDRs work, it?s how lots of things work, like for example the NA-VISA instrumentation interface, or the TWAIN scanner interface. The makers of the VISA instrumentation interface would almost certainly not want to expend engineering resources every time somebody wants to write a little application that uses the VISA interface. A HUGE part of Windows is based on interfacing between modules via DLLs, COM objects, and .Net objects. I also believe improving security is a really import goal, which is much of the motivation behind UWP.

    If in UWP it?s impossible for different vendors to make modules that interact with each other, though high performance interfaces, many kinds of solutions will just never be UWP apps. I spent some time working on a UWP instrumentation data analysis program, and my experience was writing UWP apps was really painful when you wanted to use any previous interfaces.

    Jan

    From: [email protected] On Behalf Of [email protected]
    Sent: Tuesday, April 3, 2018 7:14 AM
    To: Windows System Software Devs Interest List
    Subject: Re: [ntdev] UWP and accessing driver

    You don?t want to use metadata or privileged apps. You want to use a custom capability and access it through Windows.devices.custom. See https://docs.microsoft.com/en-us/windows-hardware/drivers/devapps/hardware-support-app--hsa--steps-for-driver-developers.

    Bent from my phone
    ________________________________
    From: [email protected] > on behalf of [email protected] >
    Sent: Tuesday, April 3, 2018 2:28:24 AM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] UWP and accessing driver

    How do we access a driver under UWP. I couldnt find something like DeviceIoControl under WinRT.
    Is the APi below the right one for Win10?
    Device Access API
    https://na01.safelinks.protection.outlook.com/?url=https://msdn.microsoft.com/en-us/library/windows/desktop/hh404235(v=vs.85).aspx&amp;data=02|01|[email protected]|170e888326da42488c4308d599453f48|72f988bf86f141af91ab2d7cd011db47|1|0|636583445050029660&amp;sdata=w/BszI/u8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk=&amp;reserved=0


    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: >

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at >

    To unsubscribe, visit the List Server section of OSR Online at >

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Muthu_KumarMuthu_Kumar Member Posts: 17

    Need MSFT signed SCCD file for "developer mode"?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,807

    Need you resurrect thread that’s over a year old?

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Muthu_KumarMuthu_Kumar Member Posts: 17

    Same subject and some good info are in this thread.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,807
    edited October 2019

    Same subject and some good info are in this thread.

    So, did you not bother to read the Community Guidelines before posting (as it asked folks to do on EVERY PAGE of this site)... or did you think that they didn't apply to you?

    Because I think the rules are pretty clear on this topic:

    There are a number of other behaviors that are considered rules of "good conduct" for posting here on the forums. These include:
    1. Please do not revive "old" threads. Until we have the ability to block posts to "dead" (old, outdated) threads, we ask you to not reply to threads where the last post is more than a month old. If you have a comment/question/issue that's raised in a "dead" thread, start a new thread (you can post a link to the old thread if you want) and ask your question there.

    Soooo.... ah....

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Muthu_KumarMuthu_Kumar Member Posts: 17

    ah!. will start a new thread...

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