Windows 7 Desktop Icons and Shortcuts Disappearing

Originally published 30 November 2011 / Filed under Windows / Server

Archived note. Originally published 30 November 2011 on iishacks.com. It describes Windows 7 and the System Maintenance troubleshooting pack as they behaved at that time and is preserved here as a record. Windows 7 is long past end of support. Verify against current vendor documentation before applying any of it to a live system.

The recovered note

Desktop shortcuts going missing has more than one cause, and the correct repair depends on which one it is. If every icon has gone, they have either been deleted or desktop icons have been switched off — that is Method 1. If some icons look wrong, are missing thumbnails, or the desktop does not refresh when new items are placed on it, the icon cache is likely corrupt, which is Method 2. If the icons that vanish are network shortcuts, broken local shortcuts, or shortcuts to files on a removable USB drive, System Maintenance is to blame.

Method 3 is the quick answer to that last case, and its drawback is that it disables all system maintenance; it is worth using to confirm the diagnosis rather than as a permanent state. Method 4 is the one the original note recommended, because it is less of a band-aid: it raises the threshold Windows applies before it clears away broken shortcuts.

Method 1 — all icons missing from the desktop

Right-click an empty part of the desktop, hover over View, and confirm that Show desktop icons is ticked. It is a per-user display setting, and both users and installers were capable of clearing it.

Method 2 — rebuild the icon cache

Open Notepad, paste the following, and save it as IconFix.bat:

taskkill /F /IM explorer.exe
cd /d %userprofile%\AppData\Local
attrib -h IconCache.db
del IconCache.db
start explorer.exe

The batch file closes the shell, clears the hidden attribute on the cache database, deletes it and starts the shell again. Windows rebuilds IconCache.db on the next launch, so icons redraw slowly for a short while afterwards. That is expected, not a sign the fix failed.

Method 3 — disable System Maintenance

Start menu, then Control Panel, then System and Security. Under Action Center click Troubleshoot common computer problems, then Change settings on the left. Under Computer Maintenance select Off, and under Other settings clear both tick boxes.

That switches off the whole scheduled maintenance run, not only the part that removes shortcuts. It is a clean diagnostic: if the icons stop disappearing, the cause is confirmed and Method 4 is the setting worth changing.

Method 4 — modify the scheduled task files

Windows 7 applies a broken-shortcut threshold of four. Advice of the period sometimes suggested deleting the script outright; raising the threshold is safer and still lets system maintenance run.

1. Go to C:\Windows\diagnostics\scheduled\Maintenance.
2. Right-click TS_BrokenShortcuts.ps1, choose Properties, then the Security tab, then Advanced and the Owner tab. The current owner shows as TrustedInstaller. Click Edit, set Change owner to the administrative account in use, and confirm through the dialogs.
3. Back on the Security tab click Edit, select the Users group and grant Modify.
4. Right-click TS_BrokenShortcuts.ps1 and select Edit. On line 44, find -gt 4)) and change it to -gt 25)) to raise the threshold to twenty-five broken icons. Adjust further if more are expected.
5. Unused icons are handled by a second script. To change that behaviour too, edit TS_UnusedDesktopIcons.ps1 the same way: find -gt 10 on line 50 and raise it.

What the System Maintenance task was doing

Windows 7 shipped a set of troubleshooting packs and a scheduled maintenance run that executed some of them unprompted. One pack walked the desktop, resolved every shortcut it found, and counted those whose targets did not answer. Above a small threshold it treated the desktop as cluttered with dead links, removed them, and reported the tidy-up through Action Center.

The intent was reasonable for the machine it was designed around. A home computer accumulates shortcuts to uninstalled programs and long-deleted files, and nobody misses them. The design rests on one assumption, and that assumption is the whole problem: that a shortcut which does not resolve right now is a shortcut whose target is gone for good.

Why unreachable network shortcuts were the common trigger

On a domain-joined machine, a large share of desktop shortcuts do not point at local files at all. They point at UNC paths on file servers, at mapped drives, at departmental shares placed there by a logon script or by policy, and sometimes at removable media. Each of those targets is unreachable under perfectly ordinary conditions: a laptop off the VPN, a file server restarted inside its maintenance window, a USB drive that is not plugged in.

A threshold of four is trivially exceeded in that environment. A user with shortcuts to five departmental shares who works from home on the day maintenance runs loses all five at once, with no prompt and nothing obviously to blame.

It also repeats. Where the shortcuts are re-created at logon by a script or by folder redirection, they come back, the machine is offline again the following week, and they are removed again. That cycle is the diagnostic signature: the losses are periodic rather than random, they correlate with being off the network, and only shortcuts with remote targets are affected.

Editing a signed in-box script is a real trade-off

Method 4 is the better repair of the four, and it still carries costs, because it modifies a file the operating system considers its own.

The diagnostics directory is owned by TrustedInstaller, which is what stops administrative accounts from altering in-box components by accident. Taking ownership and granting Modify to the Users group does not undo itself when the edit is finished: it leaves a system directory with weakened permissions for every account on the machine. Ownership and that access control entry are worth restoring afterwards.

The second cost is that the change is not durable. Servicing replaces in-box files, so a package that updates the diagnostics content restores the original script and the original threshold, and nothing announces that it has happened. The symptom returns months later on a machine somebody remembers fixing — a harder problem than the one that was fixed.

The third is that it does not scale. It is a per-machine file edit with no inventory of where it was applied, no way to report on it and no way to reverse it centrally. On an estate of any size, that is a maintenance liability rather than a configuration.

None of that makes Method 4 wrong — it buys quiet, it is reversible, and it beats deleting the script. It is a stopgap while the underlying arrangement is changed, so that desktops stop carrying shortcuts to targets which are routinely unreachable.

Reading it today

The line numbers above belong to the Windows 7 files of 2011 and will not match a current system. The shape of the problem outlived them: an automated tidy-up that infers permanence from one failed check, running on a schedule, against resources that are intermittently reachable by design. The question to ask of any such task is what it assumes about the network when it runs.

Other notes from this period sit under Windows and Server. The note on disabling User Account Control in Windows 7 covers another Windows 7 default administrators regularly turned off, and reducing the Windows 7 WinSxS folder size deals with the servicing store that replaces files like the one edited above. The full index is at post archives, and the archive homepage explains what this collection is. For support dates the Microsoft product lifecycle documentation is the current reference, and general troubleshooting guidance lives in the Windows Server troubleshooting documentation.