WSAIoctl for SIO_TIMESTAMPING always returns 10045 error (with WSAGetLastError). Cannot understand why

Hi @Nikos Terzis ,

Thanks for reaching out.

I took a close look at what you’re doing, and your socket setup itself looks fine. The reason you’re getting 10045 (WSAEOPNOTSUPP) on SIO_TIMESTAMPING is almost certainly not a coding issue, it’s a capability issue in the networking stack below Winsock.

SIO_TIMESTAMPING is not just a user-mode switch. When you call WSAIoctl with that control code, Winsock checks whether the underlying transport provider and NIC driver advertise timestamping support. If any layer (Winsock provider, TCP/IP stack, NDIS, or the NIC driver) does not report support, Windows immediately returns 10045.

A few important clarifications based on your scenario:

• Enabling the SoftwareTimestamping PowerShell module configures NDIS/software timestamping for the system and W32Time/PTP scenarios, but it does not guarantee that Winsock will expose SIO_TIMESTAMPING to user-mode UDP sockets.
• Even for software timestamping, the NIC driver still needs to advertise the proper capabilities via NDIS OIDs. If it doesn’t, the IOCTL will fail.
• Windows 10 supporting PTP (slave mode) does not automatically mean that general-purpose user-mode socket timestamping is available.
• If this is running in a VM, virtual NICs almost always do not support timestamping.
• Many consumer NIC drivers simply do not expose timestamp capabilities to Winsock, even if the OS has timestamping infrastructure internally.

Given that everything works the moment you remove the SIO_TIMESTAMPING call, the most likely cause is that the specific NIC driver (or its current version) does not expose timestamping support to the Winsock layer on Windows 10 LTSC 21H2.

What I would recommend:

1. Verify whether this is physical hardware (not VM).
2. Check the exact NIC model and install the latest vendor driver (not just the Microsoft inbox driver).
3. Confirm whether the NIC explicitly supports PTP/timestamping features in its specifications.
4. Test on a known PTP-capable NIC if possible (e.g., enterprise-grade Intel adapters).

If after that SIO_TIMESTAMPING still returns 10045, you would need either different hardware or fall back to GetSystemTimePreciseAsFileTime for software-based timing.

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

Error 10045 (WSAEOPNOTSUPP) from WSAIoctl(..., SIO_TIMESTAMPING, ...) means that the requested timestamping operation is not supported on that socket/stack configuration. On Windows this is tightly coupled to what the NIC/miniport reports as its timestamping capabilities and current configuration.

Key points from the Windows timestamping model:

1. Timestamping support is per‑adapter and must be reported by the miniport
   • The NIC driver reports hardware and software timestamping capabilities and which of them are enabled via NDIS_STATUS_TIMESTAMP_CAPABILITY and NDIS_STATUS_TIMESTAMP_CURRENT_CONFIG during initialization.
   • These capabilities include flags such as AllReceiveSw, AllTransmitSw, and TaggedTransmitSw in NDIS_TIMESTAMP_CAPABILITY_FLAGS for software timestamps, and corresponding flags for hardware timestamps.
   • If the miniport does not report timestamping capabilities, or reports them as disabled, higher layers (including Winsock) will treat timestamping as unsupported, and calls like SIO_TIMESTAMPING will fail with WSAEOPNOTSUPP.
2. Software timestamping still depends on the miniport’s advertised capabilities
   • Even for software timestamps, the miniport must explicitly support and enable them. It does this by:
     • Reading the *SoftwareTimestamp INF keyword at initialization to determine whether software timestamping is enabled.
     • Reporting software timestamping capabilities in NDIS_STATUS_TIMESTAMP_CAPABILITY.
     • Reporting the current configuration (enabled/disabled) in NDIS_STATUS_TIMESTAMP_CURRENT_CONFIG.
   • If the miniport does not expose software timestamping capability or has it disabled, the stack will not provide software timestamps for that adapter.
3. How software timestamps are generated (when supported)
   • When software timestamping is supported and enabled, the miniport:
     • Calls KeQueryPerformanceCounter to obtain a QPC value.
     • Fills NET_BUFFER_LIST_TIMESTAMP.Timestamp with that QPC.
     • Attaches it to the NET_BUFFER_LIST via NdisSetNblTimestampInfo.
   • On receive, the QPC is captured as early as possible after packet arrival; on transmit, as late as possible before handing the packet to hardware.
   • For tagged transmit software timestamps, the miniport checks NDIS_NBL_FLAGS_CAPTURE_TIMESTAMP_ON_TRANSMIT and only timestamps when that flag is set.
4. Why SIO_TIMESTAMPING returns 10045 in this scenario
   • If the NIC/driver on Windows 10 LTSC 21H2 does not:
     • Implement the timestamping OIDs (OID_TIMESTAMP_CAPABILITY, OID_TIMESTAMP_CURRENT_CONFIG, etc.), and
     • Report software timestamping as supported and enabled, then the stack will not expose timestamping to Winsock, and SIO_TIMESTAMPING will fail with WSAEOPNOTSUPP regardless of application code.
   • The NIC absolutely matters: timestamping (hardware and software) is an NDIS/miniport feature. The kernel does not unconditionally provide generic software timestamps for all adapters.
5. What to verify In this situation, the following must be true for SIO_TIMESTAMPING to succeed:
   • The NIC’s miniport driver supports NDIS packet timestamping and reports capabilities via NDIS_STATUS_TIMESTAMP_CAPABILITY.
   • The *SoftwareTimestamp INF keyword is configured to enable software timestamping for that adapter.
   • The miniport reports the current configuration via NDIS_STATUS_TIMESTAMP_CURRENT_CONFIG with software timestamping enabled.
   • Overlying components can query timestamping capabilities using the documented APIs (GetInterfaceSupportedTimestampCapabilities / GetInterfaceActiveTimestampCapabilities) and see non‑empty capabilities.

If any of these conditions are not met (for example, the NIC driver does not implement timestamping at all, or software timestamping is disabled in the INF), SIO_TIMESTAMPING will not be available and will fail with error 10045, even though the rest of the PTPv2 networking code works.

References:

• Packet timestamping
• Querying timestamping capabilities and configuration
• Attaching timestamps to packets
• Reporting timestamping capabilities and current configuration
• Standardized INF keywords for NDIS packet timestamping