Changes between Initial Version and Version 1 of Ticket #536, comment 11
- Timestamp:
- 12/09/20 12:24:37 (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #536, comment 11
initial v1 1 1 I've seen this (or a similar) issue when using Wintun on a couple of machines (on Windows 10, 18363.1016, and on Windows 10, 19041.630). It occurs only sometimes when creating an adapter, apparently by chance. However, if [https://git.zx2c4.com/wintun/tree/api/wintun.h WintunCreateAdapter] is instructed to create a new adapter with the same GUID as that of the misbehaving device, after the latter has been deleted, then the new device has the same problem. 2 2 3 "ComponentId" and "DeviceInstanceId" are missing from the registry key for the network device. As mentioned above, the problem can be "fixed" by manually creating a "ComponentId" value. Incidentally, wireguard-go is able to set up a tunnel using this same adapter, because it doesn't look up "ComponentId".3 "ComponentId" and "DeviceInstanceId" are missing from the registry key for the network device. As mentioned in other comments, the problem can be "fixed" by manually creating a "ComponentId" value. Incidentally, wireguard-go is able to set up a tunnel using this same adapter, because it doesn't look up "ComponentId". 4 4 5 5 This would maybe not address the root issue, but might it be a good idea to not rely on this registry value?