Solved [ICONS] Won't change correctly despite numerous attempts

I have been using Stardock's IconPackager for a while, and after a lack of updates with that, it has eventually stopped working with most of the main icons within Windows 8.1.

I have followed many tutorials and have used RegEdit to change the icons, and have checked them with their 64 bit counterparts as well, and I have even edited both imageres.dlls.

So, now I am stumped as to what could possible be stopping this from working.



The empty folder works fine, but once something gets added in, then it breaks.
I have triple checked imageres.dll and the front / back / open / closed parts of the folder are changed correctly in both of the dlls using Resource Hacker (also checked each dll with IconsExtract).

Is there another dll that "assists" Windows 8.1 with icon images?



This is slightly related to the whole buggy icon image problem, but for some reason when I go to a folder that is in my Downloads folder, then the icon is shown on the This PC area in the navigation pane (I did remove the other folders from This PC and just left the drive folders using RegEdit), and the icon thati s displayed is wrong.





Anyways, I appreciate any help given.

Do you have a restore point to before this problem started ?

No.

I only started editing the .DLLs today, and I do have back ups of them.
I've been using IconPackager for the past year, but it has been having issues ever since upgrading to Windows 8.1, and if IconPackager does have an update, thne I can't get it because of my ObjectDesktop subscription expiring.


Should I edit all folder related icon groups in the DLLs besides 3 (closed), 4 (open), 5 (back), 6 (front), and 162 (filled)?

I can't help you with editing dlls.
I can do it, but I don't.
Simply because I don't want to mess things up.

I suggest a refresh or restore.
That of course is your decision.

hmm...would rather avoid doing a refresh

What about returning the folder registry keys to normal, reverting the changes to the .DLLs, clearing the icon cache, and then running the System File Checker?

xSean said:

hmm...would rather avoid doing a refresh

What about returning the folder registry keys to normal, reverting the changes to the .DLLs, clearing the icon cache, and then running the System File Checker?

Click to expand...

Good ideas.

You could also run

Dism /Online /Cleanup-Image /RestoreHealth

in an administrator CMD.

Ok, so something good but very strange happened while I was going through what I first said, and I think I know what the problem was.

So, after I returned IconPackager to its default settings, deleted both key folders of ShellIcons in RegEdit, replaced the imageres.dlls with their backups, ran a small batch file to clear the icon cache, and then restarted my computer....my icons are (for the most part) the way they should be.

It is very strange, but I think the problem is that IconPackager does something that is no longer needed to get the icons changed, and Stardock hasn't even made IconPackager fully compatible with even Windows 8.

Then combined with my 32 bit imageres.dll somehow having been edited prior to everything (without me ever doing so) has strangely made everything work.

Going to have to test this a bit more, and clear my icon cache multiple times to make sure that everything actually did get cleared (because I have ran into an Access is Denied message in the Admin CMD even when explorer was ended and checking the permissions).


Right now I am doing part of your suggestion, but first doing /ScanHealth.

Edit:
Now using /RestoreHealth


Edit2:
Finished /RestoreHealth, and now onto sfc /ScanNow

So, after a few days I finally have completely figured out the problem.

It was all due to IconPackager not creating an icon replacement for a filled icon (162), and then my crappy editing of an already edited (most likely by some program) IconRes.dll.

Ended up running into the problem again today, so I deleted the 5 and 6 strings in Shell Icons in RegEdit, and replaced the ImageRes.DLLs with the originals (before I edited) since they were repaired to the default state before, so now it is only loading all pieces of a full folder from the .DLL.