Download Npcap 1.60

[Astryd Boschee]

Fixeda condition where disabling and re-enabling a network adapter while a

capture is active would prevent any packets from being received by the system

until the capture handle was closed. Fixes #710.

Introduced a workaround for a previously-unknown bug in Microsoft's bthpan.sys that was

causing BSoD crashes with INVALID_MDL_RANGE when Npcap or other drivers sent packets over

a Bluetooth-tethered connection. Microsoft intends to patch this Windows bug, but Npcap will

no longer trigger it regardless of patch status. Fixes #708.

Fixed an issue with the Npcap installer that caused it to install duplicate

certificates in the system's certificate store, which caused problems for

some software. The fixed installer will remove the duplicates. Fixes #692.

Fixed an issue causing "failed to set hardware filter to promiscuous mode" errors with NetAdapterCx-based Windows 11 miniport drivers. Npcap was interpreting the NDIS spec too strictly; we have opened an issue with Microsoft to address the fault in netadaptercx.sys. Fixes #628.

Restored original behavior of timestamps in the default case,

PCAP_TSTAMP_HOST_HIPREC_UNSYNCED/TIMESTAMPMODE_SINGLE_SYNCHRONIZATION.

Since Npcap 0.9994, the timestamp was resynchronized after NDIS stack pause

operations, which reduced timestamp drift from wall clock time but made it no

longer monotonic, making packet interval calculations inaccurate. This

restores the default behavior of WinPcap.

Fixed an issue where applications using Npcap 1.20 or later DLLs with a Npcap

1.00 driver would crash due to a stack buffer overrun when the driver returned

too many bytes in response to a request for timestamp modes. Additionally,

changed NPFInstall.exe to attempt to uninstall the Npcap NetCfg component

prior to installation, in case an improperly-uninstalled component persists.

Fixed an issue where promiscuous mode or other hardware packet filters are ignored after a second

handle is opened on the same adapter, including handles opened in the process of listing adapters

with pcap_findalldevs(). Fixes #647.

Increase strictness in checking for and restoring adapter parameters modified during capture:

hardware packet filter and lookahead will only be modified if the original value can be

determined. This fixes issues with connectivity on certain adapter types (WWAN and some WiFi

adapters) after a capture is closed.

Updated build configurations to enable DEP and ASLR for npcap.sys, which were missing from the

original configs inherited from WinPcap. Additionally, enabled Control Flow Guard for Packet.dll

and all helper EXEs.

Restored an undocumented data member of the struct ADAPTER that is not used internally. Directly

accessing members of the ADAPTER struct from Packet32.h is highly discouraged, since the

API in Packet32.h is not intended for use apart from libpcap. Closes #609.

PacketGetNetType() now always sets the LinkSpeed field to 0. Many adapters did not support the OID

