Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Upcoming OSR Seminars:

Writing WDF Drivers I: Core Concepts, Nashua, NH 15-19 May, 2017
Writing WDF Drivers II: Advanced Implementation Tech., Nashua, NH 23-26 May, 2017
Kernel Debugging and Crash Analysis, Dulles, VA 26-30 June, 2017
Windows Internals & Software Driver Development, Nashua, NH 24-28 July, 2017


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 21  
15 Mar 17 04:55
devho
xxxxxx@outlook.com
Join Date: 09 Feb 2016
Posts To This List: 12
CM_PROB_DRIVER_FAILED_LOAD

Hi guys, 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. 1. Dev and test hosts are both Windows 10 Enterprise x64 (recent build). 2. Driver built with MSVC 2015 WDK 10.0.10586.0 (also know as version 10.1.10586.0) 3. Windows SDK 10.0.1058615 is also present in the build setup. 4. Driver is legacy WDM code rebuilt with modern toolchain. 5. 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). 6. Driver architecture is sys + dll The two components are separate projects in the solution with references and dependency from sys to dll. 7. Dll uses a DEF file to manage its EXPORTS. Both components link message resources for event logging. 8. Build checking stamping (test) signing deploying are all error free. Checkinf ran clean recently and I think it still is. 9. Both sys and dll components together with cat and inf are included in the deployed package which looks good to me. 10. 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) 11. I'm pretty certain that the test host has been prepared correctly for test signing. 12. 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. 13. 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_05f89afc fd5eeb9d\miniportdriver.inf' ([strings]) dvi: Selected driver installs from section [DDInstall] in 'c:\windows\system32\driverstore\filerepository\miniportdriver.inf_amd64_05f89afc fd5eeb9d\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_05f89afcf d5eeb9d\miniportdriver.inf ndv: Building driver list from driver node strong name... inf: Opened INF: 'C:\Windows\System32\DriverStore\FileRepository\miniportdriver.inf_amd64_05f89afc fd5eeb9d\miniportdriver.inf' ([strings]) inf: Saved PNF: 'C:\Windows\System32\DriverStore\FileRepository\miniportdriver.inf_amd64_05f89afc fd5eeb9d\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_535f0b49b5d 47d3f\c_extension.inf' ([strings.0409]) dvi: Missing or invalid ExtensionId under [Version] section in INF 'C:\Windows\System32\DriverStore\FileRepository\c_extension.inf_amd64_535f0b49b5d 47d3f\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_05f89afc fd5eeb9d\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_05f89afc fd5eeb9d\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_05f89afc fd5eeb9d\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_05f89afc fd5eeb9d\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_05f89afc fd5eeb9d\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_05f89afc fd5eeb9d\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_05f89afc fd5eeb9d\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.-de viceId_-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]
  Message 2 of 21  
15 Mar 17 06:24
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3956
CM_PROB_DRIVER_FAILED_LOAD

On Wed, Mar 15, 2017 at 4:55 AM, <xxxxx@outlook.com> wrote: > 0xc0000034 STATUS_OBJECT_NAME_NOT_FOUND - I think you want to go look at the output from depends. Also how are you installing your dll? Mark Roddy --
  Message 3 of 21  
15 Mar 17 07:38
devho
xxxxxx@outlook.com
Join Date: 09 Feb 2016
Posts To This List: 12
CM_PROB_DRIVER_FAILED_LOAD

Hi Mark, Thanks for this. Depends shows all green NTOSKRNL.EXE & HAL.DLL at top level but loads of ? marks for missing files on the target... CNG.SYS EXT-MS-WIN-CI-XBOX-L1-1-0.DLL EXT-MS-WIN-FS-CLFS-L1-1-0.DLL EXT-MS-WIN-NTOS-CLIPSP-L1-1-0.DLL EXT-MS-WIN-NTOS-IUM-L1-1-0.DLL EXT-MS-WIN-NTOS-KCMINITCFG-L1-1-0.DLL EXT-MS-WIN-NTOS-KSECURITY-L1-1-1.DLL EXT-MS-WIN-NTOS-KSIGNINGPOLICY-L1-1-0.DLL EXT-MS-WIN-NTOS-KSR-L1-1-1.DLL EXT-MS-WIN-NTOS-TM-L1-1-0.DLL EXT-MS-WIN-NTOS-UCODE-L1-1-0.DLL EXT-MS-WIN-NTOS-WERKERNEL-L1-1-0.DLL MSRPC.SYS 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.
  Message 4 of 21  
