Error message, localhost

Same Problem any fixes?
Code: 5,242,881(0x500001)
Module: C:\Program Files (x86)\Acronis\DiskDirector\mmsBundle.dll
Message: Failed to retrieve parameter 'Windows name'.

Code: 1,311,724(0x1403EC)
Message: WMI 'ConnectServer' failed.

Code: 65,520(0xFFF0)
Message:

Event Code: 0x00500001+0x001403EC+0x0000FFF0

I am also attaching a zip file with acronisinfo

Windows XP SP3 32bit.
Exactly the same problem with exactly the same error messages. Was working fine until quite recently. I do have it running on this same hardware on a different boot of the exact same OS.

I'm about 80% sure it's a registry corruption issue. I've haven't yet rolled back to my furthest reaching restore points to see if I still one where DD is working.

The other possibility is some networking issue. I've recently started streaming like made from Netflix, Hulu, Amazon etc as well as having 12 Terabytes of my own stuff streaming. HOWEVER,
This error is happening on ONE OS on ONE computer of Several running this same version of DD TrueImage, the Same OS version and configuration---all of them networked together. I have 2 other Desktops that do equal or more streaming and DD 11 is working fine on them. Also working fine from my Sony Vaio laptop which has PLEX and Playon and also streams from my NAS.

I have tried nuking DD 11 and doing a re-install--even manually nuking registry entries...to no avail. What I haven't yet done is remove TrueImage Home 12. They ARE from the same company but DD is no longer supported and can tend to be somewhat incompatible with newer versions of TI. I have found, not for this specific instance, but for other DD no shows that it was necessary to uninstall them both, and then reinstall, starting with Disk Director first.

If memory serves there can be incompatible versions of [Acronis Disk Explorer/Virtual Disk Bus/Acronis TIB monitor] associated with the two products. You have to keep tweaking them to get them playing nice together. I've even found a solution in loading Disk Director 9, then True Image, then upgrading DD9 to DD 11. Somehow in that process it sorted out their differences. If you look under in Device Manager you should see an Acronis Devices "folder" near the top of the list. If you've got DD & TI running you may find the problem is related to the entries inside that "Acronis Devices" list. They may both use devices with the same name, but only one may work for both--which is why sequence of installation can be important. I vaguely recall having to go into either DD's or TI's install directory and deleting one or the other's version of the same service. I've solved these issue about a dozen times and OBVIOUSLY should be taking better notes.

For sure, since Tech Support moved out of Moscow and to...?Costa Rico?...wherever...I find myself having to just figure out things on my own. I would not hold my breath waiting for Acronis Tech Support to chime in with a solution NOR would I fork over even $29 for their dubious "assistance".

OK well,
This one turned out to be not that difficult--in my case. I'll take a leap of faith on this one and predict that most of these "WMI 'Connect Server FAILED" issues will have the same source problem and the same basic fix.

The problem is that either the Windows Management Instrumentation Service is not running:
and/or
your Windows Management Instrumentation information files are missing or corrupted.

Probably more likely latter than the former. If the service is simply not running the fix may be as simple as starting it up. A really easy second check to see if files are simply corrupted is to run
msinfo32 from a CMD prompt. It will immediately error off with :
"Can't Collect Information
Cannot access the Windows Management Instrumentation software. Windows Management files may be moved or missing."

In the more probable event that there are corrupted files they are most likely the files within the Repository folder in the WBEM folder. WBEM IS the "WMI" master folder. The solution is to force a rebuild of the Repository files. That is accomplished by renaming the existing Repository folder and rebooting. Windows, upon NOT finding it will rebuild it's contents--and basically the Repository directory within WBEM is just indexing files pointing to all the WMI files as opposed to housing them all. If that index is corrupted then windows can't find any of them so effectively they don't exist.

In Win XP that WBEM is found in Windows/System32/WBEM --on whichever drive letter you have installed windows---Often C: but hasn't been for me for years.

The immediate service associated with WMI is "Windows Management Instrumentation" It should be set to run automatically and it should be running. To rename the Repository Directory you'll want to first STOP that service but DO leave it on Automatic. You should then be able to rename WBEM/Repository to something else and just reboot. If you have trouble renaming it, boot up in SAFE mode and you should be able to rename it without any issues.

Upon rebooting Windows will immediately rebuild the indexes, and in so doing it will actively analyze the files that it finds that SHOULD be indexed --it could take a few minutes. Booting from an SSD drive it seems to happen instantaneous.

If you look at your Events log you WILL see a lot of errors as window boots doesn't find the Repository, starts to rebuild it but still reports back all the instances where it's NOT finding stuff.  The next time you reboot that shouldn't any longer be the case.

Be aware that the "Windows Management Instrumentation" service has as an essential dependency the "Remote Procedure Call (RPC)" service.  That service should also always be on Automatic.   When the Repository index is messed up that service will also report back that it basically can't find anything.    Once the Indexes are rebuilt, RPC will show you all the applications that rely on it---and at the top of that list will be Acronis Disk Director. 

Presumably you'll see everything back to normal once you've renamed Repository, rebooted with both those referenced services set to automatic and given Window a few minutes to recreate a sub-folder within WBEM called Repository and rebuild the index files it holds.   DD 11 should then load and work properly.  If not, reinstall it, Let it do a repair install--as you should NOT still have a WMI issue at that point.

OK, this time I took long notes--if I hit this again, at least I'll know where to come for the pedantic solution. It's far more annoying to KNOW I already solved this issue 3 years ago, but i can't remember what the solution was!