Root enumerated EV-cert signed driver not loading Win10 1607

I have a root-enumerated (non-PnP) KMDF driver that works as a monitor in conjunction with a 2nd USB driver for the client’s device. This pair has been running fine in Win7, and the client has asked me to migrate this to Win10 1607 for their next gen system, with the understanding of the signing requirements it entails. We have gone ahead and procured an EV cert from DigCert. I build the pair of driver packages with Test Cert under VS 2015 Update 3 / WDK 10.0.15063.0, enable Test Signing on original Win10 target, and all is well.

I then apply the EV cert for Production cert to both packages (disable Test Signing on target, of course), and looking at Setupapi.dev.log, both seem to install fine. However, only the USB driver LOADS, i.e. the noPnP driver never loads/runs. I have applied cross-signing cert, but that driver still does not load. *Installs, yes; loads/runs, no*

Since this is an embedded system that gets delivered to customers fully prepared, we are fine with the “do you trust components from this vendor” prompt for system prep.

FYI, we are applying cert to both .cat & .sys files.

So …

Do we need to take the additional step of submitting that EV-signed driver package to Dev Portal site to get MS blessing for nonPnP driver to load?

Or am I just plain missing something else here?

With all that I thought I knew about Windows device driver development, this one has me stumped. ;^(

Thanks,
MarkH

xxxxx@knowwareinc.com wrote:

I have a root-enumerated (non-PnP) KMDF driver that works as a monitor in conjunction with a 2nd USB driver for the client’s device. This pair has been running fine in Win7, and the client has asked me to migrate this to Win10 1607 for their next gen system, with the understanding of the signing requirements it entails. We have gone ahead and procured an EV cert from DigCert. I build the pair of driver packages with Test Cert under VS 2015 Update 3 / WDK 10.0.15063.0, enable Test Signing on original Win10 target, and all is well.

I then apply the EV cert for Production cert to both packages (disable Test Signing on target, of course), and looking at Setupapi.dev.log, both seem to install fine. However, only the USB driver LOADS, i.e. the noPnP driver never loads/runs. I have applied cross-signing cert, but that driver still does not load. *Installs, yes; loads/runs, no*

Does your system have “secure boot” enabled the BIOS? If not, then the
Windows 10 signing requirements are exactly identical to the Windows 7
signing requirements. No EV cert is required, but you need a
cross-certificate.

If your system does have “secure boot” set, then neither of your
self-signed drivers should load. You are required to go through the Dev
Portal site for attestation signing. It is the Dev Portal login that
requires an EV cert.

What do you see in the “no load” case? Do you get a service manager error?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Mr. Roberts beat me to it… you’ll need to Attestation Sign your driver.

Create a CAB from the driver package, upload it via the Dev Portal, and you’ll have your signed driver back in 10 minutes.

Nobody should fear Attestation Signing! Just do it… it’s painless. Oh… and they ADD their signature to the existing signature on the SYS file.

Peter
OSR
@OSRDrivers

Thank you both for the prompt responses! I have relayed the relevant information to the client.

What puzzles me is that the driver for the USB device loads/runs fine. This driver is built under the exact same VS/WDK environment and signed with same EV-cert (just a different VS project).

I have checked BIOS on the target and indeed Secure Boot is *Disabled* (Legacy Support Enabled). But I do not see any Service Manager errors for the nonPnP monitor driver in question; perhaps I am looking in the wrong place. Where should I see these?

Thanks again!
MarkH

You know, Mr. Holiday, it’s entirely possible that you’re seeing a different problem… and Mr. Roberts and I are just so accustomed to replying “You need to Attestation Sign Your Driver” (something I’ve had to tell at least two OSR clients this week alone), that we’re actually NOT helping.

Peter
OSR
@OSRDrivers

xxxxx@knowwareinc.com wrote:

What puzzles me is that the driver for the USB device loads/runs fine. This driver is built under the exact same VS/WDK environment and signed with same EV-cert (just a different VS project).

I have checked BIOS on the target and indeed Secure Boot is *Disabled* (Legacy Support Enabled). But I do not see any Service Manager errors for the nonPnP monitor driver in question; perhaps I am looking in the wrong place. Where should I see these?

How, exactly, do you start and stop the driver?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

That’s a good point, Tim. I had not thought about that, because it “just started” under previous OS, with start type of SERVICE_DEMAND_START. I am going to try again with start type changed to SERVICE_SYSTEM_START.

I don’t think I can use “net start xx” because its corresponding Service entry is not yet in the Registry.

This leads me to a question I was going to ask yourself and/or Peter: where do I look to determine load errors for drivers? I have not had to investigate this before. My guess is that even if DriverEntry were to fail for some reason, I would not be able to debug that since the driver is not being loaded in the first place. I do not see any events in Service Manager (unless I missed them). Is there a “log for driver LOADING” similar to setupapi.dev.log as “log for driver INSTALLATION”?

Thanks again!
MarkH

OK, let’s step back a moment.

In your initial post, you wrote:

Those two things you wrote “root-enumerated” and “non-PnP” are at odds with each other.

A software-only driver that is “root-enumerated” is by definition a PnP driver. The PDO is created by the Root Enumerator (the PnP Manager) and your driver is called at EvtDriverDeviceAdd.

A Non-PnP Driver would be a kernel service. It would *not* be root enumerated, but would rather be started by the Service Control Manager. You do not HAVE an EvtDriverDeviceAdd in this case… you create your Device Object in DriverEntry. These drivers are almost always written in WDM, *not* KMDF.

So… my question to you is: Which are you?

To your follow-on question:

Not true!

First, WinDbg is *supposed* to be able to allow you to speculatively add breakpoints. So, if you’re driver is named Fred.sys, and you want to put a breakpoint in DriverEntry, you can just do:

bp Fred!DriverEntry

… even if your driver is not yet loaded.

Of course, you could also hard-code a breakpoint within your DriverEntry entry point, and step-through the code that way.

Not to mention, you probably want to start and end your DriverEntry entry point with DbgPrint statements that indicate what’s going on.

Does that help any?

Peter
OSR
@OSRSDrivers

xxxxx@knowwareinc.com wrote:

That’s a good point, Tim. I had not thought about that, because it “just started” under previous OS, with start type of SERVICE_DEMAND_START. I am going to try again with start type changed to SERVICE_SYSTEM_START.

I keep trying to direct this conversation to get the critical
information, and I keep failing. I’m trying to find out whether this is
a PnP driver, or if it is a legacy driver. I asked you “how do you
start and stop the driver”, hoping you would actually tell me, and so
far you have not. The service type you need depends on what kind of
driver it is. If it is a legacy driver, then SERVICE_DEMAND_START means
some user-mode process has to call StartService.

EXACTLY how are you installing this driver? Do you have an installer?
Do you have an INF? Does it use a PnP ID, or a [DefaultInstall]
section? Do you copy files into place?

I don’t think I can use “net start xx” because its corresponding Service entry is not yet in the Registry.

Well, if there’s no Service entry, then the driver does not exist.
Literally. Windows does not refer to drivers by filename, it refers to
them by their service name. No driver can be loaded without a Service
entry – not even a filter. If the driver loads at all, then it has a
Service entry.

This leads me to a question I was going to ask yourself and/or Peter: where do I look to determine load errors for drivers? I have not had to investigate this before. My guess is that even if DriverEntry were to fail for some reason, I would not be able to debug that since the driver is not being loaded in the first place. I do not see any events in Service Manager (unless I missed them). Is there a “log for driver LOADING” similar to setupapi.dev.log as “log for driver INSTALLATION”?

It depends. For a PnP driver, you’ll get a “yellow bang” in Device
Manager, and the yellow bang code tells you more. For a legacy driver,
doing “net start” or StartService can return an error code that gives
you more information.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Peter & Tim - it is a non-PnP driver, that many years ago was based on NonPnp DDK sample. A few years back I rewrote it for Win7 using KMDF, and yes, it explicitly creates a device object during its DriverEntry.

Sorry for the confusion - I guess I was under the (false) assumption that all software-only drivers were root-enumerated.

I do have an INF file, and I use ‘dpinst’ to install the driver package. From setupapi.dev.log I can see that the installation succeeds.

I changed the StartupType to SERVICE_SYSTEM_START but this did not work either for starting the driver. And there is still no Service entry in the registry.

But from this exchange, I guess now I am not certain *how* this thing ever got started in the first place.

One question:
If I include the following in the INF file, is there some system service that would start this?

[MY_DRIVER_Ins.NT.Wdf]
KmdfService = nonpnp, mydriver_Service_kmdfInst

[mydriver_Service_kmdfInst]
KmdfLibraryVersion = 1.19

Thanks.
MarkH

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-633953-
xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, June 30, 2017 11:03 AM
To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Root enumerated EV-cert signed driver not loading
> Win10 1607

> bp Fred!DriverEntry

It’s been far too long since I got to poke around in the kernel debugger, but it used to be that you had to use bu instead of bp if the driver image wasn’t yet loaded.

bu Fred!DriverEntry

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)

