Cleaning Obsolete Software. Too Much or Too Little ?

[Alan_B]

When Cleaning the registry I see this reported :-

Invalid firewall rule	MCX-In-TCP - %SystemRoot%\ehome\ehshell.exe	HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-Out-TCP - %SystemRoot%\ehome\ehshell.exe	HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-In-UDP - %SystemRoot%\ehome\ehshell.exe	HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-Out-UDP - %SystemRoot%\ehome\ehshell.exe	HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-Prov-Out-TCP - %SystemRoot%\ehome\mcx2prov.exe	HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-McrMgr-Out-TCP - %SystemRoot%\ehome\mcrmgr.exe	HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-In-TCP - %SystemRoot%\ehome\ehshell.exe	HKLM\SYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-Out-TCP - %SystemRoot%\ehome\ehshell.exe	HKLM\SYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-In-UDP - %SystemRoot%\ehome\ehshell.exe	HKLM\SYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-Out-UDP - %SystemRoot%\ehome\ehshell.exe	HKLM\SYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-Prov-Out-TCP - %SystemRoot%\ehome\mcx2prov.exe	HKLM\SYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
Invalid firewall rule	MCX-McrMgr-Out-TCP - %SystemRoot%\ehome\mcrmgr.exe	HKLM\SYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

At first that seems reasonable because things like ehshell.exe are NOT located where the registry is stating.

In fact there is no folder %SystemRoot%\ehome\

 

Now I am unsure because 64 bit Windows lies to 32 bit applications with misdirections about system32 and sysWow64.

Is it also concealing the truth from 64 bit CCleaner and myself ?

When I searched for "ehome" I found it actually existed in Winsxs.

 

Winsxs is more Windows "magic" which I think holds multiple versions of the "same" DLL,

and with "Smoke and Mirrors" tricks Windows allows an application to use the version it needs, thus avoiding DLL HELL.

 

If different applications can use different versions of %SystemRoot%\ehome\ehshell.exe due to Windows magic

Is it possible that %SystemRoot%\ehome\ehshell.exe will only appear when the appropriate application calls for it,

but because HKLM does not define any version then CCleaner fails to invoke a valid version when it summons the EXE to appear

I think CCleaner is correct to remove the registry key, but I like to triple check.

 

There is no folder %SystemRoot%\ehome\

But Winsxs has a bucket load.

It holds 73.6 MB in 92 Files in 71 folders under the names amd64_microsoft-windows-ehome_*

and another 2.41 MB in 5 files in 5 folders under the names wow64_microsoft-windows-ehome_*

Should CCleaner remove this 76 MB of redundant obsolete junk,

or would Windows have a temper tantrum ?

 

Personally I would prefer DLL HELL instead of winsxs which has caused me "SideBySide" errors ! !

 

Regards

Alan

[Nergal]

if ehome isn't installed (or you don't use it) you don't need the firewall rules, at worst Windows firewall (which I highly doubt you, Alan, use) will ask if it's okay for ehome to access the internet.

[Alan_B]

Thanks,

 

I never knew of Ehome until I used Google.

I do not use either Ehome or the Windows Firewall, I use Comodo Internet Security.

 

Is it a reliable dependable rule that guarantees absolute safety to anyone using an alternative to Windows Firewall,

that they may delete absolutely every instance of Obsolete Software which commences with

Invalid firewall rule

 

I have just cleaned one of my invalid rules so I could see inspect the backup REG,

I selected from the registry value the portion "EmbedCtxt=@FirewallAPI.dll" and pasted into RegScanner (from Nirsoft)

That found 1708 instances of what I assume are Windows Firewall Rules which I never intend to use.

Each value has a length of 200 to 300 bytes and the whole set totals 359.50 KB

That is an awful lot of redundant junk if it is only of use with the default Firewall.

 

All my obsolete items were found in either of

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules]

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules]

 

Two of the 1708 items found by RegScanner took me to several other keys including

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules]

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\SharedAccess\Defaults\FirewallPolicy\FirewallRules]

 

I used RegEdit to export all four of the registry keys, and each of the REG files occupied 145 KB of Disc Space.

I counted 150 values in one of those files and I guess the other 3 were similar.

 

Registry cleaning found 12 values to remove out of 1708 values

As my teachers would report at end of term - Must try harder ! ! !

 

I assume the other 1696 values that escaped attention may be needed if I Update or Replace my third party Firewall.

I seem to remember that the old needs removing first and Comodo would drop me into Windows default Firewall whilst out of action.

 

I guess that 73.6 MB of ehome junk in the Winsxs folder is something I am stuck with.

Linux is looking better every day ! !

 

Alan

[Super Fast]

In the future, remember that you can save registry keys in CCleaner to re-import if you have problems.

The computer can be entirely backed up with macrium reflet or some other backup program, leaving you free to experiment.

 

The key is always having good backups first.

[Alan_B]

I agree that backups are good, but not appropriate for me in this situation.

I have a fear that the contents of Winsxs that seem to be unused may be required in 6 months time when some application is installed and depends on their presence.

 

A registry backup can restore the key but has the disadvantages that,

Each key backup will consume 145 KB Disk Space, and only liberate a few hundred bytes from the registry hive after compacting to remove free space;

Merging a REG backup is unlikely to restore normality if that key has been replaced/rewritten for some unrelated purpose, causing system inconsistency.

 

I would be far more interested in saving the 73.6 MB of unwanted and unloved Winsxs files.

 

A Macrium backup (which I use) will restore the whole system as it was with the same consistency as before,

but that will undo all the "enhancements" and updates and new installations and security patches over the last 6 months.

 

Six months is a number I pulled out of the air because I have no idea what the consequences could be.

If I knew what winsxs was all about I might be able to test the consequence within one day instead of waiting for a fateful Patch Tuesday that depends on what I zapped.

 

 

From various sources and places I have been given information that I now (mis)understand to indicate :-

Winsxs is where multiple versions of DLL's can coexist without causing the DLL HELL of "common dll files";

Winsxs is where all executables are linked to by System32 and SysWow64;

I do not know if System32 and SysWow64 are always using links, or if they actually hold anything at all;

 

My deductions include :-

Incompetent programming that results in applications using incompatible versions of the same DLL no longer cause DLL HELL,

Therefore Black Magic presumably causes System32/SysWow64 to link to the "correct" DLL that is held in Winsxs.

I do not know if that Black Magic can do its thing simultaneously for both applications if they are running at the same time.

I do not know if that Black Magic will show me anything at all in System32 if I fail to specify the version I am looking for.

 

I am able to believe that Piriform knows how to use Black Magic and is correct in saying that the particular file in winsxs is not linked to via System32,

so I have no concerns about CCleaner removing the keys and not bothering with backups,

I would love to purge 73.6 MB, but I do not understand this Black Magic and how to get the "truth" about whether the contents may BECOME accessible via System32

 

To paraphrase a famous saying

"Windows Speaks with Forked Tongue".

 

I never used anything more recent than XP until 4 months ago.

I never had 64 bits until 4 months ago.

Until 2 months ago I thought 64 bit hardware gave no benefit other than 64 bit arithmetic and more than 32 bit addressing.

 

Sixty years ago I progressed from making Meccano models to investigating the inner workings of the clockwork power pack.

The massive spring and dozens of cogs surprised me with how eager they were to escape the confines of the power pack enclosure.

It never worked the same again.

I do not intend to do the same thing with Windows 7 ! ! !

 

I think I need to give up on this.

I think there is so much to learn that I can better spend my time in other directions.

 

Regards

Alan