Changes between Initial Version and Version 1 of Ticket #536, comment 11


Ignore:
Timestamp:
12/09/20 12:24:37 (4 years ago)
Author:
dlon
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #536, comment 11

    initial v1  
    11I'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.
    22
    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".
    44
    55This would maybe not address the root issue, but might it be a good idea to not rely on this registry value?