Network adapter problem: support request sent by e-mail without responseAnswered

Hey John,

We've receieved it and have been going through the logs and the descriptions attempting to figure out what is going on.

Still waiting for an answer 2 weeks later. Please help us urgently on that matter.

As previously mentioned, our e-mail contains a lot of information, log and details from our back and forth with the end user who is eagerly waiting for assistance.

Thanks.

We’re attempting (and failing) to reproduce what the end-user is seeing. We haven’t exhausted all possible tests yet.

OK then. When can we expect a final answer on that mater ?

Any help please ? This it now URGENT!

Another customer starts complaining with the same problem and we're starting our usual back and forth to get as much data as possible to avoid loosing time with your support… which is ironic because we've provided all that you've requested by e-mail 3 weeks ago without any help so far!

We're spending way too much time on those network adapters issues. Your solution is clearly not good enough as we've been bitten by this problem for years. I really can't understand why you can't simply provide either a switch to disable this check, or an alternative build without it. We'll gladly tick any EULA and validate any strong warnings to eb able to download such a build, just to stop having this problem as it is greatly impacting our brand.

Thanks.

We cannot reproduce this behavior on real machines. VMs are a different beast. It appears as though the configuration of their Hyper-V (maybe in combination with that particular adapter) is what is causing the problem.

We're still trying to reproduce what the customer is seeing. But we haven't had luck yet.

You said in the email that changing their Hyper-V configuration also fixed it. I would say stick with the fixed Hyper-V configuration.

There is likely a reason they've configured their Hyper-V the way that they have (likely to try to keep network traffic isolated), but that's not the secure way to do things. They should assume there are 0-day escapes of Hyper-V (because there are) and that the way to network isolate a device is to unplug it from Ethernet (and optionally epoxy over the RJ45 port).

We're still trying to reproduce this so we can offer more options (and fixes) for customers determined to use interesting configurations.

I really can't understand why you can't simply provide either a switch to disable this check, or an alternative build without it.

Because it's required to get accurate fingerprints. We used to be more lax on network adapter checks and it was a mess of false-positives and false-negatives. We've said this multiple times on the forum.

The tiny handful (sub-100) reports of network adapter issues on the hundreds of millions of installs is a very good error rate. And 99% of the time the solution is to update their machine (Windows), their drivers, and TA. And that “fixes” it.

Yes, we would prefer a 0 reports of this error. But, again, it's almost always an issue of driver of software being out of date. And we're not going to program TA to force updates to their software (then we would get those angry reports instead).

A very small percentage of this error are caused by faulty hardware. Usually some no-name cheap-chinese knockoff.

Yours, however, is an interesting case where their VM configuration is messing things up in an interesting way. But again, the solution is to change their configuration to one that they already know works (you've said as much in the email).

Yours, however, is an interesting case where their VM configuration is messing things up in an interesting way. But again, the solution is to change their configuration to one that they already know works (you've said as much in the email).

You might be mixing support requests because I haven't said anything about a working solution on my e-mail for that user. As a reminder, here is our original message:

A customer is having the infamous activation error: "there are network adapters on the system that are disabled and TurboActivate couldn't read their hardware properties..."

Here are more information and what we tried so far:

• We are using TurboActivate v4.4.4.1 64-bit
• User tried to reboot the machine
• User is on Windows 11 Entreprise 22H2 22631.2070 Windows Feature Experience Pack 1000.22659.1000.0
• User told us that he updated all adapters drivers
• User tried to enable all adapters before running TurboActivate.exe as an administrator
• User tried the following command line:
  • mofcomp C:\Windows\System32\wbem\NetAdapterCim.mof
  • mofcomp C:\Windows\System32\wbem\en-US\NetAdapterCim.mfl
  • mofcomp C:\Windows\System32\wbem\de-DE\NetAdapterCim.mfl
• Event when the ethernet adapter is activated, after running TurboActivate.exe it is deactivated
• User tried the following command line:
  
  • winmgmt /verifyrepository
• Results of the following command line are attached to this message:
  • Get-WmiObject MSFT_NetAdapter -Namespace root\StandardCimv2 > out1.txt
  • Get-WmiObject -Class "win32_networkadapter" | Format-List * > out2.txt
• User is running on Hyper-V and noticed that "apart from the LAN adapter being disabled is, that the Hyper-V configuration changes from External Network to Internal Network."

As you can see, we have had an extensive back and forth with that user. I'm hoping that you would help solve this problem soon.

You might be mixing support requests because I haven't said anything about a working solution on my e-mail for that user.

Nope, that's the email I'm referring to.

User is running on Hyper-V and noticed that "apart from the LAN adapter being disabled is, that the Hyper-V configuration changes from External Network to Internal Network."

I assumed (and maybe the logs also show) that changing back to “external network” fixes the issue. Can you confirm that with the customer.

This is not the case! The end-user hasn't been able to activate yet despite his extreme patience, as our back-and-forth with him started on the 30th of July, and the first e-mail we sent you was on the 3rd of August and contained all the required information. By the way, this e-mail and our additional ping e-mails are still unanswered so I'm glad we have this forum as a backup communication channel.

Here is what he confirmed today: "yes, I can confirm that the activation was never successful. It looks like that the network driver is crashing and being deactivated. I also tried to connect with the a second network interface connected with USB but same behavior. Even if I connect the Computer with WiFi the card is being deactivated. The Notebook is a brand new Dell Alienware m18 R1 with Windows 11 Enterprise."