Although the default icon for a shortcut is the icon of the target, you can override that

A customer reported that a shortcut they deployed to their employees' desktops was triggering unwanted server traffic.

My customer deploys a shortcut on %ALLUSERSPROFILE%\Desktop, and this shortcut points to an EXE file on a remote server. Once a local user logs on, the computer will try logging onto the remote computer to query information and generate a login failure alert on the server.

Is there any way to stop Explorer from querying the shortcut information?

Fortunately, the customer provided context for the question, because the question the customer is asking doesn't actually match the scenario. The customer doesn't want to stop Explorer from querying the shortcut information; the customer just wants to stop Explorer from contacting the server to get the icon.

The default icon for a shortcut is the icon of the target, and in order to get that icon, Explorer needs to contact the target. But you can override that default. Programmatically, you call IShellLink::SetIconLocation; interactively, you view the shortcut's properties and click Change Icon.... In either case, set it to an icon that doesn't reside on the server. Save the changes and deploy the modified shortcut.

Comments (17)
  1. asf says:

    I problem I have seen with IShellLink::SetIconLocation is that the shell tries to be nice and automatically transforms c:program files… to %programfiles% even on x64 and you end up with a broken icon for x86 apps…

  2. Dan Bugglin says:

    asf sounds like a compatibility shiv, I would wonder if an application manifest would turn off that behavior.

  3. JustAQuestion says:

    What about ShellIconCache? What does it do exactly? I thought it existed specifically to mitigate issues like the one in question.

    [It mitigates but does not remove the problem. (1) You still have to read the icon from the network to put it in the cache, and (2) it may fall out of the cache. -Raymond]
  4. Joshua says:

    Ah yes, law of unintended consequences. In retrospect, the best place to store the icon of a shortcut would have been in the shortcut file itself, but that was not known when this was designed.

    [That creates its own problems, because it means that the icon is "locked in" at shortcut creation time. "Why do some of my HTML shortcuts have the Firefox 3 icon, others have the Firefox 4 icon, and still others have the IE icon? Even worse, when I double-click them, they all open in Firefox 4, even the IE ones." -Raymond]
  5. Mc says:

    Been there done that.  I deployed a installer that created a desktop shortcut pointing to a local executable,  but the icon image was accidentally pointing at the server.   Everything worked fine and nobody noticed.    Two years later the server gets decommissioned then after a while lots of complaints about missing icons…  

  6. EricM says:

    Having the icon file included in the shortcut itself doesn't mean you're locked in at all. Not to put too fine a point on it, but Macs have a good UI for setting icons. I say this knowing full well this will devolve to Mac vs PC arguments :(

    Right now, depending on which media player I installed last, the exact same problem Raymond describes happens to my media files. I'm fairly certain users are already in some kind of icon hell.

    [But if it doesn't lock the icon, then the icon wasn't in the shortcut file after all. -Raymond]
  7. Random832 says:

    "Right now, depending on which media player I installed last, the exact same problem Raymond describes happens to my media files." No it doesn't. All of your files of the same type [where "type" is e.g. "AVI" or "MP3", not "media files"] have the same icon. And all of your files open with the application implied by the icon.

    The Mac (I assume you mean mac classic, I don't know what OSX does) way, where you can copy an icon to the clipboard and paste it in file properties, puts the icon in the file [I think it's the actual file, not the alias – this works because all mac files can have resources] as a resource. The icon will not change if you uninstall the program that can open the file, or install a new program that opens that kind of file. (Even one that takes over the same creator code, such as a new version of the same program). So, yes, you are locked in to that icon.

  8. Joshua says:

    Figures that what I almost never use would be what breaks.

  9. bzakharin says:

    How is using IShellLink::SetIconLocation not the same type of lock in as storing icons in shortcuts? Sure it has narrower scope, but depending on what you're doing with it, could cause exactly the problem Raymond describes.

  10. Medinoc says:

    One of my pet peeves is installers that create shortcuts with *an icon on the CD itself*. Yes, it exists; some people apparently assume one never switches disks.

  11. Rick Brewster says:

    Boris, because the icon that the shortcut points to ("by reference") can change. You aren't copying the icon's bitmap into the shortcut ("by value").

  12. Cheong says:

    > That creates its own problems, because it means that the icon is "locked in" at shortcut creation time.

    I think if the "lock in" is only provided for paths that's clearly network path, people would understand. The "Change Icon" button can be used to refetch the icon if it's needed to refresh (handly to put in online help).

    I think most people concern more about performance than "icons that doesn't refresh". And those who'd really concern are likely to be capable of remembering the new rule once it's been told.

    [Except that you have just created a behavior change for people who use a network-based profile. None of their icons work the same as local or roaming profiles. -Raymond]
  13. Ens says:


    We weren't talking about a performance issue.  This is about avoiding login failure alerts at the server.

    It's not some blocking call and there is an icon cache already noted.  The user isn't really going to see any real performance problems from this — being unable to see the icon for a couple seconds would be an extreme circumstance.  You could maybe come up with circumstances where a crappy server or crappy network is DOS'd by a bunch of machines booting up simultaneously, but that's not going to be an issue for "most people", whereas locked in icons would.

  14. Cheong says:

    @Ens: Yes, it's not about performance. I'm just talking about whether "embedding the icon to shortcut file itself if target is EXE on network" would be acceptable / could be justified.

    Also note that any access to non-local resources bears performance cost. Since even the cache may miss, performance benefit would be another reason to favour it behave that way.

  15. prunoki says:


    Around me people accept the things they can understand: it appears slower because it is on the network is fine. Firefox 3 icons opening Firefox 4 is a lot harder to explain and understand. But maybe that is only us.

  16. Adam V says:


    "Figures that what I almost never use would be what breaks."

    Sounds pretty good to me, considering the alternative is "what I use everyday is what breaks."

  17. David Walker says:

    asf's comment (the first comment) was interesting.  Is this a reproducible bug?  If so, asf, you could file a bug report on it.

Comments are closed.

Skip to main content