Npcap OEM 1.50: driver fails to start on Windows 7/Server 2008 R2 #536
Comments
akontsevoy
changed the title
|
Thanks for reporting this. As mentioned in #233 (comment), we are working to ensure the certificates in the trust chain are added to the proper trust stores on the target computer, which reportedly resolves the issue. We expect to have a release that resolves this issue within the next week or so. |
|
@dmiller-nmap But the certificate issue seems to be only half of the problem; even if the driver warning is accepted and the driver is installed, it then fails to start on WS2008R2 with |
Is there any way, e.g. from |
|
Not really (NPFInstall.log included above); So I can only assume that's what gets returned by the Npcap has been installed with the following command line: Service registry entries: |
|
Update: both issues still persist as of 1.55; that is, driver installation still throws a warning (and fails in silent mode), or if forced, the installed driver fails to start (same error 87). Therefore, the second problem (driver failing to start on NT 6.1) was introduced in 1.31<version<=1.50 (probably in 1.40). If I had to guess, it's those registry access changes in Packet.c. The first problem (driver install warning) was probably introduced when you changed your code signing CA (again). As I mentioned in #107, it's not about certificates not being installed in the trusted root store (tried that -- didn't fix the problem, not for NT 6.1), nor is it about SHA256 signatures being used (I do have SHA256 patches installed). It's something else that's different about your old CA and new CA; we need to figure out what exactly. Whatever it is, it readily reproduces on (for example) Racemi WS2008R2 images in AWS EC2 (even after installing SHA256 patches and the rest of Windows updates). Perhaps we are installing root CAs into the wrong store? (Is there a separate trusted CA store for driver code signing as opposed to user code signing?) Can you maybe get in touch with your new CA or with Microsoft and have them shed some light on why one CA works and the other doesn't, despite all the steps taken? |
|
The problem is most likely that the MS kernel-mode code signing cross-certificate for our CA expired 30 minutes before we signed the drivers for Npcap 1.31. Microsoft's official policy is that only drivers signed through the WHQL certification process can be installed on Windows now, though for some reason none of our own tests showed this to be a problem. This is the issue that the The issue of the driver not starting is again not something that showed up in our testing, but I believe it is due to changing our NX pool opt-in mechanism. Windows 6.1 does not support no-execute (NX) nonpaged memory allocations, but later versions do. When we shipped a single binary Windows 7 through 8.1, we used the POOL_NX_OPTIN method to use NX pool on systems that support it by doing a runtime check. When we separated the Windows 7 driver into its own binary, we changed opt-in mechanisms, but code analysis was misidentifying some things, so after several iterations of changes we ended up with a build that attempts to make allocations from the NX pool even on Windows 7 (6.1). This is most likely the cause of the driver failing to start. This should have been caught in our testing, but we have not observed it, and I do not have a good explanation. The signature issue falls under #237, so we can discuss it there. We will continue using this issue to track the driver start failure problem. |
dmiller-nmap
changed the title
|
This issue is fixed in Npcap 1.60. For discussion of the driver install warning/prompt, see #237. |
Version 1.50 of Npcap introduced the same regression on Windows Server 2008 R2 (fully patched before ESU) as 0.9990 did (see #107). When installing manually, a warning pops up to install the driver, and when installing silently, it fails (this time the installer returns proper exit code though, and no longer leaves Npcap half-installed). This is despite kb3033929, kb4474419-v3, and kb4490628 patches installed.
Worse, the driver, even when it installed manually, fails to start on WS2008R2 afterwards:
It looks like you've changed the signer again (now to DigiCert); perhaps you need to install their root and intermediate certificates into appropriate certificate stores before installing the driver? And since by now you are shipping different drivers for W7, W8 and W10, could we not simply leave the W7/2008R2 driver signing process alone? No more changes would be made to those systems except critical patches, so whatever signing mechanism that worked before should in theory continue to work (as long as the involved certificates don't expire or get revoked).
Contents of setupapi.dev.log (silent install failure followed by manual install warning override):
Contents of
NPFInstall.log(again, failed silent install followed by successful manual install):The text was updated successfully, but these errors were encountered: