Starting with TA 4.4.2.1: "CoInitializeEx failed. Re-enable Windows Management Instrumentation (WMI) service"Solved

Hi,

A customer is reporting this error during the launch of our software with TA version 4.4.2.1: "CoInitializeEx failed. Re-enable Windows Management Instrumentation (WMI) service. Contact your system admin for more information".

When moving back to version 4.3.3.0 on the same computer, the problem disappears.

Is it a known problem ? What can be done to fix this ?

Thank you.

Much more information is needed.

What programming language?

Did you upgrade the “integration files”? (E.g. TurboActivate.cs if C#, etc., etc.)?

What OS version (if it's Windows 10, also specify the build version)?

We are using Delphi 10.3 for a 32-bit application.

Both TA and TF DLL, EXEs and integration files (.pas) have been updated.

End user's machine is Edition Windows 10 Home, Version 2004, Build 19041.746, 64 Bit, Dutch. He can reproduce the problem in Administrator mode. He restarted, redownloaded and reinstalled with virus protection off but nothing helps.

Finally, applying this method didn't change anything: https://wyday.com/limelm/help/faq/#fix-broken-wmi

What can we do next ?

Is the WMI service disabled? From the error: “Re-enable Windows Management Instrumentation (WMI) service. Contact your system admin for more information".”

, edited

It must be running because running TA 4.3.3.0 works on the same computer.

Customer confirmed that Windows Management Instrumentation service was running and its startup type set as automatic.

What's next ?

In 4.4.x we vastly improved the speed of hard drive detection / fingerprinting on Windows. However, on failure it returns TA_E_COM (even though, it technically doesn't use COM).

So, we're going to do 2 things.

  1. We're going to create a new error code for this type of failure.
  2. We're going to create a simple utility to diagnose this problem for the customer. So, we'll give more meaningful feedback so the customer can fix their problems.

In the meantime, does this customer have an odd configuration? For example, something like their “main drive” (on which Windows is installed) actually being run off a network drive (or some such craziness)? And / or do they have software that locks down the computer (beyond Window's AV)?

, edited

Here is his reply: « It is an ordinary  Asus desktop, with one fixed 1TB disk, 8GB RAM and Intel Core i5 3GHz processor. Standard configuration, nothing runs of the network.
I am using GDATA antivirus and firewall as protection (standard settings), and already tried with antivirus-guard disabled. »

What’s next ?

Have them download this utility: https://wyday.com/files/wyday-fp-diagnostic.zip

Have them…

  1.  extract it
  2. open a commandline prompt (type “cmd” in the Window start menu)
  3. navigate to the folder they extracted it to (e.g. cd Desktop  or  cd Downloads )
  4. have them run it (  wyday-fp-diagnostic.exe )
  5. Tell them to give you the full output from running that command.
  6. Then give it to us.

It will tell us exactly what failed, and we'll dig into the problem and solution from there.

The customer is having an error with this utility: « The diagnostic utility does not run. The error message says that VCRUNTIME140_1.dll is missing. Meanwhile Windows upgraded from version2004 to 20H2. Unfortunately, the error persists« 

Re-uploaded with the dependencies built in. Try again.

"The feedback is:
First IO call failed: 1
Failed to get main drive information."

hmmmm. We’ll change the tool to provide more info. 
 

Or better yet, would it be possible to do a remote debug of this customer? Something is very wrong, and we need to decide whether it’s with our code or with the errors we’re giving.

, edited

We've just sent you the end-user's detail by e-mail. Let me know how it goes.

Thank you.

The fix should be coming this week.

Answer

TA / TF / TFS 4.4.3 are out with the fix. Thanks for reporting!

The customer confirmed that this version fixed the issue. Thanks.

Reply
Discard post