New Hardware : Tested Driver : DriverEntry Not Getting Called

Hi Guys,

I have been developing a WDF driver for a new hardware. The driver was developed using QEMU and it works great in the QEMU environment. Now I am testing the driver with a FPGA which is equivalent to the actual silicone.

When I have the FPGA and I boot windows server 2019, I do see the device in device manager. All good. I have test signing on and have a WinDbg connection to the target.
Now I take my tested [64-bit] and try to install the driver. The Device manager gives me a prompt “unsigned Driver—do you really want to install it” and I say “Yes”.
Then, it says error 39, the “DriverEntry” was not found.

Being completely puzzled, I scan through the PCIe status registers of the device and found a bunch of fatal errors in there. I assume that the PciBus driver has detected some error and that is why its refusing to install the driver (after all my driver is tested!!). And I relay this to the hardware/firmware team.

They are one step ahead of me! They give me a firmware which clear these status bits in the config space and then the device shows up without any errors in the host. Now my driver should load, but it does not and gives me the same error (DriverEntry not found error 0x39).

I would understand if the driver fails in PrepareHardware (or something like that), but “DriverEntry” not found really puzzles me. I am thinking that it is refusing to load the driver because there is some enumeration error on this device.

Question:

How can I get details of errors detected by pci.sys bus driver or any errors related to the device? Are there any extensions available in WinDbg to get more info as Why it is not trying to load my driver?

Any help, highly appreciated.
Aj

Attach a debugger and put a __debugbreak() at the very start of your driver entry. Does it fire?

You can also try checking c:\Windows\inf\setupapi.dev.log for more info

error 39 is not DriverEntry not found, it is your driver failed to load. Obviously you have a DriverEntry routine.

@“Scott_Noone_(OSR)” I already have a DbgBreak in DriverEntry.
@Mark_Roddy : The error code that I sent is the error code displayed in Device manager. It should be in Decimal

@“Scott_Noone_(OSR)” : thanks for pointing out the c:\Windows\inf\setupapi.dev.log. It does give some pointers.

From the Setup-API log some interesting pointers:-

         Verifying file against specific Authenticode(tm) catalog failed.
          !   sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
              sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 16:00:04.886
          !   sig: Driver package catalog file certificate does not belong to Trusted Root Certificates, but user wants to install anyway.

Then at a later point in log I see:-

          Install Device: Starting device 'PCI\VEN_XXXX&DEV_XXXX&SUBSYS_XXXXXXXX&REV_00\4&25BE404C&0&0010'. 16:00:08.074
          dvi:                     Install Device: Starting device completed. 16:00:08.120
          !!!  dvi:                Device not started: Device has problem: 0x27 (CM_PROB_DRIVER_FAILED_LOAD), problem status: 0xc0000263.
          dvi:                     {Configure Device - exit(0x00000000)} 16:00:08.120
          dvi:                     Device Status: 0x01802400, Problem: 0x27

From Debugger when I do a !DevNode for my device:-

Flags (0x0c002230) DNF_ENUMERATED, DNF_IDS_QUERIED,
DNF_RESOURCE_REQUIREMENTS_NEED_FILTERED, DNF_HAS_PROBLEM,
DNF_NO_LOWER_DEVICE_FILTERS, DNF_NO_LOWER_CLASS_FILTERS

CapabilityFlags (0x00000400) WakeFromD0
Problem = CM_PROB_DRIVER_FAILED_LOAD
Problem Status = 0xc0000263

Any input highly appreciated.

Do I need to install some test certificate or something on the windows machine to enable Test Signing?
Must be missing something simple.

Thanks
Aj

OK, maybe we stand corrected. Problem 0xC0000263 is, in fact, STATUS_DRIVER_ENTRYPOINT_NOT_FOUND. You’re quite sure you loaded the 64-bit driver, and didn’t accidently grab the x86 or ARM64 version? What class of device is this? The DriverEntry entry point is not exported – it’s the initial transfer address for the executable. Is there a way you can email a copy of the driver binary to me?

@Tim_Roberts : I will send you the file at timr@probo.com … .does that work for you?

I am sure that this is a 64-bit x64 driver because I have never built the driver for any other platform.
I have also tested the driver on a 64-bit server running on QEMU.

Not sure what am I missing here.

  • Aj

Well, it’s clearly an x64 driver, it only imports from NTOSKRNL and WDFLDR, and it is signed with a WDK test certificate. I don’t see anything wrong. You installed this with an INF file?

Yes, the INF file works great on my QEMU environment. Nothing in there has anything that could be bad. I am saying this because device manager OS actually matched the PCI Ids properly, gave me a prompt if I want to install the driver and I selected yes. The INF file also has a bunch of registry keys creation, which I see are created properly.

The only thing that I can say is that the PCI device is not doing something which it is supposed to do and that is why it does not load a function driver.

Then I did a !pcitree and saw all the devExt for all the devices. Then I did a !devExt on my device:-

!devext ffffe4854e00f1b0
PDO Extension, Bus 0x2, Device 0, Function 0.
DevObj 0xffffe4854e00f060 Parent FDO DevExt 0xffffe4854ceecaa0

** Device State = PciNotStarted**

Does the highlighted give anything?
Thanks
Aj

Hmmm. Your error code really is DRIVER_ENTRYPOINT_NOT_FOUND. So check this thread out: https://community.osr.com/discussion/292960/driver-does-not-work-on-some-versions-of-windows-10 this person seems to have had the exact same problem.

For amusement I grepped a disassembly listing of ntoskrnl and it looks like there are no fewer than 8 paths that return this incredibly specific error code. Super helpful :slight_smile:

1 Like

Make sure that all the imports in the driver are satisfied. Do a dumpbin /IMPORTS on the .sys file and ensure that all the imports are resolved. The thread that Mark was pointing out above may give you some clues.

@Mark_Roddy
This was it!! Would have been a lot easier to solve the problem if the error code returned was not DRIVER_ENTRYPOINT_NOT_FOUND. Or something like “LOAD_FAILURE” or something.

But learned something new today :slight_smile:

Thanks everyone for help.

  • Aj