Solved over a month ago, patio? Perhaps you didn't quite get the message when I mentioned that "the numerous registry hacks and other suggested fixes did not help in my case."
Key words here are "in your case" you'll note the original poster, the one with this problem, stated almost a month ago:
http://www.techsupportforum.com/microsoft-support/windows-vista-windows-7-support/503452-solved-icons-desktop-have-missing-file-icon-instead-shortcut-arrow.html#post2837395
The above link solved my problem
IE: their problem was solved.
The value of outlining alternate ways to resolve a problem is that if one way doesn't work then another might.
Indeed, and I definitely agree. But look at the link they said solved their problem.
You'll note something interesting about the thread, in that you have also recently posted there. A month after they already solved their problem, and secondly, that the advice you gave isn't that much different operation-wise from the help they got that solved their problem. The only difference is that you've managed to find an alternate way to effect the same changes.
The helper there guides them through the following steps:
1.)fixing the LNK registry entries (to make sure that the shell Link overlay handler is properly installed)
2.)deleting the icon cache (which sort of confirms my suspicion that the system will use a previously stored icon cache on reboot).
3.)Rebooting
4.)
5.) Profit.
Your solution is effectively a ham-fisted way of doing step 2- there is no confirmation that the link overlay handler is properly installed, and changing the size back and forth is pretty much just forcing it to rebuild the system image list and the icon cache. On the other hand, your solution has the advantage of not necessarily requiring a reboot (with the other solutions, a reboot was required in order to force the system image list to be re-created again. It's generally best to perform a reboot, applications have this weird habit of caching away handles to imagelists. Some of them are like scavengers who keep a bunch of imagelist handles in a hidey hole, refusing to accept that they look awful. (some explorer replacement programs do this for some reason).
Does your solution require a REG script? No, but it also doesn't fix the problems that the reg script they provide are intended to fix (broken/missing Link overlay handlers) so the functionality isn't the same. Your method merely replaces the command prompt->delete icon cache->reboot step. Certainly a good alternative that can be given in an active thread but to bump a month old topic (two month-old topics, if you count the other forum) with a ham-fisted way of doing the same solution the Original Poster used isn't about to win you any gold stickers.
How and why this happens is unknown
The Overlay image is a normal icon that is drawn over top of the desktop icon- for windows 95, for example, the icon was was still 16x16, 32x32, etc, but only occupied the lower left corner, so, when windows used ImageList_DrawOverlay (or simply drew the icon over top of the icon for the target) it would appear on top. This didn't change a whole lot since, except now it blends in with the target icon using alpha channels.
This problem can only be caused by a few specific circumstances:
The Icon handle to the overlay icon becomes null,points to the wrong index, or another application has literally removed it from the system imagelist. I've seen this before, since some programs have this complex where they suddenly own the system imagelist and put whatever they please in it. This of course makes things rather confused to the system (which, not surprisingly, actually owned the imagelist, thus the name) when it tries to draw the overlay using the same Image index that it acquired when it first added it. Instead of drawing the overlay icon as it expected, it ends up overlaying some other icon that the rogue program put on the imagelist. This is more or less constrained to very specific conditions and environments- usually each application is now given a handle to a copy of the system imagelist, rather then a handle to the actual imagelist itself, so this is more a problem in the 9x era.
The Icon overlay is drawn using a Shell Icon handler, Which essentially is a plugin used by explorer. Now, explorer plugins like icon handlers aren't just used by explorer- other applications often use SHGetFileInfo() to acquire information about files, including their associated icons. when this function is called, the Shell (to which the function belongs, thus the SH at the beginning) will use the various Icon handlers to try to create the icon. Of course, this particular behaviour can be changed using various SHGFI_* flags. For example, you can force it to have the link overlay, request the Index into the system imagelist Of the shortcut overlay, or specify that the file should be selected. An application can also opt to only go by the file extension (Some icon handlers might open the file to determine the appropriate icon, this flag basically says "give me an icon, and no dilly dallying Mr.Shell".
Clearly, there is a lot that can go wrong here. First, what happens if there are Problems with the COM subsystem? Then, all of a sudden none of the browser extensions, including icon handlers, works. Also, the system imagelist sits in RAM for a very long time (even in copies) and if a naughty shell extension changes it (often by accident) that change will be reflected in the other extensions. (I said that each application gets a different copy of the list, but in this case these are COM Dll's loading in process with explorer so they all get given the same "copy" that explorer gets). So one buggy extension= major problems for all of them. This is sometimes the result of malware, actually, since malware is in general written by lobotomized COBOL programmers in very dark rooms.
The reason your solution of changing the DPI fixes the problem is because when you do so and apply the change, the shell broadcasts WM_SETTINGSCHANGE to all top-level windows. In response to this message, and determining that the default icon size has changed(as a result of the DPI change), it rebuilds it's system Image list to match the new size.
deleting the icon cache doesn't have an effect, because the icon cache being deleted merely means it will be regenerated as icons are requested- the overlay icon is still invalid or missing from the imagelist so the rebuilt icons are still not correct. One would need to reboot after deleting it to have the intended effect.
Registry "hacks" don't work because they either require a reboot or are entirely misguided. The problem is not with the data that was originally loaded but usually with the system imagelist itself, which needs refreshing. a common tactic is to suggest using something that "rebuilds the icon cache" so to speak, which usually ends up being something to the effect of
SendMessage(Handle, WM_SETTINGCHANGE,SPI_SETNONCLIENTMETRICS, "WindowMetrics");
With the idea being that the shell will detect the change and rebuild the icons. However, it only does so if it detects the icon size has changed- either because of the setting you note changing here (DPI) or because the pixel value in HKCU\Control Panel\Desktop\WindowMetrics in the "Shell Icon Size" value. One tactic is to change this by moving it up one pixel, invoking the program/code that ends up calling sendMessage, and then bumping it down. This rebuilds the system imagelist from scratch using the pixel-more value and then rebuilds it using the standard size. You usually can't just say "rebuild all the icons in the same size" because then the shell says to itself "haha! I already have a nice cache of icons in that size, That was fast!" Despite said cache/system imagelist being incorrect.
These sorts of icon problems, especially relating to the system imagelist, were rather common with Windows 9x. Sometimes you would have word documents with a Photoshop icon or something equally random. the tweakUI "rebuild icon cache" often works, I think it employs something to the effect of "change the size, rebuild, revert the size, rebuild" as I noted, since the icons clearly redraw on the desktop twice during the operation.
