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.
1 you add the LogConfig to the inf 2 this will force assign the hardware resources to the “pnp” device 3 your pnp driver will receive these resources in PrepareHardware
Don’t read a non-PnP sample. You’re writing a PnP WDF driver, even though that driver receives non-PnP resources. That you specify.
I don’t how to be more clear than I have been: Put the resources in a LogConfig section in your INF. You will get called with these resources in PrepareHardware… they’ll come in the TranslatedResources structure. Just try it. It works. I promise.
Peter
Once I knew what the key words were, I see there is a LogConfig section in the AMCC5933 sample. Just for clarification, the OS parses both the hardware and the LogConfig section and provides a combined structure with the resources found by both methods? Anyway, I see how to parse it now.
I have another question. The old driver only has two functions that are ever called, a write port and read port. The function that handles this is:
`NTSTATUS IsaDrvDeviceControl(IN PDEVICE_OBJECT DeviceObject,IN PIRP pIrp)
{
PIO_STACK_LOCATION irpSp;
NTSTATUS ntStatus = STATUS_SUCCESS;
ULONG inBufLength; /* Input buffer length */
ULONG outBufLength; /* Output buffer length */
PUCHAR CharBuffer;
PUSHORT ShortBuffer;
PULONG LongBuffer;
PVOID ioBuffer;
USHORT Offset;
UCHAR Value;
DeviceObject;
irpSp = IoGetCurrentIrpStackLocation( pIrp );
inBufLength = irpSp->Parameters.DeviceIoControl.InputBufferLength;
outBufLength = irpSp->Parameters.DeviceIoControl.OutputBufferLength;
ioBuffer = pIrp->AssociatedIrp.SystemBuffer;
CharBuffer = (PUCHAR) ioBuffer;
ShortBuffer = (PUSHORT) ioBuffer;
LongBuffer = (PULONG) ioBuffer;
switch(irpSp->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL_READ_PORT_UCHAR:
if ((inBufLength >= 2) && (outBufLength >= 1))
{
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_TRACE_LEVEL,"MTIsaDrv: IOCTL_READ_PORT_UCHAR 0x%X\n",ShortBuffer[0]);
(UCHAR)Value = READ_PORT_UCHAR((PUCHAR)ShortBuffer[0]);
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_TRACE_LEVEL,"MTIsaDrv: Value Read %X\n",Value);
CharBuffer[0] = Value;
}
else
{
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_TRACE_LEVEL,"MTIsaDrv: IOCTL_READ_PORT_UCHAR Error inBufLength=%u, outBufLength=%u\n",inBufLength,outBufLength);
ntStatus = STATUS_BUFFER_TOO_SMALL;
}
pIrp->IoStatus.Information = 1; /* Output Buffer Size */
ntStatus = STATUS_SUCCESS;
break;
case IOCTL_WRITE_PORT_UCHAR:
if (inBufLength >= 3)
{
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_TRACE_LEVEL,"MTIsaDrv: IOCTL_WRITE_PORT_UCHAR(0x%X,0x%X)\n",ShortBuffer[0], CharBuffer[2]);
WRITE_PORT_UCHAR((PUCHAR)ShortBuffer[0], CharBuffer[2]);
}
else
{
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_TRACE_LEVEL,"MTIsaDrv: IOCTL_WRITE_PORT_UCHAR STATUS_BUFFER_TOO_SMALL inBufLength=%u\n",inBufLength);
ntStatus = STATUS_BUFFER_TOO_SMALL;
}
pIrp->IoStatus.Information = 0; /* Output Buffer Size */
ntStatus = STATUS_SUCCESS;
break;
default:
DbgPrintEx(DPFLTR_IHVDRIVER_ID,DPFLTR_TRACE_LEVEL,"MTIsaDrv: Unsupported IOCTL Call code=0x%X\n",irpSp->Parameters.DeviceIoControl.IoControlCode);
ntStatus = STATUS_UNSUCCESSFUL;
pIrp->IoStatus.Information = 0;
break;
}
pIrp->IoStatus.Status = ntStatus;
IoCompleteRequest( pIrp, IO_NO_INCREMENT );
return ntStatus;
}
`
pIrp on input has the port to use, and data to write for a write function as well as the buffer to return data. It looks like this should be done in the EvtIoDeviceControl function. The buffer sizes are included in the arguments, but I’m unclear where the port number, data, and return buffer are.
The device context you get from
‘devExt = DeviceGetContext(WdfIoQueueGetDevice(Queue));’
can include a handle to the request, but I haven’t found anything using this handle. Some of the samples have port I/O, but none of those do the I/O in direct response to calls from an application.
The WDF equivalent of getting IRP->AssociatedIrp.SystemBuffer for an INPUT argument is calling WdfRequestRetrieveInputBuffer. For an output argument (for you to return a result) call WdfRequestRetireveOutputBuffer.
It seems you could do some reading in the WDK and figure this out…
Peter
The device context you get from … can include a handle to the request …
No, only if you put it there. The device context is simply a structure that YOU define that includes whatever information YOU need to track. In a case like this, where you immediately handle and complete requests, there’s no need for any state information.
Remember that, for METHOD_BUFFERED ioctls, as these surely are, the input and output buffer are the same. The code above makes that clear. KMDF hides that a little bit, since there are separate calls, but WdfRequestRetrieveInputBuffer and …OutputBuffer will return the same pointer. That just means you have to be careful not to overwrite anything you might need.
I’m sorry. I was an idiot. I had been looking for a couple of days and it just didn’t occur to me to look at WdfRequest function definitions. In hindsight it was blind of me.
I did find the functions that got me the pointers I needed.
I got it compiled, but there is a problem with the INF file. I get warnings about the LogConfig statement. I found some documentation on LogConfigOverride, but that appears to not apply here.
I read the description here:
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/inf-logconfig-directive
And followed the example at the bottom. This is the code in the INF
`[MTIsaDrv_Device.NT]
CopyFiles=Drivers_Dir
LogConfig=MTIsa_LogConfig
[MTIsa_LogConfig]
ConfigPriority=NORMAL
IoConfig=3@300-302%ff00(3ff:
`
I get the following warnings when I compile this
`
1>\MTIsaDrv\MTIsaDrv.inf(52-52): warning 2009: Legacy directive ‘LogConfig’ will be ignored.
1>\MTIsaDrv.inf(52-52): warning 1300: Found legacy LogConfig operation.
1>\MTIsaDrv\MTIsaDrv.inf(54-54): warning 2083: Section [mtisa_logconfig] not referenced or used.
`
(I edited the paths for readability)
1300: You will see this error if you use deprecated sections or directives such as LogConfig or DDInstall.CoInstallers.
2083: It doesn’t seem to think it’s referenced.
2009: I can’t find any reference to this, but Warning 2222 has the same wording. It says:
"This warning indicates that the INF specifies a deprecated directive. When the driver is installed, the directive referencing the section is not evaluated. For example, the INF LogConfig Directive directive is no longer supported, so the following section results in this warning.
[InstallSection.LogConfigOverride]
LogConfig=LogConfigSection
…
For information about which INF directives are deprecated, see INF Directives."
In the warnings and errors page here:
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/inf-validation-errors-and-warnings
I was getting some other errors until I changed from Universal Driver to Desktop in the Properties
Driver Settings->General->Target Platform
Changing the Target OS in the same section to Windows 8.1 or 7 doesn’t change anything when compiling. If the above warning explanation is true, it looks like the Win 10 WDK no longer supports LogConfig, which makes this a dead end. I guess I should try the Win 8 WDK?
Setting the driver to be “Desktop” and not “Universal” was going to be MY suggestion.
Regardless of whatever warnings you get… does the INF/Driver install and work?
Peter
It took some effort to get the debug environment set up. windbg kept failing installing on my development machine and I had to move some equipment around to co-locate the test machine with my development machine. The test machine is normally with the test equipment, which weighs about 70 lbs. and is elsewhere.
Anyway, got it set up and tried installing the driver. I didn’t see any of the DbgPrint messages in windbg (I changed the TraceEvents to DbgPrint in the driver code), but I did look at the install log. I think it tells me everything I need to know about LogConfig and Win 10:
sto: {Stage Driver Package: C:\Users\test\AppData\Local\Temp\{3564404b-bdcc-2a41-b9c0-28f1a7aca49f}\mtisadrv.inf} 00:24:59.580
inf: {Query Configurability: C:\Users\test\AppData\Local\Temp\{3564404b-bdcc-2a41-b9c0-28f1a7aca49f}\mtisadrv.inf} 00:24:59.596
! inf: Legacy directive 'LogConfig' will be ignored. Code = 2009, Line = 51
! inf: Found legacy LogConfig operation. Code = 1300
! inf: Driver package 'mtisadrv.inf' is NOT configurable.
inf: {Query Configurability: exit(0x00000000)} 00:24:59.596
flq: {FILE_QUEUE_COMMIT} 00:24:59.596
flq: Copying 'C:\Users\test\AppData\Local\Temp\{3564404b-bdcc-2a41-b9c0-28f1a7aca49f}\MTIsaDrv.cat' to 'C:\WINDOWS\System32\DriverStore\Temp\{11957266-6ca9-bf41-9f75-29c5ee7d722f}\MTIsaDrv.cat'.
flq: Copying 'C:\Users\test\AppData\Local\Temp\{3564404b-bdcc-2a41-b9c0-28f1a7aca49f}\mtisadrv.inf' to 'C:\WINDOWS\System32\DriverStore\Temp\{11957266-6ca9-bf41-9f75-29c5ee7d722f}\mtisadrv.inf'.
flq: Copying 'C:\Users\test\AppData\Local\Temp\{3564404b-bdcc-2a41-b9c0-28f1a7aca49f}\MTIsaDrv.sys' to 'C:\WINDOWS\System32\DriverStore\Temp\{11957266-6ca9-bf41-9f75-29c5ee7d722f}\MTIsaDrv.sys'.
flq: {FILE_QUEUE_COMMIT - exit(0x00000000)} 00:24:59.612
sto: {DRIVERSTORE IMPORT VALIDATE} 00:24:59.612
sig: Driver package catalog is valid.
!!! sig: Driver package INF file hash is not present in catalog file. Filename = mtisadrv.inf, Error = 0xE000024B
! sig: Driver package appears to be tampered, but user wants to install it anyway.
sto: {DRIVERSTORE IMPORT VALIDATE: exit(0x00000000)} 00:25:01.596
sig: Signer Score = 0x80000000 (Unsigned)
sto: {Core Driver Package Import: mtisadrv.inf_x86_cecc67334ca843ca} 00:25:01.596
sto: {DRIVERSTORE IMPORT BEGIN} 00:25:01.596
bak: Create system restore point:
bak: Description = Device Driver Package Install: Robson Technologies Inc. Multitrace Driver
bak: Time = 6094ms
bak: Status = 0x00000000 (SUCCESS)
sto: {DRIVERSTORE IMPORT BEGIN: exit(0x00000000)} 00:25:07.697
cpy: {Copy Directory: C:\WINDOWS\System32\DriverStore\Temp\{11957266-6ca9-bf41-9f75-29c5ee7d722f}} 00:25:07.697
cpy: Target Path = C:\WINDOWS\System32\DriverStore\FileRepository\mtisadrv.inf_x86_cecc67334ca843ca
cpy: {Copy Directory: exit(0x00000000)} 00:25:07.697
idb: {Register Driver Package: C:\WINDOWS\System32\DriverStore\FileRepository\mtisadrv.inf_x86_cecc67334ca843ca\mtisadrv.inf} 00:25:07.712
idb: Created driver package object 'mtisadrv.inf_x86_cecc67334ca843ca' in DRIVERS database node.
idb: Created driver INF file object 'oem7.inf' in DRIVERS database node.
idb: Registered driver package 'mtisadrv.inf_x86_cecc67334ca843ca' with 'oem7.inf'.
idb: {Register Driver Package: exit(0x00000000)} 00:25:07.712
idb: {Publish Driver Package: C:\WINDOWS\System32\DriverStore\FileRepository\mtisadrv.inf_x86_cecc67334ca843ca\mtisadrv.inf} 00:25:07.712
idb: Activating driver package 'mtisadrv.inf_x86_cecc67334ca843ca'.
cpy: Published 'mtisadrv.inf_x86_cecc67334ca843ca\mtisadrv.inf' to 'oem7.inf'.
! inf: Legacy directive 'LogConfig' will be ignored. Code = 2009, Line = 51
idb: Indexed 2 device IDs for 'mtisadrv.inf_x86_cecc67334ca843ca'.
sto: Flushed driver database node 'DRIVERS'. Time = 31 ms
sto: Flushed driver database node 'SYSTEM'. Time = 31 ms
idb: {Publish Driver Package: exit(0x00000000)} 00:25:07.775
sto: {DRIVERSTORE IMPORT END} 00:25:07.775
dvi: Flushed all driver package files to disk. Time = 0 ms
sig: Installed catalog 'MTIsaDrv.cat' as 'oem7.cat'.
bak: Commit system restore point:
bak: Description = Device Driver Package Install: Robson Technologies Inc. Multitrace Driver
bak: Time = 0ms
bak: Status = 0x00000000 (SUCCESS)
sto: {DRIVERSTORE IMPORT END: exit(0x00000000)} 00:25:07.962
sto: {Core Driver Package Import: exit(0x00000000)} 00:25:07.962
sto: {Stage Driver Package: exit(0x00000000)} 00:25:07.962
It looks like LogConfig no longer works with Win 10 if I’m reading the log correctly.
When it looked like this was the situation, I did alert the guy i report to to give him a heads up. We are already talking about changing the hardware. Looks like that’s the route now.
Thanks for taking the time to post this… This is both surprising and very concerning.
So, I spent some time looking around this morning…
COULD it be that we all just “failed to get the email” that this particular directive has been deprecated, and that it’s been REPLACED by a new section called FactDef??
Could you please give this a try, and let us know how it goes? Because, while nothing at all would surprise me about Microsoft these days, I really don’t see how Windows could just eliminate support for non-PnP devices. That would be incredibly unwise, and would rule-out a lot of industrial control PCs.
Peter
The first mentions of LogConfig are related to the configurable state of the INF. A configurable INF, known as Declarative publicly (the D in DCH), failure just means the install will go down the older install path that requires a user mode process to spin up and orchestrate the install
! inf: Legacy directive ‘LogConfig’ will be ignored. Code = 2009, Line = 51
! inf: Found legacy LogConfig operation. Code = 1300
! inf: Driver package ‘mtisadrv.inf’ is NOT configurable.
msports.inf still refers to LogConfig, so I have some doubt that support has been removed, but how often do we see ISA style serial ports anymore ;).
Again, while it may mean it is unsupported, I don’t interpret this line as not supported, but rather this metadata is ignored when the driver package is copied over to the driver store
inf: Legacy directive 'LogConfig' will be ignored. Code = 2009, Line = 51
FactDef has been around since XP, not quite a new section. Rather, I think you should experiment with LogConfigOverride too. From the LogConfig docs, https://docs.microsoft.com/en-us/windows-hardware/drivers/install/inf-logconfig-directive
As a result, the LogConfig directive under a DDInstall section is ignored for PnP devices,. To override the resources reported by the bus for a PnP device, include the LogConfig directive under a DDInstall.LogConfigOverride section. In this case, the resources specified in the log-config-section is used instead of those reported by the bus.
Finally, you should look at the Details tab in the device’s properties dialog. I am guessing a properly processed LogConfig will show up as its own property entry. Maybe there are some clues in the properties.
I totally appreciate Mr. @Doron_Holan’s wisdom here. FactDef was in XP?? I didn’t know that!
how often do we see ISA style serial ports anymore
Hmmmm… in industrial PCs? Every day. In embedded systems? All the time. Shocking, I know… but it’s true.
It LOOKS like LogConfig is, in fact, dead… see this page, where it says among other things:
I don’t really understand… and I definitely don’t understand how FactDef is different from LogConfig.
Peter
Does your driver load and does your driver get assigned the required ISA ports? The logfile indicates ‘success’ at the end, which is where, unless there is other evidence of failure, I would conclude that the inf was in fact processed.
As usual that document might or might not mean it doesn’t work for all driver inf files, not just universal inf files. It clearly says it won’t work for universal. It does not clearly state that for non-universal.
msports.inf still refers to LogConfig, so I have some doubt that support has been removed, but how often do we see ISA style serial ports anymore ;).
Hmmmm… in industrial PCs? Every day. In embedded systems? All the time. Shocking, I know… but it’s true.
Apologies if the snark did not translate in my response. I know they are everywhere and will outlive us all, I guess at this point windows only supports 165550 serial ports that are fully described by the bus or ACPI and can no longer force a hw config on them.
I guess at this point windows only supports 165550 serial ports that are fully described by the bus or ACPI and can no longer force a hw config on them.
I’m almost curious enough to spin up a vm and test this out.
I guess at this point windows only supports 165550 serial ports that are fully described by the bus or ACPI and can no longer force a hw config on them.
Hmmmm… yeah… hmmm… Good point… I have a file named “msports.inf” on my Windows 11 system:
[LptPort.NT]
CopyFiles=LptPort.NT.Copy
AddReg=LptPort.AddReg,LptPort.NT.AddReg
LogConfig=lsnn,lsan,lann,laan
...
[lsnn]
ConfigPriority=HARDRECONFIG
IOConfig=3bc-3be(3ff::),378-37a(3ff::),278-27a(3ff::)
[lsan]
ConfigPriority=HARDRECONFIG
IOConfig=3bc-3be(3ff::),378-37a(3ff::),278-27a(3ff::)
IRQConfig=3,4,5,6,7,8,9,10,11,12,13,14,15
[lann]
ConfigPriority=HARDRECONFIG
IOConfig=8@100-3ff%fff8(3ff::)
[laan]
ConfigPriority=HARDRECONFIG
IOConfig=8@100-3ff%fff8(3ff::)
IRQConfig=3,4,5,6,7,8,9,10,11,12,13,14,15
This isn’t an ISA serial device. It’s an ISA industrial device doing direct I/O with external test hardware. I had come across FactDef and briefly tried to compile with it, but I believe that was before I switched from Universal to Desktop driver.
I tried FactDef again and it looks like it installed OK. Log section at the bottom. There is one warning that I don’t quite follow:
“Selected driver node does not match this device (force-install)”
When I installed with LogConfig, the driver installed, but Device Manager said it was using no resources. With FactDef Device Manager reports that the driver is using ports 300-302, which is correct.
I guess FactDef is the way to go now with Win 10.
`>>> [Device Install (DiInstallDevice) - ROOT\UNKNOWN\0000]
Section start 2022/03/03 19:31:32.732
cmd: “C:\WINDOWS\system32\mmc.exe” C:\WINDOWS\system32\devmgmt.msc
ndv: Flags: 0x00000002
dvi: Class GUID of device changed to: {abdaddaf-39a2-47f2-9ebd-1d0e7395d706}.
ndv: Driver package ‘C:\WINDOWS\System32\DriverStore\FileRepository\mtisadrv.inf_x86_92df085dc7c330ed\mtisadrv.inf’ is already imported.
sto: {Setup Import Driver Package: c:\target\mtisadrv.inf} 19:31:32.758
sto: Driver package already imported as ‘oem8.inf’.
sto: {Setup Import Driver Package - exit (0x00000000)} 19:31:32.774
dvi: Class GUID of device changed to: {abdaddaf-39a2-47f2-9ebd-1d0e7395d706}.
ump: {Plug and Play Service: Device Install for ROOT\UNKNOWN\0000}
dvi: Class GUID of device changed to: {abdaddaf-39a2-47f2-9ebd-1d0e7395d706}.
ndv: {Core Device Install} 19:31:33.180
! pol: Selected driver node does not match this device (force-install)
dvi: {Install Device - ROOT\UNKNOWN\0000} 19:31:33.194
dvi: Device Status: 0x01802001
dvi: Parent Device: HTREE\ROOT\0
dvi: {DIF_ALLOW_INSTALL} 19:31:33.212
dvi: Default installer: Enter 19:31:33.220
dvi: Default installer: Exit
dvi: {DIF_ALLOW_INSTALL - exit(0xe000020e)} 19:31:33.230
dvi: {DIF_INSTALLDEVICEFILES} 19:31:33.238
dvi: Default installer: Enter 19:31:33.244
dvi: Default installer: Exit
dvi: {DIF_INSTALLDEVICEFILES - exit(0x00000000)} 19:31:33.256
dvi: {_SCAN_FILE_QUEUE} 19:31:33.262
flq: File ‘C:\WINDOWS\system32\DRIVERS\MTIsaDrv.sys’ pruned from copy.
dvi: {_SCAN_FILE_QUEUE - exit(0x00000000)} 19:31:33.296
flq: {FILE_QUEUE_COMMIT} 19:31:33.306
flq: {FILE_QUEUE_COMMIT - exit(0x00000000)} 19:31:33.312
dvi: {DIF_REGISTER_COINSTALLERS} 19:31:33.318
dvi: Reset Device: Resetting device configuration. 19:31:33.324
dvi: Reset Device: Resetting device configuration completed. 19:31:33.330
dvi: Default installer: Enter 19:31:33.336
inf: {Install from INF Section - MTIsaDrv_Device.NT.CoInstallers} 19:31:33.342
inf: Flags - 0x001001ee
inf: {Install from INF Section - exit(0x00000000)} 19:31:33.354
dvi: Default installer: Exit
dvi: {DIF_REGISTER_COINSTALLERS - exit(0x00000000)} 19:31:33.366
dvi: {DIF_INSTALLINTERFACES} 19:31:33.372
dvi: Default installer: Enter 19:31:33.378
dvi: Default installer: Exit
dvi: {DIF_INSTALLINTERFACES - exit(0x00000000)} 19:31:33.390
dvi: {DIF_INSTALLDEVICE} 19:31:33.396
dvi: Default installer: Enter 19:31:33.402
dvi: {Install DEVICE}
inf: {Install from INF Section - MTIsaDrv_Device.NT} 19:31:33.414
inf: Flags - 0x00000001
inf: {Install from INF Section - exit(0x00000000)} 19:31:33.426
inf: {Install from INF Section - MTIsaDrv_Device.NT} 19:31:33.432
inf: Flags - 0x001005ee
inf: {Install from INF Section - exit(0x00000000)} 19:31:33.444
dvi: {Writing Device Properties}
dvi: HardwareID=root\mtisadrv
dvi: Strong Name=oem8.inf:e1fec0c324801fcd:MTIsaDrv_Device:1.47.2.886:root\mtisadrv
dvi: {Writing Device Properties - Complete}
inf: AddService=MTIsaDrv,0x00000002,MTIsaDrv_Service_Inst (mtisadrv.inf line 70)
dvi: Add Service: Modified existing service ‘MTIsaDrv’.
inf: {Install from INF Section - MTIsaDrv_Service_Inst} 19:31:33.490
inf: Flags - 0x00100004
inf: {Install from INF Section - exit(0x00000000)} 19:31:33.502
dvi: {Install DEVICE exit (0x00000000)}
dvi: Install Device: Configuring device class. 19:31:33.516
dvi: Install Device: Configuring device class completed. 19:31:33.522
dvi: Device Status: 0x01802001
dvi: Install Device: Starting device ‘ROOT\UNKNOWN\0000’. 19:31:33.534
dvi: Install Device: Starting device completed. 19:31:33.648
dvi: Default installer: Exit
dvi: {DIF_INSTALLDEVICE - exit(0x00000000)} 19:31:33.662
dvi: {DIF_NEWDEVICEWIZARD_FINISHINSTALL} 19:31:33.746
dvi: Default installer: Enter 19:31:33.752
dvi: Default installer: Exit
dvi: {DIF_NEWDEVICEWIZARD_FINISHINSTALL - exit(0xe000020e)} 19:31:33.764
dvi: {Install Device - exit(0x00000000)} 19:31:33.772
dvi: {Core Device Install - exit(0x00000000)} 19:31:33.778
ump: {Plug and Play Service: Device Install exit(00000000)}
<<< Section end 2022/03/03 19:31:33.794
`
I am also facing the same issue.
I have been developing an ISA device driver for Windows 10. For my device, I need to list out the available resources, IRQ, IO ports, and memory ranges for the driver that we are supporting.
With reference to the conversation, I also tried using the FactDef section in my inf file, which is resulting in Found Legacy Operation FactDef.
Microsoft has deprecated FactDef section support.
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-ddinstall-factdef-section
What is the alternate way to list the IRQs for my driver?
Found Legacy Operation FactDef
Is that a problem?? Does it WORK?
Peter