15 Mar 17 08:57
D. T.
xxxxxx@gmail.com
Join Date: 01 Apr 2017
Posts To This List: 180
CM_PROB_DRIVER_FAILED_LOAD

>! 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.
  Message 5 of 21  
15 Mar 17 13:23
devho
xxxxxx@outlook.com
Join Date: 09 Feb 2016
Posts To This List: 12
CM_PROB_DRIVER_FAILED_LOAD

>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?
  Message 6 of 21  
15 Mar 17 13:32
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11447
CM_PROB_DRIVER_FAILED_LOAD

xxxxx@outlook.com wrote: > Depends shows all green NTOSKRNL.EXE & HAL.DLL at top level but loads of ? marks for missing files on the target... > > CNG.SYS > EXT-MS-WIN-CI-XBOX-L1-1-0.DLL > EXT-MS-WIN-FS-CLFS-L1-1-0.DLL > EXT-MS-WIN-NTOS-CLIPSP-L1-1-0.DLL > EXT-MS-WIN-NTOS-IUM-L1-1-0.DLL > EXT-MS-WIN-NTOS-KCMINITCFG-L1-1-0.DLL > EXT-MS-WIN-NTOS-KSECURITY-L1-1-1.DLL > EXT-MS-WIN-NTOS-KSIGNINGPOLICY-L1-1-0.DLL <...excess quoted lines suppressed...> 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.
  Message 7 of 21  
15 Mar 17 13:36
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11447
CM_PROB_DRIVER_FAILED_LOAD

xxxxx@outlook.com wrote: >> 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.
  Message 8 of 21  
15 Mar 17 14:05
devho
xxxxxx@outlook.com
Join Date: 09 Feb 2016
Posts To This List: 12
CM_PROB_DRIVER_FAILED_LOAD

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: <KernelBufferOverflowLib>$(DDK_LIB_PATH)\BufferOverflowK.lib</KernelBufferOverflo wLib> 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.
  Message 9 of 21  
15 Mar 17 16:50
D. T.
xxxxxx@gmail.com
Join Date: 01 Apr 2017
Posts To This List: 180
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.
  Message 10 of 21  
15 Mar 17 16:58
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1304
CM_PROB_DRIVER_FAILED_LOAD

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." So I wonder why you used that as an example? Don Burn Windows Driver Consulting Website: http://www.windrvr.com -----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 <xxxxx@lists.osr.com> 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. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 11 of 21  
15 Mar 17 17:16
D. T.
xxxxxx@gmail.com
Join Date: 01 Apr 2017
Posts To This List: 180
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 Here is the definition in wdm.h for WDK10: #if (NTDDI_VERSION >= NTDDI_WIN2K) NTSYSAPI VOID NTAPI RtlInitializeBitMap ( _Out_ PRTL_BITMAP BitMapHeader, _In_opt_ __drv_aliasesMem PULONG BitMapBuffer, _In_opt_ ULONG SizeOfBitMap ); #endif
  Message 12 of 21  
15 Mar 17 17:53
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1304
CM_PROB_DRIVER_FAILED_LOAD

So this is not the first annotation screw up in the WDK, and it certainly won't be the last. Don Burn Windows Driver Consulting Website: http://www.windrvr.com -----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 <xxxxx@lists.osr.com> 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 Here is the definition in wdm.h for WDK10: #if (NTDDI_VERSION >= NTDDI_WIN2K) NTSYSAPI VOID NTAPI RtlInitializeBitMap ( _Out_ PRTL_BITMAP BitMapHeader, _In_opt_ __drv_aliasesMem PULONG BitMapBuffer, _In_opt_ ULONG SizeOfBitMap ); #endif --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 13 of 21  
15 Mar 17 18:15
D. T.
xxxxxx@gmail.com
Join Date: 01 Apr 2017
Posts To This List: 180
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 doc was updated with WDK8.
  Message 14 of 21  
