Issue on Windows with timestamping types (frozen timestamps)

[nikodul]

Describe the bug
On Windows, after testing on at least two computers, we figured out that activating certain timestamping types alter the behaviour of other timestamping types.
In the attached capture test (modified from the capture test program on the git), we open, capture and close a device several times, with different timestamping types.
Whereas the captured packets timestamping seem to work ok in the first round of timestamping types, switching back to PCAP_TSTAMP_HOST captures packets with frozen timestamps.

Restarting the program does not fix the problem: timestamps are frozen except with PCAP_TSTAMP_HOST_LOWPREC and PCAP_TSTAMP_HOST_HIPREC which still seem to work ok.

Only rebooting seems to re-enable correct timestamping with other types (e.g. PCAP_TSTAMP_HOST, PCAP_TSTAMP_HOST_HIPREC_UNSYNCED), until once again the faulty mode is activated (PCAP_TSTAMP_HOST_LOWPREC or PCAP_TSTAMP_HOST_HIPREC or both).

Note: once the issue affects the capture program sample, WireShark also reports frozen timestamps when used on the same interface.

To Reproduce
Steps to reproduce the behavior:

1. Compile and run the test program (modified for the libpcap capturetest.c): capturetest.txt
   Rename from .txt to .c
2. See error

See first analysis by @guyharris here:
the-tcpdump-group/libpcap#1219 (comment)

Expected behavior
Captured packets timestamps should not be identical on many subsequent captured packets.

Logs
test.log

Diagnostic information

• Windows version: Windows 11 Version 21H2, OS Build 22000.2295)
• Output of [DiagReport] attached: DiagReport-20230905-095133.txt

[dmiller-nmap]

The frozen timestamp looks to be about 68 hours prior to the others, which probably means it is a zero performance counter representing the system boot time. With the current driver, that means that the counter of capture handles requiring the performance counter timestamp type (the default) is zero or negative. I will look into bugs in the increment/decrement of this counter.

[dmiller-nmap]

This issue should be resolved in Npcap 1.77.