I’ve researched this on NTDEV and elsewhere and there are multiple causes. I’ve gone some way down the paths, and so far gotten nowhere. I’m going in circles to be honest.
Can anyone help me with a plan of attack - in order of most likely to least likely reason and hint at indications that let me check a possibility off my list?
Thanks in anticipation of some fresh ideas.
Here are pertinent details, and I attach setupapi.dev.log at the end.
Dev and test hosts are both Windows 10 Enterprise x64 (recent build).
Driver built with MSVC 2015 WDK 10.0.10586.0 (also know as version 10.1.10586.0)
Windows SDK 10.0.1058615 is also present in the build setup.
Driver is legacy WDM code rebuilt with modern toolchain.
Driver targets all currently supported platforms (Windows 7-10 x32/x64) and is built with the Windows 10 kit (not 8.1). Project Settings taken under advice in response to an earlier post on NTDEV (e.g. links against BufferOverflowK.lib).
Driver architecture is sys + dll The two components are separate projects in the solution with references and dependency from sys to dll.
Dll uses a DEF file to manage its EXPORTS. Both components link message resources for event logging.
Build checking stamping (test) signing deploying are all error free. Checkinf ran clean recently and I think it still is.
Both sys and dll components together with cat and inf are included in the deployed package which looks good to me.
Test signing is applied on both release and debug builds (I’m mixing them both during testing in case build configuration mistakes lie hidden in one of them)
I’m pretty certain that the test host has been prepared correctly for test signing.
I ran Depends.exe (Dependency Walker 2.2.6000 from 2006?) it showed multiple queries. But I’m less than convinced to follow that up, given its age and lack of providence. The fact that help file is unreadable doesn’t inspire my confidence.
Here’s my (redacted) setupapi.dev.log…
>> [Device Install (DiInstallDevice) - ROOT\TOASTER\0000]
>> Section start 2017/03/14 17:49:58.697
cmd: “C:\Windows\system32\mmc.exe” C:\Windows\system32\devmgmt.msc
ndv: Flags: 0x00000002
dvi: Selected driver installs from section [DDInstall] in ‘c:\drivertest\drivers\miniportdriver.inf’.
dvi: Class GUID of device changed to: {5c0eb904-6a74-4a9f-b905-046956acd28b}.
dvi: Set selected driver complete.
sto: {Setup Import Driver Package: c:\drivertest\drivers\miniportdriver.inf} 17:49:58.711
sto: Driver package already imported as ‘oem15.inf’.
sto: {Setup Import Driver Package - exit (0x00000000)} 17:49:58.715
inf: Opened INF: ‘c:\drivertest\drivers\miniportdriver.inf’ ([strings])
inf: Opened INF: ‘C:\Windows\System32\DriverStore\FileRepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’ ([strings])
dvi: Selected driver installs from section [DDInstall] in ‘c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’.
dvi: Class GUID of device changed to: {5c0eb904-6a74-4a9f-b905-046956acd28b}.
dvi: Set selected driver complete.
dvi: {Plug and Play Service: Device Install for ROOT\TOASTER\0000}
ump: Creating Install Process: DrvInst.exe 17:49:58.731
ndv: Driver INF Path: C:\Windows\INF\oem15.inf
ndv: Driver Node Name: miniportdriver.inf:c14ce884221ae399:DDInstall:17.38.42.880:pcmcia\Bills_toast_b.v.-deviceId_-ac14\4
ndv: Driver Store Path: C:\Windows\System32\DriverStore\FileRepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf
ndv: Building driver list from driver node strong name…
inf: Opened INF: ‘C:\Windows\System32\DriverStore\FileRepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’ ([strings])
inf: Saved PNF: ‘C:\Windows\System32\DriverStore\FileRepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.PNF’ (Language = 0409)
dvi: Enumerating INFs from path list ‘C:\Windows\INF’
inf: Opened PNF: ‘C:\Windows\System32\DriverStore\FileRepository\c_extension.inf_amd64_535f0b49b5d47d3f\c_extension.inf’ ([strings.0409])
dvi: Missing or invalid ExtensionId under [Version] section in INF ‘C:\Windows\System32\DriverStore\FileRepository\c_extension.inf_amd64_535f0b49b5d47d3f\c_extension.inf’.
inf: Searched 663 potential matches in published INF directory
dvi: Selected driver installs from section [DDInstall] in ‘c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’.
dvi: Class GUID of device changed to: {5c0eb904-6a74-4a9f-b905-046956acd28b}.
dvi: Set selected driver complete.
ndv: {Core Device Install} 17:49:58.895
! pol: Selected driver node does not match this device (force-install)
ndv: {Install Device - ROOT\TOASTER\0000} 17:49:58.895
ndv: Parent device: HTREE\ROOT\0
! ndv: Unable to determine matching device ID for oem15.inf. Error = 0xE0000228
! ndv: Unable to configure device, falling back to standard device installation.
dvi: {DIF_ALLOW_INSTALL} 17:49:58.899
dvi: No class installer for ‘XYZ-IT ABCD PCMCIA Driver’
inf: Opened PNF: ‘c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’ ([strings])
dvi: No CoInstallers found
dvi: Default installer: Enter 17:49:58.901
dvi: Default installer: Exit
dvi: {DIF_ALLOW_INSTALL - exit(0xe000020e)} 17:49:58.901
dvi: {DIF_INSTALLDEVICEFILES} 17:49:58.901
dvi: No class installer for ‘XYZ-IT ABCD PCMCIA Driver’
dvi: Default installer: Enter 17:49:58.901
dvi: {Install FILES}
inf: Opened PNF: ‘c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’ ([strings])
inf: {Install Inf Section [DDInstall]}
inf: {Install Inf Section [DDInstall] exit (0x00000000)}
dvi: Processing co-installer registration section [DDInstall.CoInstallers].
inf: {Install Inf Section [DDInstall.CoInstallers]}
inf: {Install Inf Section [DDInstall.CoInstallers] exit (0x00000000)}
dvi: Co-installers registered.
dvi: {Install INTERFACES}
dvi: Installing section [DDInstall.Interfaces]
dvi: {Install INTERFACES exit 00000000}
dvi: {Install FILES exit (0x00000000)}
dvi: Default installer: Exit
dvi: {DIF_INSTALLDEVICEFILES - exit(0x00000000)} 17:49:58.907
dvi: {SCAN_FILE_QUEUE}
flq: ScanQ flags=620
flq: SPQ_SCAN_PRUNE_COPY_QUEUE
flq: SPQ_SCAN_FILE_COMPARISON
flq: SPQ_SCAN_ACTIVATE_DRP
flq: ScanQ number of copy nodes=0
flq: ScanQ action=200 DoPruning=32
flq: ScanQ end Validity flags=620 CopyNodes=0
dvi: {SCAN_FILE_QUEUE exit(0, 0x00000000)}
flq: {FILE_QUEUE_COMMIT} 17:49:58.911
flq: No operations queued.
flq: {FILE_QUEUE_COMMIT exit OK} 17:49:58.913
dvi: {DIF_REGISTER_COINSTALLERS} 17:49:58.913
dvi: No class installer for ‘XYZ-IT ABCD PCMCIA Driver’
dvi: Reset Device: Resetting device configuration. 17:49:58.913
dvi: Reset Device: Resetting device configuration completed. 17:49:58.915
dvi: Default installer: Enter 17:49:58.915
inf: Opened PNF: ‘c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’ ([strings])
inf: {Install Inf Section [DDInstall.CoInstallers]}
inf: {Install Inf Section [DDInstall.CoInstallers] exit (0x00000000)}
dvi: Co-installers registered.
dvi: Default installer: Exit
dvi: {DIF_REGISTER_COINSTALLERS - exit(0x00000000)} 17:49:58.917
dvi: {DIF_INSTALLINTERFACES} 17:49:58.917
dvi: No class installer for ‘XYZ-IT ABCD PCMCIA Driver’
inf: Opened PNF: ‘c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’ ([strings])
dvi: No CoInstallers found
dvi: Default installer: Enter 17:49:58.919
dvi: {Install INTERFACES}
inf: Opened PNF: ‘c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’ ([strings])
dvi: Installing section [DDInstall.Interfaces]
dvi: {Install INTERFACES exit 00000000}
dvi: Default installer: Exit
dvi: {DIF_INSTALLINTERFACES - exit(0x00000000)} 17:49:58.921
dvi: {DIF_INSTALLDEVICE} 17:49:58.921
dvi: No class installer for ‘XYZ-IT ABCD PCMCIA Driver’
dvi: Default installer: Enter 17:49:58.923
dvi: {Install DEVICE}
inf: Opened PNF: ‘c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afcfd5eeb9d\miniportdriver.inf’ ([strings])
dvi: Writing BASIC Logical Configurations…
inf: {Install Inf Section [DDInstall]}
inf: {Install Inf Section [DDInstall] exit (0x00000000)}
dvi: Processing Registry/Property directives…
inf: {Install Inf Section [DDInstall]}
inf: {Install Inf Section [DDInstall] exit (0x00000000)}
inf: {Install Inf Section [DDInstall.Hw]}
inf: Empty section
inf: {Install Inf Section [DDInstall.Hw] exit (0x00000000)}
dvi: {Writing Device Properties}
dvi: Provider name=XYZ-IT
dvi: DriverDate 03/14/2017
dvi: DriverVersion=17.38.42.880
dvi: Manufacturer=XYZ-IT
dvi: HardwareID=pcmcia\Bills_toast_b.v.-deviceId-ac14\4
dvi: Matching DeviceID=pcmcia\Bills_toast_b.v.-deviceId-ac14\4
dvi: Strong Name=oem15.inf:c14ce884221ae399:DDInstall:17.38.42.880:pcmcia\Bills_toast_b.v.-deviceId_-ac14\4
dvi: {Writing Device Properties - Complete}
inf: {Install Inf Section [DDInstall.Services]}
inf: AddService=ABCD,0x00000002,MiniportServiceInstall,MiniportEventLogInstall (miniportdriver.inf line 47)
inf: ServiceType=1 (miniportdriver.inf line 50)
inf: StartType=3 (miniportdriver.inf line 51)
inf: ErrorControl=1 (miniportdriver.inf line 52)
inf: ServiceBinary=C:\Windows\system32\DRIVERS\MiniportDriver.sys (miniportdriver.inf line 53)
dvi: Add Service: Modified existing service ‘ABCD’.
inf: AddReg=MiniportEventLogAddReg (miniportdriver.inf line 56)
inf: {Install Inf Section [DDInstall.Services] exit(0x00000000)}
dvi: Updated active section names for: oem15.inf
dvi: {Install DEVICE exit (0x00000000)}
dvi: Writing common driver property settings.
dvi: DriverDescription=XYZ-IT ABCD PCMCIA Driver
dvi: DeviceDisplayName=XYZ-IT ABCD PCMCIA Driver
dvi: Install Device: Configuring device class. 17:49:58.941
dvi: Install Device: Configuring device class completed. 17:49:58.941
dvi: Install Device: Starting device. 17:49:58.941
dvi: Install Device: Starting device completed. 17:49:58.955
!!! dvi: Device not started: Device has problem: 0x27 (CM_PROB_DRIVER_FAILED_LOAD), problem status: 0xc0000034.
dvi: Default installer: Exit
dvi: {DIF_INSTALLDEVICE - exit(0x00000000)} 17:49:58.957
dvi: {DIF_NEWDEVICEWIZARD_FINISHINSTALL} 17:49:58.957
dvi: No class installer for ‘XYZ-IT ABCD PCMCIA Driver’
dvi: Default installer: Enter 17:49:58.959
dvi: Default installer: Exit
dvi: {DIF_NEWDEVICEWIZARD_FINISHINSTALL - exit(0xe000020e)} 17:49:58.959
ndv: Device install status: 0x00000000
ndv: Performing device install final cleanup…
! ndv: Queueing up error report since device has a PnP problem…
ndv: {Install Device - exit(0x00000000)} 17:49:59.019
ndv: {Core Device Install - exit(0x00000000)} 17:49:59.019
ump: Server install process exited with code 0x00000000 17:49:59.021
ump: {Plug and Play Service: Device Install exit(00000000)}
<<< Section end 2017/03/14 17:49:59.025
<<< [Exit status: SUCCESS]
If I build a standard sample (eg kbdfltr) from the WDK samples it looks very similar.
Depends help chm shows empty pages so I’m unable to assess the significance of what’s being shown.
I see comforting green boxes under PI for recognised functions like IoAllocateMdl (but these are not bound). I don’t see anything deviates from that soothing pattern for any of the dependencies found. But there are a shed load of missing dependencies downstream.
This is a fresh install of a recent release of Win10 Enterprise.
Depends is showing Product version 10.0.14393 on all the stuff it does manage to find
I build, with some effort to stick to the orthodox manner, using earlier (10586 vintage) tools.
Static verifier doesn’t work for me either (encountered errors when building the driver) although the release build runs to completion without warnings or errors. I’ve seen that also in NTDEV but here I’m sitting with a fresh install VS2015 & WDK on a fresh install of Windows 10 (14393?).
Regarding DLL install, I’m ONLY copying the dll with the inf to %12% alongside the driver.sys and nothing else. This may be insufficient, and if so I’d like to know but its not *this* issue.
I know this because I’ve dropped the DLL (temporarily I hope) and am now building the whole driver as a monolithic lump. This reduces the number of possible causes quite a lot, but it ISNT changing the behaviour.
>! pol: Selected driver node does not match this device (force-install)
ndv: {Install Device - ROOT\TOASTER\0000} 17:49:58.895
ndv: Parent device: HTREE\ROOT\0 !
ndv: Unable to determine matching device ID for oem15.inf. >Error = 0xE0000228 !
ndv: Unable to configure device, falling back to standard device installation.
What does ROOT\TOASTER\0000 has to do with your device ID ?
Did you use a sample driver INF file as a template ?
Device not started: Device has problem: 0x27
Did you debug the IRP_MN_START_DEVICE code ?
PS: you can use DEVCON to clean the test machinbe. Clean unwanted device nodes and unwanted driver packages from the driver store.
>What does ROOT\TOASTER\0000 has to do with your device ID ?
Its a consequence of defining a custom TOASTER class, as the device doesn’t match any of the standard device types. Its a PCMCIA peripheral, but not a multifunctional device.
The setting may be wrong, but the device has been attaching to the appropriate node since 2000 thru XP, and recently at least once on 7.
Did you use a sample driver INF file as a template ?
In 1997 maybe! I updated that from NT 4 to 2000 and reused it on XP. This is the initial startpoint after all it has been working for 20 years. No claims that its “right” but it passes all the checks.
Did you debug the IRP_MN_START_DEVICE code ?
No, because I don’t see any debug, and it doesn’t hit an initial hard coded breakpoint on driverentry in the debug build. I have enabled a full debug mask. I’m trying out built in VS Debugger for the first time (not WinDbg) there might be some screws loose here. I take this as a strong (but not certain) indication that it isn’t getting as far as calling my driver entry.
Surely a hard coded breakpoint will be honoured without having to take steps to enable it?
Are you testing on Windows 10? Those are Windows 10 DLLs. If you need
this driver to run on earlier systems, you will have to have your
project file target the older systems. You must build for the oldest
system you need to support. You aren’t trying to build a “universal”
driver, are you? Those are Windows 10 only.
Regarding DLL install, I’m ONLY copying the dll with the inf to %12% alongside the driver.sys and nothing else. This may be insufficient, and if so I’d like to know but its not *this* issue.
You should not be copying your INF at all. For a plug-and-play install,
the operating system will place the INF in \Windows\Inf. A
non-plug-and-play install doesn’t need the INF.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> What does ROOT\TOASTER\0000 has to do with your device ID ?
Its a consequence of defining a custom TOASTER class, as the device doesn’t match any of the standard device types. Its a PCMCIA peripheral, but not a multifunctional device.
But PCMCIA devices are plug-and-play, right? The PCMCIA driver should
be creating device IDs that look like
PCMCIA\Manufacturer-Product-CRC
THAT’S the device ID that will be assigned the resources, like memory
and interrupts. That’s the ID you need to claim in your INF.
ROOT\TOASTER\0000 is a fake device that you create in software. It
isn’t connected to the hardware.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim yes I’m testing on 10. I’m building with 10 and the intention is to target 7 and up in 32 and 64 bit.
Property pages and project file have been setup as per earlier ntdev advice, and are probably not wrong… Maybe worth a check as some things are a bit counterintuitive.
Configuration properties General Target Platform greyed out “Windows 10”
TargetPlatformVersion $(LatestTargetPlatformVersion)
PlatformToolset Windows10KernelModeDriver10.0
Configuration type Driver
Linker includes *KernelBufferOverflow.lib*
Driver Settings Target OS Version *Windows 7*
In the Project file: $(DDK_LIB_PATH)\BufferOverflowK.lib
Driver Model Type of driver WDM
I’m told that’s this is the way to build with the Win 10 WDK and to target Windows 7 and up.
User mode similarly uses Win 10 SDK and uses targetver to set compatibility to 7.
The elves might have messed with these settings on the night shift since I configured them, but I think they’re OK.
You should not be copying your INF at all.
I understand, and I’m not. I didn’t make myself clear first time round. I meant to say that my inf file arranges that the driver and the dll are copied to the system at C:\Windows\System32\drivers and trusts that the system search path will find the dll because it is located in the same directory as the driver.
You should create a binary for each WDK you are using because, for instrance, some APIs belong to PAGED_CODE sections in some version of the OS and therefore cannot be used at high IRQL while they belong to non-paged sections in other OS versions.
RtlInitializeBitMap is such an API. This API cannot be used at IRQL > APC_LEVEL since WDK8 even if the BITMAP is located in non-paged pool. In WDK7, the API can be used at any IRQL if the BITMAP is located in non-paged pool.
The general rule is you use the latest WDK, and you target the earliest
version of Windows that you want to support. I certainly wouldn’t recommend
using more than one WDK on a project. Also, the documentation for
RtlInitializeBitMap has always indicated:
“Callers of RtlInitializeBitMap, and callers of other RtlXxx routines that
operate on an initialized bitmap variable, must be running at IRQL <=
APC_LEVEL if the memory that contains the bitmap variable is pageable or the
memory at BitmapHeader is pageable. Otherwise, RtlInitializeBitMap can be
called at any IRQL.”
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, March 15, 2017 4:51 PM
To: Windows System Software Devs Interest List Subject: RE:[ntdev] CM_PROB_DRIVER_FAILED_LOAD
You should create a binary for each WDK you are using because, for instrance, some APIs belong to PAGED_CODE sections in some version of the OS and therefore cannot be used at high IRQL while they belong to non-paged sections in other OS versions.
RtlInitializeBitMap is such an API. This API cannot be used at IRQL > APC_LEVEL since WDK8 even if the BITMAP is located in non-paged pool. In WDK7, the API can be used at any IRQL if the BITMAP is located in non-paged pool.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, March 15, 2017 5:17 PM
To: Windows System Software Devs Interest List Subject: RE:[ntdev] CM_PROB_DRIVER_FAILED_LOAD
>So I wonder why you used that as an example?
We had a discussion about that Don.
Sorry if I’m mixing up here but the headers are not the same for WDK7 and WDK10 for RtlInitializeBitmap.
Here is the WDK7 definition (note the __drv_maxIRQL):
#if (NTDDI_VERSION >= NTDDI_WIN2K) __drv_maxIRQL(APC_LEVEL) NTSYSAPI VOID NTAPI RtlInitializeBitMap ( out PRTL_BITMAP BitMapHeader, in drv_aliasesMem PULONG BitMapBuffer, in ULONG SizeOfBitMap ); #endif
No Don, this is not an annotation issue. I think that in WDK7, you cannot initialize a bitmap at high IRQL because the API could be paged-out.
The doc was updated with WDK8.
You are incorrect. This was an annotation issue in WDK7. The
RtlInitializeBitMap API itself does not have any inherent IRQL
restrictions, and it cannot be paged out. If you ask it to operate on
pagable data, then you had better be <= APC_LEVEL, but that is not in
inherent requirement of the API. That’s why the annotation was removed,
because it restricted legitimate uses.
The exact same thing could be said of RtlMoveMemory. If you give it
non-paged data, it works at any IRQL. If you give it paged data, you
had better be <= APC_LEVEL. That’s not a restriction of RtlMoveMemory.
Compare that, for example, to the Unicode string kernel APIs. Even if
you pass them non-paged data, they access paged data internally. Thus,
they must be called <= APC_LEVEL.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I just saw Tim’s comment, I will add that the most common annotation mistake
is that they restrict the IRQL when it should only be restricted for
non-paged memory. Also, note that the documentation still says only for
non-paged if this was truly a problem the doc’s would have been fixed by
now.
Finally, you were arguing for different binaries for different WDK’s. But
this is not a binary issue, because you would still have to modify the
source for the later OS. Unless there is some critical need having two
versions of the source is beyond stupid. I know when I was a manager if
someone who was supposed to be at the level of writing drivers proposed this
to me, I would be giving them a review to show them out the door.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, March 15, 2017 6:16 PM
To: Windows System Software Devs Interest List Subject: RE:[ntdev] CM_PROB_DRIVER_FAILED_LOAD
No Don, this is not an annotation issue. I think that in WDK7, you cannot initialize a bitmap at high IRQL because the API could be paged-out.
> The general rule is you use the latest WDK, and you target the earliest > version of Windows that you want to support. >
Except of course the MSDN docs say just the opposite now:
If you want your kernel-mode driver to run on multiple versions of Windows and dynamically determine the features that are available to the driver, build the driver using the build configuration for the most recent version of the operating system. For example, if you want your driver to support all versions of Windows starting with Windows 7, but to use certain features that were first available in Windows 8.1 when your driver is running on Windows 8.1 or later versions of the operating system, specify Windows 8.1 ( Win8.1) as the target configuration.
dynamically determine the features that are available to the driver
When you don’t need or care about newer features you can (and should?) use the latest WDK and target the earliest OS you are interested in.
* Bob
Bob Ammerman
xxxxx@ramsystems.bizmailto:xxxxx 716.864.8337
138 Liston St Buffalo, NY 14223 www.ramsystems.bizhttp:</http:>
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy Sent: Thursday, March 16, 2017 5:55 AM To: Windows System Software Devs Interest List Subject: Re: [ntdev] CM_PROB_DRIVER_FAILED_LOAD
On Wed, Mar 15, 2017 at 4:57 PM, Don Burn > wrote: The general rule is you use the latest WDK, and you target the earliest version of Windows that you want to support.
Except of course the MSDN docs say just the opposite now:
If you want your kernel-mode driver to run on multiple versions of Windows and dynamically determine the features that are available to the driver, build the driver using the build configuration for the most recent version of the operating system. For example, if you want your driver to support all versions of Windows starting with Windows 7, but to use certain features that were first available in Windows 8.1 when your driver is running on Windows 8.1 or later versions of the operating system, specify Windows 8.1 (Win8.1) as the target configuration.
Mark Roddy — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</mailto:xxxxx>
Interesting. The dust appears to have settled on “I was correctly advised previously” My stuff’s OK - but the MSDN docs and annotations are a bit fast and loose. It was ever thus.
To get back to my issue and REALLY down to earth. Here’s what actually happened…
I cobbled up an .inx from my initial “x32 only” .inf file. When extending that for NTamd64 I hit some fiddly aspect that blocked me from decorating DDInstall. It seems I need to revisit that!
The .inf is syntactically good but is NOT doing copyfiles on 64 bit. An early candidate happened to be left in system32\drivers and THAT file was being repeatedly used (and rejected) no matter what I supplied on the install media. The dumbest things are the hardest to find.
Thanks for all the help, and I’m glad it stimulated the wider discussion!
On Thu, Mar 16, 2017 at 8:16 AM, Robert Ammerman wrote:
> The below only applies when you want to: > > > > dynamically determine the features that are available to the driver > > > > > > When you don’t need or care about newer features you can (and should?) use > the latest WDK and target the earliest OS you are interested in >
Sure. So what happens when people follow the standard advice to use the lowest version supported as the target is that they end up cutting and pasting header file excerpts in order to support different behavior in later releases. Knowing when you need to “dynamically determine the features” is frequently not obvious. There is no simple answer to which path to take.