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