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/


SCCD confusion/errors

Jason_T.Jason_T. Member Posts: 78

I'm trying to test sending a driver an ioctl via a UWP app. Per multiple references this requires a custom capability. I have added these lines to my driver's INF:

[Foo.NT.Interfaces]
AddInterface="{%GUID_DEVINTERFACE_FOO%}", , FooAddInterface

[FooAddInterface]
AddProperty=FooAddInterface.AddProps

[FooAddInterface.AddProps]
{%DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities%}, 8, 0x2012,, %CustomCapability%

[Strings]
GUID_DEVINTERFACE_FOO="705791F3-E013-45A8-827B-80F4020B5F21" ; This is my device interface as registered by IoRegisterDeviceInterface
DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities="026e516e-b814-414b-83cd-856d6fef4822" ; This seems to be some magic guid value
CustomCapability="microsoft.hsaTestCustomCapability_q536wpkpf5cy2" ; Borrowing this verbatim from the MS sample

Note that I'm doing this via the INF since my driver is a WDM driver and I didn't see a way to add the custom capability property to the interface outside of kmdf-land.

In my UWP app I have added an SCCD:

<?xml version="1.0" encoding="utf-8"?>









0000

Upon deployment, I get the error:

Severity Code Description Project File Line Suppression State
Error DEP8000 : Unexpected deployment failure : RemoteCommandException : error 0x800701C8: While preparing to process the request, the system failed to register the windows.capability extension due to the following error: The custom capability's SCCD has an invalid catalog.

.

0x800701c8

I cannot find a single word of documentation on what the Catalog element of the CustomCapabilityDescriptor is supposed to be. I have found MS samples that have it set to both "0000" and "xxxx" but both of those generate this same error.

Furthermore, I'm guessing that even if I get past this error I'll hit an issue with the AppPackageFamilyName, but if I change that name then the sig hash will be wrong, right? I know 1809 added the "allow all" but as far as I can tell 1803 is the latest released version for my target (dragonboard 410c). I really just want to try to test this proof of concept (to see if I can send an IOCTL to my device from a UWP app) on a single developer box, but this has burned a few days of time at this point. Anybody have any tips?

-JT

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,048

    Doesn’t this stuff need to be signed/blessed by MSFT to be able to work?

    ISTR that was the “fly in the ointment” for this when I last looked into it.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Jason_T.Jason_T. Member Posts: 78

    Thanks for replying. I certainly can't say anything authoritatively, but the docs here seem to suggest that you can use an option to DIY it until you get the real one:

    "For testing purposes, a custom capability owner can restrict installation of a hardware support app to computers in developer mode.

    To do so, before getting the SCCD signed by Microsoft, add DeveloperModeOnly"

    Now re-reading that again I suppose it's possible they are meaning that I still need to get it signed, but I just need to add that tag prior to the signing. My original interpretation was that with this tag it didn't need to be signed. I suppose I'll have to email MS to see how to proceed.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,518
    via Email
    Look at the sccd sdk sample. It has the necessary appx manifest changes you can base your changes off of. Before you have a signed sccd file you can turn on developer mode (in settings) before you deploy the app. This will indicate to the deployment stack to accept an unsigned sccd.

    d

    Bent from my phone
    ________________________________
    From: Jason_T.
    Sent: Saturday, November 3, 2018 7:17:09 AM
    To: Doron Holan
    Subject: Re: [NTDEV] SCCD confusion/errors

    OSR https://na01.safelinks.protection.outlook.com/?url=https://community.osr.com/&amp;data=02|01|[email protected]|dc21cb6f126c4961bdf708d641970b2c|72f988bf86f141af91ab2d7cd011db47|1|0|636768514311516973&amp;sdata=aKGTxCCE5KIOVlEYL8mUjY4QASKMs74epJoCUcSYlWA=&amp;reserved=0
    Jason_T. commented on SCCD confusion/errors

    Thanks for replying. I certainly can't say anything authoritatively, but the docs here seem to suggest that you can use an option to DIY it until you get the real one:

    "For testing purposes, a custom capability owner can restrict installation of a hardware support app to computers in developer mode.

    To do so, before getting the SCCD signed by Microsoft, add DeveloperModeOnly"

    Now re-reading that again I suppose it's possible they are meaning that I still need to get it signed, but I just need to add that tag prior to the signing. My original interpretation was that with this tag it didn't need to be signed. I suppose I'll have to email MS to see how to proceed.
    d
  • Jason_T.Jason_T. Member Posts: 78
    edited November 2018

    Hi Doron,

    Thank you for replying. My SCCD is verbatim from the SDK sample, with the single addition of the <DeveloperModeOnly Value="true"/> tag. I also have developer mode turned on on my dev machine which is the source of the deploy (but the target of the deploy is an IoT core machine and I have not found an explicit way to enable developer mode on that, if this is required?)

    In any case, the deploy always fails seemingly due to a catalog issue:

    "Severity Code Description Project File Line Suppression State
    Error DEP8000 : Unexpected deployment failure : RemoteCommandException : error 0x800701C8: While preparing to process the request, the system failed to register the windows.capability extension due to the following error: The custom capability's SCCD has an invalid catalog.

    0x800701c8"

    I have tried the values 0000, xxxx and FFFF for the <Catalog> tag, all of which are found in various MS examples and documentation, but all of which result in the same 'invalid catalog' error.

    Any ideas?

    Thanks!
    -JT

    Post edited by Jason_T. on
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,518
    via Email
    I think only desktop allows an sccd which is not officially signed to work in developer mode. IOW I don
    d
  • sam_msftsam_msft Member Posts: 1

    @Doron_Holan said:
    I think only desktop allows an sccd which is not officially signed to work in developer mode. IOW I don

    Yes, this is generally correct. If you are in developer mode on a desktop based SKU, then they signing checks are skipped.

    @Jason_T. said:

    Thank you for replying. My SCCD is verbatim from the SDK sample, with the single addition of the <DeveloperModeOnly Value="true"/> tag. I also have developer mode turned on on my dev machine which is the source of the deploy (but the target of the deploy is an IoT core machine and I have not found an explicit way to enable developer mode on that, if this is required?)

    FYI, DeveloperModeOnly means the machine must be in developer mode and applies to desktop SKUs, so it is not doing what you want.

    So, since you are deploying to an IoT SKU, the SCCD file must actually be signed. The catalog is embedded into the SCCD in the catalog element.

    This doc talks about how to use custom capabilities, but the important thing is to email your SCCD file to ([email protected]), and request to to have it signed. The process isn't too difficult.

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!
Internals & Software Drivers 30 Nov 2020 LIVE ONLINE
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Developing Minifilters Early 2021 LIVE ONLINE