A LEADER in Gartner’s SIEM Magic Quadrant (2012-2016)
Highest Score in Gartner’s 2015 SIEM Critical Capabilities Report
A CHAMPION in Info-Tech Research Group’s 2015 SIEM Vendor Landscape Report
SC Labs RECOMMENDED in 2016 SIEM and UTM Group Test | 5-Star Rating (2009-2016)
? ? ? ?

xxxxx@knowwareinc.com wrote:

Peter & Tim - it is a non-PnP driver, that many years ago was based on NonPnp DDK sample. A few years back I rewrote it for Win7 using KMDF, and yes, it explicitly creates a device object during its DriverEntry.

Sorry for the confusion - I guess I was under the (false) assumption that all software-only drivers were root-enumerated.

I do have an INF file, …

Is it the minimal INF file that was included with the “nonpnp” sample?
The one that only has six lines? Because that INF is not intended to be
used by itself. It is a dummy INF file that is meant to be read by the
KMDF co-installer, in the WdfPreDeviceInstall entry point. The nonpnp
sample had two parts: the driver file, and the installer application.
It is the installer application that (1) copies the file to
\windows\system32\drivers, (2) creates the service, and (3) calls the
KMDF co-installer.

and I use ‘dpinst’ to install the driver package. From setupapi.dev.log I can see that the installation succeeds.

