000000000046 will duplicate in the registry when the bridge is broke, because it is a failsafe. The failsafe. Is it a choker that every time CCleaner runs a registry scan, cleans all, and this 000000000046 child mirror reappears? To quote our Horse's Engineer, "That Cleaner is one step away from viral." CC has the starch to actually remove the key for about 1/10,000 of a second. So if the CC key tag system can handle that, why can't it FAIL to report 000000000046 Typelib every time it runs UNLESS there is a legitimate bridge issue?
Usual excuse from Piriform is, "Gosh, it was Norton again!" Not. It was Windows. Thing is this, when the bridge gets banged up, CC's key tangle makes it instantly part of the problem. At an administration level redesigning interrupts at 1/10,000 of a second... wait, NO! at 1/20,000 of a second. verified on this box a few times, lol. IE11 readdresses back servers. And so does the kernel. Just a thought, eh.
Abstract::
Missing TypeLib Reference IBackupLocationsShellFolderImpl - {00020424-0000-0000-C000-000000000046} HKCR\Interface\{F0E3A5D7-80C7-4228-90FE-61DF01C417A5} Mark
HKEY_CLASSES_ROOT\Interface\{F0E3A5D7-80C7-4228-90FE-61DF01C417A5} (Default) REG_SZ IBackupLocationsShellFolderImpl
HKEY_CLASSES_ROOT\Interface\{F0E3A5D7-80C7-4228-90FE-61DF01C417A5}\TypeLib (Default) REG_SZ {00020424-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\Interface\{F0E3A5D7-80C7-4228-90FE-61DF01C417A5}\TypeLib Version REG_SZ 1.0
Key Name: HKEY_CLASSES_ROOT\Interface\{F0E3A5D7-80C7-4228-90FE-61DF01C417A5}
Class Name: <NO CLASS>
Last Write Time: 130716 - 22:13
Value 0
Name: <NO NAME>
Type: REG_SZ
Data: IBackupLocationsShellFolderImpl
Key Name: HKEY_CLASSES_ROOT\Interface\{F0E3A5D7-80C7-4228-90FE-61DF01C417A5}\ProxyStubClsid
Class Name: <NO CLASS>
Last Write Time: 130716 - 22:13
Value 0
Name: <NO NAME>
Type: REG_SZ
Data: {00020424-0000-0000-C000-000000000046}
Key Name: HKEY_CLASSES_ROOT\Interface\{F0E3A5D7-80C7-4228-90FE-61DF01C417A5}\ProxyStubClsid32
Class Name: <NO CLASS>
Last Write Time: 130716 - 22:13
Value 0
Name: <NO NAME>
Type: REG_SZ
Data: {00020424-0000-0000-C000-000000000046}
Key Name: HKEY_CLASSES_ROOT\Interface\{F0E3A5D7-80C7-4228-90FE-61DF01C417A5}\TypeLib
Class Name: <NO CLASS>
Last Write Time: 130716 - 22:13
Value 0
Name: <NO NAME>
Type: REG_SZ
Data: {00020424-0000-0000-C000-000000000046}
Value 1
Name: Version
Type: REG_SZ
Data: 1.0
... and in particular, the section 70% of the way through titled, Managing Settings Made by PCA. As you might have guessed (if not, let me emphatically stress so here) Windows is always a 'piece of work' in progress. CC scoops, first run, right after Windows installs, a host of tlb, etc. entries. All the flag in CC asserts is that the software/script device is not currently doing anything. Regarding Cmicnfgp.cpl, PCA has set it's own flags. The item is not a threat. Like all the tlb's etc. that CC has flagged for deletion. Let PCA do what it does best, namely manage. Don't blame CC. But now you know! As you gaze vacantly at Scan for Issues digs, right click any selected item (s) and notice that you can select: "Add to Exclude List". Then you can actually click Options / Exclude, and see how careful and perhaps prodigious CC permits. Perhaps a good policy for CCleaner (third party software), is install and run right after you run Windows Installer. Select and exclude just about everything. THEN notice as you explore, and poke around how much garbage the extra sensitive CCleaner can kick out of your way. Agree?