Can you post a screenshot?  We are unable to reproduce here.

Also include version of IP?

Follow up - really confused now!

In going back to do the screenshot (and having re-applied the Yuumenco IconPackage yet again), I find that all the folders appear to have the following Icon set:

D:\Public\Documents\Stardock\IconPackager\Yuuminco(R4)(XP-Vista)\Yuuminco Icon 20.ico,0

(I presume that the last re-application of the iconpackage did that, as they were definitely set to 'C:\Windows\system32\shell32.dll,3' before.)

I also discover that which icon (Yuumenco or standard Windows) is actually displayed depends on what size the icons are shown at. The windows standard icons only appear when Explorer is set to show MEDIUM icons. At other sizes they are all shown correctly.

I have spent a fair amount of time debugging IP on Vista 64 and so I have found some patterns.  Since I run the same IP on a Vista 32 laptop right next to mine, I am able to give some nice apples to apples comparisons.

On 32 bit IP, you can apply a new set of icons and the program will pick everything up, replace them, go on normally just fine.

On 64 bit IP, a new icon set will be "corrupted" the any previously applied one.  This can be the Windows native set OR the last custom set applied.

The only way I found to minimize this was to use IP to revert to the Windows set BEFORE applying a new icon set.  This also minimizes what I call "folder migration".

In folder migration, I will see newly created folders (and/or old ones as contents are added) show up in the previous and/or windows vista default folder icons.  This starts with one, then another, and another, until most directories are a patchwork of old and new icons.  There is no way to stop this that I can tell (since it is not an icon cache issue) and it seems to only happen on Vista 64, though I have never tested IP on XP64.

EDIT:  I believe I MAY have solved "folder migration".  There MAY be a conflict between IconDeveloper (also from Stardock) and IconPackager in the Vista 64 bit environment.  When I uninstalled ID and rebooted, directories with custom icons that were "refreshed" (by dropping any new file into them and then deleting it) now seem to be holding to the new icons.  On my Vista 64 system I am unable to find any corrupted/oldicon directories now.  Knock on wood.

I don't know if this also contributes to or causes the problems with icon packages properly refreshing in IP, under Vista 64 but it would be helpful at this point to know if the original poster has Icon Developer installed, yes? 

EDIT2:  Unfortunately, the old folders bug is NOT fixed.  Note to Stardock that this only seems to happen with Folders that contain ONLY other folders.  If there is a file of any kind in the root of the folder, the parent folder's icon remains customized.  It might be tied in with thumbnails in some way, as I can fix it by dropping a file into the root.  The folder icon gets fixed and I can then delete the file I added to the root...until it croaks again. 

Sorry for the red herring on Icon Developer.

Looks like a new version of IP is up on Impulse.  You might want to give that a try, reapply your icon package and let us all know if it helps.  I'm testing right now.  Good luck!

Edit:  Newest version has not addressed the creeping/changing/reverting folders icons issue under Vista 64. 

To get rid of the blank icons issue, I needed to revert back to the windows default icons, reboot, then apply a new icon pack.

If that doesn't work, try reverting back to default icons, uninstalling IP, rebooting, then reinstall and apply new icons.

The broken icons thing is a problem with the IP code from a few versions back.  The only way I could fix it was to take the revert and then uninstall steps above.

Good luck!

Been offline for a few days.

I did a system restore to fix the blank StartMenu / .exe icons.  I knew about that registry fix but could not find it in my internet searches. Thanks Shirley, I will save that now for future reference.

Well, although IP looked fine after a rebuilt icon-cache and updating to the next version (although I see 4.1 is out now), after a few reboots it is back to being a complete mess (see below).

I don't think it works very well at all, at least not in 64-bit Vista.

A BIG Eureka on "Folder Icon migration"! 

One thing I am finding is that SOME programs (for example, the Stacks Docklet running on ObjectDock plus) will actually launch a 32 bit version of Explorer (re: Explorer*32.exe) instead of the 64 bit Explorer.exe under Vista 64. 

In this case, if thumbnails have not been generated before, the thumbnails will be created with the old system default icons and not the new IP icons. 

I believe this may indeed be the root cause of the Folder Migration issue I was talking about earlier, as this behaviour also CHANGES icons, etc. when they've been addressed by the 32 bit Explorer.

At my end, I've eliminated/replaced some Stacks Docklets from my dock and/or replaced actual folders with shortcuts in the stacks shortcuts directories I have kept.  Apparently, Stacks Docklet will launch a FOLDER with Explore*32.exe but launches SHORTCUTS to folders with the 64 bit native Explorer.exe.

This also seems in line with the fact that ObjectDock, running under 64 bit OS, does NOT show the custom IP icons in the Flyout Menu docklet, but rather the 32 bit/old shell versions.

So, solutions might be...

A]  IP does its magic with both the 32 bit and 64 bit versions of Explorer on 64 bit Vista, so that either version of Explorer shows the correct icons no matter what program accesses it, and from whatever path.  This would solve the problem with native and third party docklets, but may not be possible for technical reasons I am not yet aware of (i.e. is it possible to modify both shells separately or does one take precedence)?

B]  Stardock compiles native 64 versions of the docklets, though that won't solve the issue with third party docklets.

C]  Something new or a combination/modification of A and/or B above. 

I hope this helps narrow this down.