Dpinst is not the right tool for a non-PnP driver. If you’re calling on
that dummy INF, then everything becomes clear. Installing a non-PnP
driver is easy, but you have to do it yourself. You can use an INF with
a [DefaultInstall] section, but you don’t use Dpinst with such an INF.

Your installer can be a batch file:
copy nonpnpdriver.sys \windows\system32\drivers
sc create nonpnp1 type= driver start= demand binPath=
\SystemRoot\System32\Drivers\nonpnpdriver.sys

That’s all it takes. After that, you can say
sc start nonpnp1
and your driver should run.

I changed the StartupType to SERVICE_SYSTEM_START but this did not work either for starting the driver. And there is still no Service entry in the registry.

That means your INF is not doing what you think it is doing.

But from this exchange, I guess now I am not certain *how* this thing ever got started in the first place.

That’s our job, sowing confusion around the world!


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

You still have to use bu rather than bp as bp will attempt to instantiate
the breakpoint immediately. Can’t do that if the driver isn’t loaded.

Mark Roddy

On Fri, Jun 30, 2017 at 3:03 PM, Phil Barila
wrote:

> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-633953-
> > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> > Sent: Friday, June 30, 2017 11:03 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE:[ntdev] Root enumerated EV-cert signed driver not loading
> > Win10 1607
>
> > bp Fred!DriverEntry
>
> It’s been far too long since I got to poke around in the kernel debugger,
> but it used to be that you had to use bu instead of bp if the driver image
> wasn’t yet loaded.
>
> bu Fred!DriverEntry
>
>
> Not speaking for LogRhythm
> Phil Barila | Senior Software Engineer
> 720.881.5364 (w)
>
> A LEADER in Gartner’s SIEM Magic Quadrant (2012-2016)
> Highest Score in Gartner’s 2015 SIEM Critical Capabilities Report
> A CHAMPION in Info-Tech Research Group’s 2015 SIEM Vendor Landscape Report
> SC Labs RECOMMENDED in 2016 SIEM and UTM Group Test | 5-Star Rating
> (2009-2016)
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

> You still have to use bu rather than bp

???

If it doesn’t find the symbol, it sets the breakpoint as uninstantiated automagically… do I really mis-remember that?

Peter
OSR
@OSRDrivers

It does

On Jul 1, 2017 4:30 PM, wrote:

> > You still have to use bu rather than bp
>
> ???
>
> If it doesn’t find the symbol, it sets the breakpoint as uninstantiated
> automagically… do I really mis-remember that?
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>