Disclaimer: I researched what I could on this OSR forum prior to posting this.
I have a working driver package (2 drivers, lower edge+upper filter) that was built using VS2019 (I forget which WDK), that we had attestation signed and have been using for ~2 years, installing that signed package on several machines over that time, with no issues.
We now need to make some minor changes, and while doing so have decided to "migrate" the driver projects to build on VS2022 using the most recent WDK (as of this post is 10.0.26100.1). I have also installed the "matching" SDK for that same version.
Current OS on target is Windows 10 Version 22H2.
Alas, after building and attempting to install the driver package, I receive the following error:
{Driver Entry Point Not Found}
The %hs device driver could not locate the entry point %hs in driver %hs.
I have been at this for a few days trying to resolve this issue, and I am now at a loss, so I am reaching out to this group for their valued help.
In the event this may be related to some incompatible library issue, here is my linker command line:
Where the error message comes from? Is it a system message box or an error from some 3rd party tool? I've often seen misleading 'X Not found' errors on Windows tools when a tool is looking for an entry point in a DLL but actually the DLL was corrupted or not readable or wrong architecture.
Also double check if the DriverEntry is declared correctly.
All I can recommend is what we do whenever we change tool chains: Start with a new, empty, KMDF project, and add the existing files. Reset your include paths and libs.
It’s a small annoyance, but we’ve found this to be the most predictable way of upgrading versions of VS.
So I have gone ahead and done just that. Alas, the exact same issue ensues.
I have never seen anything like this before in my years of Windows kernel mode work. Seems like this should be a simple migration.
Are you guys aware of anything that may contribute to this in this latest WDK??
Is there something specific I should be looking at, e.g. some setting that perhaps has changed??
I can't think of anything, and I've never had this problem. Ugh...
You're not doing anything "unusual"? Building with, clang or using makefile instead of just good old VS and the good old, ordinary, default, WDK project settings?
I am not; I am just building with good ol' VS 2022 and default WDK project settings.
I did disable Spectre Mitigation. The driver that will not load is an NDIS miniport with WDM lower edge, based on netvmini/630 from DDK samples. Again, the previous attestation-signed version worked fine, and this new build has no source code changes.
They are both built as KMDF drivers. The previous version also had Spectre Mitigation disabled, so I have not tried with that enabled. Is that now a requirement?
I'm just trying to suggest something for you to try.
Hmmm... but you said one is an "NDIS driver with a WDM bottom edge" -- That's not a KMDF driver. What leads you to say this is a KMDF driver (this could be the root of the problem).
Well, I am using WDF for data buffer management, request handling, etc. to talk to my proprietary lower edge driver. Note: there is a thread on this forum from a few years back when I was trying to figure out this architecture.
I am setting the following pre-processor directives:
The linker command line is pretty much as what is in my original post for this thread. But here is one thing I noticed:
Should the /ENTRY: item be "GsDriverEntry", rather than "FxDriverEntry", as it is now?
This has been working well, so it is frustrating why simply migrating those vcxprojects from VS2019 to VS2022 should not just simply work. So again, I appreciate your efforts here. Thank you for that!
It should be noted that Spectre Mitigation is only wise from the point of view that it does not cost much. The actual vulnerabilities are very difficult to exploit in a real world setting, and are special cases of a class of timing effects endemic to multi-tasking and pre-emptive multi-tasking OSes. Stuff that we all considered and dismissed long ago. 1990 ish when the advent of SMP and pre-emptive multi-tasking made it possible for one core to 'spy' on the work of another core running concurrently, or one task to 'spy' on the work of a task that was just pre-empted by inferring values that must or probably were present in memory used by those other contexts on the future behaviour of the processor
better CPU microcode and better OS kernel behaviour protect more than the compiler options, but the compiler options are cheap (in terms of the performance of the emitted code) and readily available (all recent versions of VS) so there probably isn't a good reason to disable them. Or if there is, do it with a pragma around a certain block of code and not globally
I have to say that I agree with Mr Bond. Although it is POSSIBLE to exploit Spectre, I don't believe it is possible to extract any usable information in a finite amount of time.
I have always been able to build most everything; it is the issue with subsequent installations that is the impetus for this thread.
Anyhow, a new KMDF driver project from WDK template will build with VS 2022 & WDK 10.0.26100 and install just fine.
However, I just discovered that the NDIS netvmini sample (6.30) from Windows driver samples on github will build untouched using that same build environment - but upon installation I receive the same error: problem status code 0xC0000263 with Driver Entry Point Not Found.
Recall that my target OS is currently Windows 10 Version 22H2.
So the question becomes: does anyone know what has to be done to build an NDIS-WDM Miniport driver with VS2022 and latest WDK that will install on recent Windows 10 OS??
I have just verified that building the latest Netvmini sample driver (version 6.80) from MS Github site with latest WDK (version 10.0.22621.382) - making zero modifications - will NOT install on latest Windows 10 (version 22H2).
I receive the same "Driver Point Entry Not Found" error that I have been wresting with now for over a week.
I get that same result on two (2) different target systems.
As a side note, please be aware that Spectre Mitigation and support for CET / Kernel-mode Hardware-enforced Stack Protection = /CETCOMPAT linker switch, do not work together. They might produce a Stack overflow exception.
While I appreciate the additional information with regards to Spectre Mitigation, please be aware that that is not the cause for this issue. I have verified that this installation/load issue occurs with Spectre Mitigation both enabled or disabled.
I am hoping to not detract from resolving the issue as to what is necessary to:
a) build an NDIS-WDM miniport
b) using the latest WDK with VS 2022
c) such that it will load properly on latest Windows 10
A few weeks back I learned that the classic depends tool also works with drivers.
Try loading your driver into depends on the problem system. You might find some missing exports.
In our case, it was because a function that used to be inline was converted to an export, and older operating systems don't have it.
"Caution
Starting in Windows 11, version 22H2, this function changed from inline to exported. As a result, if you build your driver targeting the latest version of Windows, it will fail to load in older OS versions. To change the target OS version in Visual Studio, select Configuration Properties->Driver Settings->General."
It should be noted that the use of depends.exe is mostly useless these days - at least in UM - because of the introduction of API sets. And the much more complex logic implemented by the loader to inject compatibility shims of various kinds.
I have not looked, but it might still be fine in KM (my job is almost all UM these days). And yes, since a .SYS file is just another PE, every tool that works for .EXE and .DLL files work for .SYS too
