Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
Coming Back to Driver Development
Bill_Olson
Member Posts: 77
It's been a while for me. I did some driver development back in 2010 and 2011, but the 32 bit ISA driver I wrote back in 2010 has been doing the job adequately and the USB project got pushed to the back burner and was never completed. Now customers are getting to a point where their IT departments are requiring them to update to at least Win 10 x64, so I'm back looking at the drivers.
This is a two part question. I've been trying to get up to speed with VS 2019 and the new WDK, but I've hit some problems, but if the answer to the first question is no, we're going to need a different approach.
As I mentioned, the interface hardware currently in use is an 8 bit ISA card. The system this interfaces with was original introduced in the 1980s and it still does the job. The company I work for has been slowly updating the hardware in the system to use newer components, but the interface has been unchanged for over 30 years. They can still get industrial motherboards with ISA slots, so they keep going with ISA.
There have been three attempts by three different people to make a USB replacement and I got the furthest. A direct translation of the ISA commands to USB is glacially slow because of the nature of the ISA command pattern and USB's scheduled nature. I worked around it, but still had some problems I didn't solve before getting pulled off to do something else.
Anyway, Question #1 - Does Windows 10 x64 still support ISA? I think it does, but we haven't been able to find any examples, even in industrial computing applications.
If true, I've run into some issues getting set up to compile the driver again. I'm just trying to get going with the tools that support Win 10. I have Visual Studio Professional 2019 Version 16.11.9 installed and I installed the 2004 version of the WDK for Win 10. There was an error message for VSIXInstaller at the end, but according to my searches, it appears that only supports an old version of Visual Studio and doesn't support VS 2019.
I found the Getting Started document on OSR's site
https://osr.com/getting-started-writing-windows-drivers/
It says:
"Visual Studio and the WDK together provide everything you need to create driver projects, and to compile, link, and even debug Windows drivers. After you’ve successfully installed Visual Studio and the WDK, you can very easily build a simple driver demo project. You don’t even need any hardware! Just select “New Project” and within Visual C++ select the Windows Driver project category. Within this category select Kernel Mode Driver (KMDF). Click OK and Visual Studio will generate a simple starter or demo driver project for you that doesn’t require any specific hardware. This driver will successfully build, and can even be installed on a test machine. Yup, it really is that simple."
I selected New->Project, but there is no Windows Driver category, or anything that has anything to do with drivers available. My guess is either something from the WDK installer didn't work right or Microsoft went and changed things since document was written and it takes some other magical incantation to get a new driver project now.
What am I doing wrong?
Thanks in advance...
Howdy, Stranger!
| 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 | 13-17 May 2024 | Live, Online |
| Developing Minifilters | 1-5 Apr 2024 | Live, Online |
| Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
| Writing WDF Drivers | 26 Feb - 1 Mar 2024 | Live, Online |
Comments
As far as I know, yes it does. See this NTDEV thread.
...
OK. You could very well have run into the well known "I installed the WDK with VS, but the I don't see any driver type projects" problem. I've had that happen to me, and I've seen it happen to countless clients/students/colleagues over the years.
First, you really DO want to install the Windows 11 WDK. This is the latest WDK, it works with VS 2019 (only) and it's the right WDK to use for Win 10 driver development.
Sooooo... REMOVE the 2004 version of the WDK for Win 10. Install the SDK and WDK as described on the MSFT page. BE SURE to select the option, offered at the end, after the install finishes, to install the whatever-it-is components to hook-up with VS at the end (THIS not working, or not being requested, is what most typically causes the projects to not show up.
Let us know how that goes,
Peter
Peter Viscarola
OSR
@OSRDrivers
I find that impossible to believe. An ISA bus with zero wait states transfers a word every 250ns. In that time USB will have completed two complete microframes. That is, you can transfer 16kB on USB in the same time you get 2 BYTES on ISA. If USB is slower than ISA, then you have done something horribly wrong.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
Actually, a lot of this depends on the user interface. I have dealt with a number of instrument manufacturers whose drivers were a little more than write register / read register as separate IOCTL's. The challenge there is how to create a new interface that can easily be adopted for the program controlling the device, then provide drivers so both ISA and USB can work.
I love that we can count on Mr. Roberts to enlighten us with stuff like this. I, for one, have no earthly clue about how fast or slow most hardware interfaces are. ISA being capable of only transferring one word in 250ns really puts the age of that interface into perspective. And that's quite separate from whether making a USB interface for an ancient ISA device is easy or not easy... I think it depends a lot on the register access pattern required, as Mr. Burn stated.
Still... I love learning the relative speed of various buses.
Thank you, Mr. Roberts.
Peter Viscarola
OSR
@OSRDrivers
Which USB standard are you referring to?
microframe is 125us for HS and 1ms for FS/LS.
Microframe is a HS concept, and is always 125us. A frame is 1ms, for all speeds. HS has both: 8 microframes make up a frame.
My brain is a vast warehouse of useless knowledge. Very much like the secret warehouse at the end of "Raiders of the Lost Ark".
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
This is how the hardware was designed. All transfers are one byte at a time. A straight translation to USB means that you are transferring one byte per 125 us sub-frame (USB2 or 3). On the ISA bus it's 250ns as Tim Roberts points out. The 500x slow down in transfer rate becomes very noticeable very fast.
I figured out how to bundle some transfers into blocks and transfer over USB, but the microcontroller I used on the USB device side had to reproduce the ISA bus on the device side. The back plane of the device chassis is a slightly modified ISA bus protocol. I made some suggestions how we could move further low level functions to the microcontroller, but their customers were clamoring for some other things and I had to switch back to Windows app development and they put USB on a lower priority since ISA was working.
As far as ISA on Win 10 x86, I know that works. We're still using the driver I wrote in 2010. Industrial motherboards are available with ISA slots. I just didn't know if Win 10 x64 supports ISA. x64 can be different when you get off the well beaten track.
I downloaded the Win 11 WDK, but the installer said it's the Win 10 WDK. Maybe a typo on Microsoft's part?
I removed the old Win 10 WDK and installed the new one, but I didn't get the option to install anything else at the end. I noticed there is an EWDK, do I need to install that? It says it's a stand alone development environment, so I would guess not.
I extracted all the install files and stored them on my NAS before I began. A practice I do whenever possible because online installers can end up pointing to dead links eventually. Something MS does more than just about anyone else. Is there a stand alone MSI that will connect this with VS?
OK, it did ask me the question:
Install Windows Driver Kit Visual Studio extension to complete integration with Visual Studio, the Windows Driver Kit extension is required.
The only option was "Close". I made sure the check was set and clicked Close. It came back immediately saying:
The install of "Windows Driver Kit" was not successful for all of the selected products. For more information click on the install log link at the bottom of the dialog.
Here is the contents of the log:
2/1/2022 6:53:32 PM - Microsoft VSIX Installer
2/1/2022 6:53:32 PM - -------------------------------------------
2/1/2022 6:53:32 PM - vsixinstaller.exe version:
2/1/2022 6:53:32 PM - 16.9.1050
2/1/2022 6:53:32 PM - -------------------------------------------
2/1/2022 6:53:32 PM - Command line parameters:
2/1/2022 6:53:32 PM - C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\VSIXInstaller.exe,/a,C:\Program Files (x86)\Windows Kits\10\Vsix\VS2019\WDK.vsix,/callingprocessid:11432,/installas:1996
2/1/2022 6:53:32 PM - -------------------------------------------
2/1/2022 6:53:32 PM - Microsoft VSIX Installer
2/1/2022 6:53:32 PM - -------------------------------------------
2/1/2022 6:53:33 PM - Skipping product Microsoft.VisualStudio.Product.Professional (10f4b98e) since it does not support extensions
2/1/2022 6:53:33 PM - Initializing Install...
2/1/2022 6:53:33 PM - Extension Details...
2/1/2022 6:53:33 PM - Identifier : Microsoft.Windows.DriverKit
2/1/2022 6:53:33 PM - Name : Windows Driver Kit
2/1/2022 6:53:33 PM - Author : Microsoft Corporation
2/1/2022 6:53:33 PM - Version : 10.0.21381.0
2/1/2022 6:53:33 PM - Description : A set of extensions that integrates Windows Driver development into Visual Studio.
2/1/2022 6:53:33 PM - Locale : en-US
2/1/2022 6:53:33 PM - MoreInfoURL :
2/1/2022 6:53:33 PM - InstalledByMSI : False
2/1/2022 6:53:33 PM - SupportedFrameworkVersionRange : [4.5,)
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - SignatureState : ValidSignature
2/1/2022 6:53:33 PM - SignedBy : Microsoft Corporation
2/1/2022 6:53:33 PM - Certificate Info :
2/1/2022 6:53:33 PM - -------------------------------------------------------
2/1/2022 6:53:33 PM - [Subject] : CN=Microsoft Corporation, OU=OPC, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
2/1/2022 6:53:33 PM - [Issuer] : CN=Microsoft Code Signing PCA 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
2/1/2022 6:53:33 PM - [Serial Number] : 33000003C93EFB7FE21A3D22B30000000003C9
2/1/2022 6:53:33 PM - [Not Before] : 12/15/2020 1:24:05 PM
2/1/2022 6:53:33 PM - [Not After] : 12/2/2021 1:24:05 PM
2/1/2022 6:53:33 PM - [Thumbprint] : E120FF932F2D4DFB59B1DA16BA7C397119E2DEBF
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - Supported Products :
2/1/2022 6:53:33 PM - Microsoft.VisualStudio.Community
2/1/2022 6:53:33 PM - Version : [16.0,17.0)
2/1/2022 6:53:33 PM - Microsoft.VisualStudio.Pro
2/1/2022 6:53:33 PM - Version : [16.0,17.0)
2/1/2022 6:53:33 PM - Microsoft.VisualStudio.Enterprise
2/1/2022 6:53:33 PM - Version : [16.0,17.0)
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - References :
2/1/2022 6:53:33 PM - -------------------------------------------------------
2/1/2022 6:53:33 PM - Identifier : Microsoft.VisualStudio.MPF
2/1/2022 6:53:33 PM - Name : Visual Studio MPF
2/1/2022 6:53:33 PM - Version : [11.0,12.0)
2/1/2022 6:53:33 PM - MoreInfoURL :
2/1/2022 6:53:33 PM - Nested : No
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - Prerequisites :
2/1/2022 6:53:33 PM - -------------------------------------------------------
2/1/2022 6:53:33 PM - Identifier : Microsoft.VisualStudio.Component.CoreEditor
2/1/2022 6:53:33 PM - Name : Visual Studio core editor
2/1/2022 6:53:33 PM - Version : [16.0,17.0)
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - Signature Details...
2/1/2022 6:53:33 PM - Extension is signed with a valid signature.
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - Searching for applicable products...
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio 2010 Professional
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio Professional 2013
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio 2013 Shell (Integrated)
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio Professional 2015
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio Community 2015
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio 2015 Shell (Integrated)
2/1/2022 6:53:33 PM - Found installed product - Global Location
2/1/2022 6:53:33 PM - Found installed product - Visual Studio Professional 2017
2/1/2022 6:53:33 PM - VSIXInstaller.NoApplicableSKUsException: This extension is not installable on any currently installed products.
at VSIXInstaller.ExtensionService.GetInstallableDataImpl(IInstallableExtension extension, String extensionPackParentName, Boolean isRepairSupported, IStateData stateData, IEnumerable
1& skuData) at VSIXInstaller.ExtensionService.GetInstallableData(String vsixPath, String extensionPackParentName, Boolean isRepairSupported, IStateData stateData, IEnumerable1& skuData)at VSIXInstaller.ExtensionPackService.IsExtensionPack(IStateData stateData, Boolean isRepairSupported)
at VSIXInstaller.ExtensionPackService.ExpandExtensionPackToInstall(IStateData stateData, Boolean isRepairSupported)
at VSIXInstaller.App.Initialize(Boolean isRepairSupported)
at VSIXInstaller.App.Initialize()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
I have several versions of VS installed (I use VC 2010 the most). I have VS 2019 installed and it runs, but it didn't show up in the list.
I finally got it to work. I completely uninstalled VS 2017 and VS 2019, then reinstalled VS 2019. When I reinstalled the WDK, another screen came up after the Install Windows Driver Kit VS Extension and I was able integrate the driver kit with VS 2019. They're there now.
Thanks for the help.
Glad you got it sorted.
Peter Viscarola
OSR
@OSRDrivers
This is another example of the bandwidth / latency problem. Versus the ISA bus, USB is like a high bandwidth high latency network. Many algorithms have been designed to address this problem, but in general you need to be able to have more data ready to send or 'in flight' than just one byte at a time.
I know nothing about your particular problem, but that probably means redesigning the UM program to make the calls higher level 'commands' instead of simple read / write requests. That will be a breaking change between your driver and application. In your situation, that may or may not be a problem. Regulatory hurtles are often an impediment to changes of this kind on top of the obvious deployment problems.
good luck!
This is an industrial tester with many I/O selectable based on the addressing. During a test it sets addresses in the test system to address a given I/O selection, then runs a test on that point. Signals are injected on a point by setting a D2A, and measurements are made by reading the A2D connected to that point. The A2D should have been implemented with a hardware interrupt, but the system polls it while doing a conversion.
Because of the polling, each D2A takes two 125us on USB, first send the messages to trigger the D2A, then come back to read it. With ISA it's two ISA cycles most of the time, sometimes it takes 2 polls. A test will usually cycle through a bunch of I/O ports and run tests, one after another.
With USB I could combine a bunch of calls for setup, but for the A2D there isn't any way around the delays at least the way the hardware is now.
If your USB device included one of the many available cheap microprocessors you could move all the processing down to the device and just use the host to control which programs to run.
Moving the work to a micro controller is exactly the right thing to do, but it will likely require a redesign of the UM program to send commands like 'Run test suite A' and expect a response with all of those test results. A whole batch of tests of tests get run by the microcontroller, and the results get sent back. If the OP can't change the UM part, then this will be very hard.
One idea is that if there is some way that the driver can detect the start of test suite A without being explicitly told, it can send a command to the microcontroller to run the whole batch that is expected, and only return the first result to UM once all of the results are ready. Then the remaining test results can be satisfied from host memory without any device access and they will all complete quickly. This only works if you can expect a certain set of tests from the first IOCTL or something else
I was testing with a USB controller with a built in microcontroller from Cypress. I built a state machine in the microcontroller for I/O on the backplane bus of the tester and a FIFO system to pumping data through. I rewrote the I/O layer of the sending programs to take advantage of this.
We talked about moving more functionality to the microcontroller and there are a number of low level functions that could be on the microcontroller. The systems engineer (who also is the sales guy, it's a small company) has talked about making an inexpensive system for simple testing that has an embedded PC in the test chassis and all you do is plug in a monitor, keyboard, and mouse. If that happens, it will be a while.
At the time I was working on USB there was a suite of programs and two accessed the hardware asynchronously during test. The programs with USB ran OK stand alone with the hardware, but I couldn't get a full test with the two programs accessing the hardware during a test. I assumed there was a situation where the FIFO was getting mixes of data from the two programs almost at once. I was working on sorting that out when they drew me off to do other things.
The suite of programs are very old. The first of them was written in 1987 for Windows 1.0. The whole suite was released for Windows 2.0. I finished a port to 32 bit Windows when I started. It had stalled a few years before when they ran out of the money and the previous programmer got laid off. Over the last few years I've been writing a new program with all the functionality of the suite. At this point the two programs that access the hardware during test are combined in one program.
There is talk again of getting USB working. This time with only one program accessing the hardware it should be an easier problem. Ultimately some solution using a current standard bus is where they want to go. We've looked a little at industrial ethernet too. Right now they are building computers for customers with an industrial motherboard that has an ISA slot that costs around $1000.
If we have a solution that uses a standard bus like USB or ethernet that will save them the cost of having to build and support custom PCs. The customers can use any PC they want. In most labs that use this equipment, there are multiple users for the testers, so if each user can use their own laptop that will make a lot of users happy. Everyone can configure the software the way they like and not have to worry about other users as much.
That's the long term goal, but short term we need a working x64 ISA driver.
On the driver build front I'm making some progress. I started out creating a KMDF bare bones driver and then started looking at the old driver to cut and paste. Upon researching further I found the old driver was built as WDM. I don't know why, I think KMDF was a thing in 2010, but I created an empty WDM project and it compiled (with a few warnings that were cleaned up).
I'm experimenting with 32 bit first because I have a working 32 bit driver to compare to. I've hit the wall with Win 10 hiding things from the user. My test system is set up as quad boot: Win 7, an old version of Win 10 x86, an up to date version of Win 10 x86, and a new installation of Win 10 x64.
I remembered seeing the driver in Device Manager before, but I could not find it in the newer x86 version of Win 10. I enabled Show Hidden Devices and ended up going over every device in each sub-category. Just to do a sanity check and I went back to Win 7, the card's driver shows up under "Non-Plug n Play Devices" when I select Show Hidden Devices. How do I see a non-PnP device in Win 10 device manager? I know it's installed, I've done testing with the hardware on the Win 10 installation, and I reinstalled the entire software package (which installs the driver too) just to make sure.
You’ve just accidentally wandered into a very ugly area.
You initially asked: Does Windows 10 support ISA. The answer was: Yes, absolutely.
You have an old driver, that was presumably written before Windows 2000? That’s the case if the driver does not have handlers for IRP_MJ_PNP. In that case, you don’t have a WDM driver. You have a Windows NT V4 style, non-PnP and non-Power Management supporting driver.
These drivers are, for all intents and purposes, not supported on modern Windows systems. They might work; they might not work; it depends on the specifics of the system on which they are running.
This driver needs to be rewritten, and it’ll be easiest to rewrite it using WDF. When we do this for our clients, it’s usually “just” a matter of pulling the guts of the hardware manipulation code out of the old driver, and stuffing it into a new, modern, WDF structure. It’s not hard, but you DO need to know how to write WDF drivers.
There’s really no alternative.
Now, if your driver IS a WDM driver (if it handles IRP_MJ_PNP) well, then, there’s hope.
Peter
Peter Viscarola
OSR
@OSRDrivers
The driver was originally written by me in 2010. At the time the oldest OS in use was XP. I looked at the code and there are several uses of IRP_MJ_, specifically IRP_MJ_CREATE and IRP_MJ_DEVICE_CONTROL. I assume that's what I should be looking for?
The hardware though is not PnP. It's a very old design that predates PnP technology and is very simple. The entire schematic fits on one A sized sheet of paper. Is non PnP hardware not supported by Win 10?
For what? If you don't support IRP_MJ_PNP and IRP_MJ_POWER, then it isn't WDM. It's a legacy driver. For ISA, that's not surprising. ISA is not a PnP bus (there's no way for a board to identify itself), so you have to use INF magic to assign the driver. Given the magic, you CAN participate in the PnP world.
Yes, non-PnP hardware is supported. There's lots of it, even in a modern computer. Much of it gets exposed through the BIOS ACPI DSDT.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
OK, I misunderstood the information. IRP_MJ_PNP and IRP_MJ_POWER are not used in this driver, so this is a legacy driver after all. It looks like a rewrite is necessary.
Since it is necessary should I be looking at converting this to a KMDF driver instead?
I thought I remembered some PnP ISA hardware back in the day. I could be wrong. They say memory is the second thing to go... Can't remember the first.
Yes. Rewrite it in KMDF.
It was a bad decision to write this driver as an NT V4 style driver back in 2010. This was already deprecated, and by 2000 it was not architecturally correct to just use whatever resources you want within toting through the PnP manager.
Peter
Peter Viscarola
OSR
@OSRDrivers
I don't know what I was thinking back then.
It looks like most of the online documentation for legacy drivers (pre-WDM) have fallen in the bit bucket. The old driver is pretty simple, it's essentially 4 functions: DriverEntry, DrvUnload, DrvCreateDispatch, and DrvDeviceControl. There are two macros for __drv_dispatchType that define the DrvCreateDispatch and DrvDeviceControl functions.
I can't find much on __drv_dispatchType anywhere. I assume DrvUnload, DrvCreateDispatch, and DrvDeviceControl fit into the architecture in some other way under KMDF?
I’ve never seen the macro __drv_dispatchType… so that’s a new one on me.
So, yes… you can handle create (if you need to, usually you don’t) and dispatching IOCTLs by control code in KMDF. You just need to learn a bit about how to write a WDF driver.
My best hint for leaning WDF is to forget everything you know, or don’t know, about WDM. Approach learning KMDF like you’re learning how to write a driver for a new OS. Of course, standard Windows architectural concepts (threads, IRQLs, etc) all still,apply. But the details of Request handling are very different… and trying to mentally map one driver type to another will lead to constant sorrow.
Peter
Peter Viscarola
OSR
@OSRDrivers
classifying 'irp handler functions - as in the standard WDM driver dispatch
section of a driver object.
Mark Roddy
What Peter said ... take the basic ideas (threads, synchronization, userspace and kernel space, etc.) but treat it as an entirely new OS and programming model Start with one of the simply KMDF samples out there, build it and step through it, then go from there ...
I've spent the week digesting a few of the driver samples. Specifically the AMCC5933 driver, which I had to go back a couple of versions to dig out. That's an ISA driver. I also looked at the non-PnP driver sample (ioctl). I think I'm getting the gist of how the KMDF driver architecture works.
I see the steps to initiate a non-PnP driver are a bit different since you have to tell the driver what the actual resources are rather than have it figure it out for itself. It appears the sample doesn't actually access any hardware though. It appears to just do file I/O.
The hardware I'm working with is pretty simple. It defines 3 I/O ports numbered sequentially from a base address, usually 0x300. So it read and writes to 0x300, 0x301, and 0x302. The board can be set to different I/O port base addresses, though 0x300 is the most common. For a non-PnP driver I believe these addresses need to be in the inf file? And I assume all three need to be enumerated separately?
How do I go about assigning the port addresses in the DeviceAdd function? In the AMCC5933 sample the EvtDevicePrepareHardware function has a loop that parses the resource list and then call MmMapIoSpace to assign the hardware space within the driver. I assume I will call MmMapIoSpace directly once I know what the ports are? And I will call this three times, one for each port used?
Does the driver need to reread the inf file every time the computer boots to get the I/O port addresses when initializing the driver?
A WDF driver for an ISA bus device is identical to a WDF driver for any other hardware device. It gets its resources in PrepareHardware, and it accesses them via the HAL’s READ_REGISTER_xxx and READ_PORT_xxx methods.
You specify the non-PnP resources via LogConfig directives in your INF file.
Peter
Peter Viscarola
OSR
@OSRDrivers
The non-PnP sample has no PrepareHardware section, but it doesn't access hardware. This hardware has nothing for the OS to detect. I should put the information in the LogConfig section of the INF file in a PrepareHardware function? Where to put the information was not clear from the samples.
2 this will force assign the hardware resources to the “pnp” device
3 your pnp driver will receive these resources in PrepareHardware