I hope you guys don’t mind too much that this question is about somebody else’s driver, not one I have written or am trying to write…
I have a customer that uses a USB->Relay output board from a large supplier in that space. The board refused to work on a new machine which only has USB3 controllers on it (even though some of the ports are only USB2). The vendor says their driver, which has been running fine in USB2 for a decade or so, is incompatible with the USB3 world and “can’t be fixed”. I take the last to mean “they don’t want to fix it”.
I was under the impression that a USB2 driver would work fine with a USB3 controller. Am I wrong? If so, I have serious concerns about the future of a driver I did write.
* Bob
? Bob Ammerman
? xxxxx@ramsystems.biz
716.864.8337
138 Liston St
Buffalo, NY 14223
www.ramsystems.biz
-----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 1:03 PM
To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Root enumerated EV-cert signed driver not loading
> Win10 1607
>
> 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
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at:
> http:
>
> 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:</http:></http:></http:>