15 Mar 17 18:57
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11447
CM_PROB_DRIVER_FAILED_LOAD

xxxxx@gmail.com wrote: > 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.
  Message 15 of 21  
15 Mar 17 19:13
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1304
CM_PROB_DRIVER_FAILED_LOAD

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. Don Burn Windows Driver Consulting Website: http://www.windrvr.com -----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 <xxxxx@lists.osr.com> 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 doc was updated with WDK8. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 16 of 21  
16 Mar 17 05:55
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3956
CM_PROB_DRIVER_FAILED_LOAD

On Wed, Mar 15, 2017 at 4:57 PM, Don Burn <xxxxx@windrvr.com> 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. https://msdn.microsoft.com/en-us/windows/hardware/drivers/develop/building-driver s-for-different-versions-of-windows Mark Roddy --
  Message 17 of 21  
16 Mar 17 08:17
Bob Ammerman
xxxxxx@ramsystems.biz
Join Date: 05 Jun 2016
Posts To This List: 48
CM_PROB_DRIVER_FAILED_LOAD

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. * Bob Bob Ammerman xxxxx@ramsystems.biz<mailto:xxxxx@ramsystems.biz> 716.864.8337 138 Liston St Buffalo, NY 14223 www.ramsystems.biz<http://www.ramsystems.biz/> 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 <xxxxx@lists.osr.com> Subject: Re: [ntdev] CM_PROB_DRIVER_FAILED_LOAD On Wed, Mar 15, 2017 at 4:57 PM, Don Burn <xxxxx@windrvr.com<mailto:xxxxx@windrvr.com>> 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. https://msdn.microsoft.com/en-us/windows/hardware/drivers/develop/building-driver s-for-different-versions-of-windows 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
  Message 18 of 21  
16 Mar 17 08:26
devho
xxxxxx@outlook.com
Join Date: 09 Feb 2016
Posts To This List: 12
CM_PROB_DRIVER_FAILED_LOAD

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!
  Message 19 of 21  
16 Mar 17 10:31
D. T.
xxxxxx@gmail.com
Join Date: 01 Apr 2017
Posts To This List: 180
CM_PROB_DRIVER_FAILED_LOAD

Tim Roberts wrote: >You are incorrect. This was an annotation issue in WDK7. Please check that RtlInitializeBitmap does not belong to a pageable section in W7 before arguing. It looks like it was according to others... The discussion is there. https://www.osronline.com/ShowThread.cfm?link=280750
  Message 20 of 21  
16 Mar 17 10:57
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3956
CM_PROB_DRIVER_FAILED_LOAD

On Thu, Mar 16, 2017 at 8:16 AM, Robert Ammerman <xxxxx@ramsystems.biz> wrote: > The below only applies when you want to: > > > > *dynamically determine the features that are available to the driver* > > > > > <...excess quoted lines suppressed...> 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. Mark Roddy --
  Message 21 of 21  
16 Mar 17 14:21
devho
xxxxxx@outlook.com
Join Date: 09 Feb 2016
Posts To This List: 12
CM_PROB_DRIVER_FAILED_LOAD

Well, I can only say that I carefully followed standard advice in 2001 when porting this NT 4 code, to WDM, and made a one line fix in 2005 for a bug that showed up in XP SP3. Today the same code compiles builds installs and runs on Win 10 x64 with the latest WDK targeting Win 7. I might be tempting fate here, but after all the installation headaches, it ran first time. We can point out the little mistakes in specs or advice if we like - but Microsoft are clearly doing something right! This code is 16-20 years old and has never seen 64-bit architecture until today. I'm frankly quite amazed. The VS 2015 built in debugger is (to quote SoftICE) just awesome.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 03:52.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license