Il 04/04/20 05:46, blz ha scritto: > On 4/3/2020 12:06 PM, Nathan Stratton Treadway wrote: >> On Fri, Apr 03, 2020 at 20:00:54 +0300, Samuli Seppänen wrote: >>> Hi, >>> >>> Il 02/04/20 22:07, Nathan Stratton Treadway ha scritto: >>>> Would this second option be consistent with the fact that the failed >>>> setupapi log says the driver package was "already imported? >>> Seems like it. You can use >>> >>> <https://github.com/mattock/tap-windows-scripts> >>> >>> to get rid of all tap-windows instances in the Driver Store. That's what >>> I use when I need to be 100% positive the latest driver version is >>> actually being used and not some cached version. >> Yeah, I will plan to do that once it seems like there's nothing more to >> learn investigating the system in its current state.... >> >>>> Is "oemvista.inf_amd64_6d4bec28a2ef0cdf" a name that is hard-coded >>>> inside the TAP-Windows installer, or is that generated dynamically at >>>> installer-execution time? >>> I have absolutely no idea. We don't actively create such identifiers, >>> identifiers so I have to assume it's Windows. >> Well, I guess the interesting thing is that the same directory name was >> used on both the failing- and succeeding-installation machines. So I >> guess it is baked into the driver-installer somewhere (unlike the >> "c:\windows\inf\oem*.inf" name used, which was different between the two >> machines).... But I'm wondering whether or not that directory name is >> constant across tap-windows versions, etc. > What I am wondering is Windows Update, which can and does sometimes > download drivers from Microsoft's repository, could be a possible > culprit? I've seen WU time and again be the root cause of some pretty > big driver-related headaches before.
We have not uploaded tap-windows6 to the Microsoft driver repository. Fortunately it seems :). Samuli _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