that was being used to get the link speed, and libpcap (Npcap's published API) does not pass this

information through, so there should be no impact on the majority of software. Software that needs

link speed may use pcap_oid_get_request() or GetAdaptersAddresses() to get the information.

Packet injection operations are no longer limited to one at a time. Multiple threads can issue

multiple send operations concurrently on the same capture handle without issue, unless system

resource limits result in allocation failures. Additionally, WinPcap's limit of 256 concurrent

sends on each adapter has been removed. Each Write call is still synchronous, however.

Loopback packet capture and injection now uses fewer WFP filters and callbacks, avoids duplicate

packet processing, uses inspection rather than blocking filters, and persists callout driver

objects while still removing callout filters when captures are not using them. These and other

improvements increase loopback capture efficiency and reduce interference with other network

components.

Npcap is only supported on Windows 7 SP1 and later, and requires KB4474419 to support SHA-2

signature validation. The installer will now check these specific requirements, rather than

attempting an installation that will fail anyway.

Fixed a minor issue with Npcap OEM's silent installer: Npcap 1.55 and later ought to avoid

reinstalling the same version if the existing installation options match the requested options,

but /winpcap_mode=no would never match.

Packet sendqueue operations now more strictly check timestamp order. If an out-of-order

timestamp is encountered, the packet will not be transmitted. PacketSendPackets() will

set the last error value to ERROR_INVALID_TIME. Since packets may be

reported slightly out-of-timestamp-order on multiprocessor machines due to

processing delays, only timestamps that are more than 1ms earlier than the

preceding timestamp will generate the error.

Npcap now tracks the original lookahead value (OID_GEN_CURRENT_LOOKAHEAD,

PacketSetMaxLookahead()) before requesting the max value from the miniport, and restores it once

the capture handle is closed. The practice of setting the lookahead to max value was inherited

from WinPcap, and may be changed in the future subject to performance testing.

I'm currently on Windows 7 with KB3033929 (SHA-2 Code Signing Support for Windows 7 and Windows Server 2008 R2) installed. This patch is one of the prerequisites of the last Security Rollup before Windows 7 went out of support, anyone still uses Windows 7 today SHOULD have this installed. (Yes I have tried Windows 10 21H1 and have encountered compatibility problem, there are still valid reasons one can not simply upgrade to Windows 10)

Is the limitation in VeraCrypt added only to prevent users with system encryption from breaking their installation, or it can't work even in portable mode? It would be nice to at least have portable mode still work on Windows 7.

Concerning the idea presented in the links, they seem to indicate the Windows 10 attestation signature will be recognized in Windows 7 and Windows 8/8.1 and so nothing special is needed for non-PNP drivers which is the case of VeraCrypt (we don't need the other shim based idea).

I will need to test this in order to confirm it

Concerning npcap being able to work on Windows 7, they are simply cheating: the driver uses cross-signing with an expired Digicert cross-root certificates at the time of signing. Below are screenshots of the analysis of the npcap 1.60 driver for Windows 7.

As you can see, they are using cross-signing which is not allowed anymore by Microsoft and worse they are cross-signing AFTER the expiration date of Digicert cross-root certificate. Legally they are taking a big risk vis--vis Microsoft.

It's a relief to see a solution coming into place for this. Vadim/botty's post from 2021-10-22 that RadarNyan mentioned pointed to useful info as did mine from 2021-09-09 which specifically mentioned attestation signing being a possible option for VeraCrypt's non-PnP driver.

I won't hold my breath as far as full support for XP/2003 returning as well since there will be no dual signature in future releases. However, if unsigned releases on a limited basis such as once per year could be considered that could help a few people who must continue to use legacy systems for various reasons.

Wow such a long chain of positive events!

The 1.25.6 nightly works on my system: Windows 7 x64, system encryption on UEFI/GPT. I confirmed the driver is loaded (C:\Windows\System32\drivers\veracrypt.sys) using Nirsoft's DriverView. Note that the system is practically clean in my case. Installed from the exe package.

The MSI package is confusing, the main page for VeraCrypt says they're Windows 10 only, but the error message says: "This 32-bit installer can only run on at least Windows Vista" ... the only .msi package is x64.

@opieant1: Indeed, your post gave precise information and I missed it like Vadim one. This mistake made the project loose 4 months! I will try from now on to read all posts to avoid repeating such situation.

@botty: The MSI needs some enhancements and fixes and what you mentioned is part of the TODO list. For now the main functionality is there and the next step will be to make it compatible with system encryption.

As I noted in a reply to your comment on Npcap issue #628, this has nothing to do with the "failed to set hardware filter to promiscuous mode" issue. Please ask a new question, so we can respond to that.

i'm not able to raise a case, maybe because you dinged me for raising a valid issue that needs solving. maybe not exactly the fail above, but very similar (Win 11 2H23 update stops USB Serial devices). ether way,. it didn't need the -1 rating.

This is probably due to 1) the Windows 11 driver for your adapter using the Windows NetAdapterCx framework, 2) the NetAdapterCx framework not strictly following the Network Driver Interface Specification (NDIS) rules, and 3) the Npcap driver expecting all adapter drivers to strictly follow that specification and reporting an error if they don't.

There is a current Wireshark issue open (18414: Version 4.0: failed to to set hardware filter to promiscuous mode) that points to a npcap issue: 628: failed to set hardware filter to promiscuous mode with Windows 11 related to Windows drivers with Windows 11.

I upgraded my Wireshark today and it also tried to replace my Npcap 1.60 with a new 1.71, but the uninstall of 1.60 failed.I tried uninstalling Wireshark from Windows and it worked, but I cannot uninstall Npcap either from within the Wireshark upgrade package or from within the Windows application management. It hangs and doesn't complete the uninstall process.I tried re-installing Wireshark but it says I need to delete Npcap 1.60 first. When I start Wireshark, I get the following:

The error I keep getting is:Unable to load Npcap or WinPcap (wpcap.dll); you will not be able to capture packets. In order to capture packets Npcap or WinPcap must be installed. See for a downloadable version of Npcap and for instructions on how to install it.

3a8082e126