The Mystery of the Disappearing Pinned Shortcuts
Here is another great article by my Colleague Jacques Bensimon. Be sure to follow him on Twitter. (@JacqBens)
I don’t know if many of you have run across this issue, but it has certainly been kicking my butt ever since we started creating user profiles for Windows 7 and 2008 R2. The mysterious behavior is easy enough to describe:
(1) we create a template (or default, or mandatory) profile containing specific pinned items in the Start Menu and/or the Taskbar (a slightly tricky proposition, but a frequent customer request now that Microsoft has kindly eliminated the display of Start Menu root shortcuts and done away with the Quick Launch toolbar … and don’t get me started on the subject of Windows 8!),
(2) the profile works as designed for a while, i.e. over several days/weeks, users of that profile log on to multiple machines running the same image and consistently get their pinned items, until
(3) one day, on one or more (or all) machines, users logging on briefly see their Taskbar pinned items but, within a matter of seconds, they disappear (the icons, not the users – that would be a much less serious issue J). If the users now look at the Start menu, they’ll see that those pinned items have also disappeared.
Further examination of a user’s profile at that point reveals that this is not merely a question of pinned items not being displayed: they are well and truly gone! The actual shortcut files have been deleted from the profile (i.e. from %AppData%\Microsoft\Internet ExplorerQuick LaunchUser PinnedStartMenu and …User PinnedTaskbar) and the corresponding Registry entries have been reset to “virgin” values (various entries named “Favorites…” at keys HKCU\Software\Microsoft\WindowsCurrent\Version\Explorer\StartPage2 and …ExplorerTaskband).
Investigating this behavior was simplified by the fact that, as mentioned at the top, it was observed not only on Windows 7 but also on RDS/XenApp servers running Windows 2008 R2, so it was possible to monitor system activity (using SysInternal’s ProcMon) from an admin session while an affected user account was logging on. Two facts emerged from this monitoring:
(a) Explorer.exe itself, as it started within the user’s session, was committing the heinous “pinnicide” (i.e. it deleted the shortcuts and reset the Registry entries – no other process was involved), and
(b) it did so soon after several intensive rounds of querying the values at the two user Registry keys already mentioned above (HKCU\Software\Microsoft\WindowsCurrent\Version\Explorer\StartPage2 and …ExplorerTaskband) as well as those at the machine Registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage, with what looked like a particularly unhealthy obsession with a REG_DWORD entry named FavoritesRemovedChanges found under all three keys in question.
Although I can find no authoritative reference on the meaning or purpose of these FavoritesRemovedChanges values, the name suggests some sort of shortcut change and/or deletion counter. This guess was bolstered by a review of the machine’s application installation and update reports created with the (incredibly useful and absolutely indispensable) Total Uninstall installation tracker (I’ll have to write about it someday): this revealed that the three FavoritesRemovedChanges values always seem to match each other, to always change in lockstep, and to increment by exactly the number of Start Menu shortcuts modified (or simply overwritten) by a setup operation (there may be other scenarios under which these values will change, but I didn’t capture any). In any case, it quickly became apparent that machines on which pinned items were suddenly being deleted at logon were those on which some application or system component update had been performed, causing the HKLM instance of FavoritesRemovedChanges to be incremented and as a result to no longer match the corresponding HKCU instances in the Registry hives of users logging on following the image update. I can’t say for sure whether this is an Explorer bug or intentional behavior (a paranoid “Start Menu shortcuts have changed in your absence so I no longer trust your nasty old pinned items” mechanism), but I can say this: if the user’s HKCU FavoritesRemovedChanges entries are modified to match the HKLM entry at logon before Explorer starts (e.g. from a logon script), the pinned items are never deleted and the issue is eliminated.
Here’s a batch command that will accomplish this quietly:
For /F “tokens=3” %%v in (‘Reg Query HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage /v FavoritesRemovedChanges 2^>NUL: ^| Find /i “Fav”‘) do (
For %%k in (StartPage2 Taskband) do Reg Add HKCU\Software\Microsoft\WindowsCurrent\Version\Explorer\%%k /v FavoritesRemovedChanges /t REG_DWORD /d %%v /f >NUL: 2>NUL:
)
Careful: On a 64-bit platform, the above code fragment will not work as is if the batch file runs under the 32-bit CMD.exe (because the attempt to query something under HKLM\Software\ with the 32-bit Reg.exe will be redirected to HKLM\Software\Wow64\32\Node – see this post for details on this and on what follows). You could change “Reg Query …” above to “%SystemRoot%\SysNativeReg Query …” to force the use of the 64-bit Reg.exe, but then the code would fail when running under the 64-bit CMD.exe (because “SysNative” has no meaning for 64-bit processes). You think you always know whether your batch file runs as a 32-bit or 64-bit process? Consider this: on a TS/RDS server, if this script runs as a child of UsrLogon.cmd (the “application compatibility” root script), then it will run as a 64-bit process … until you add XenApp to the mix, at which point Citrix, ever helpful, will cause the 32-bit CtxHide.exe to launch UsrLogon.cmd, causing it to run as a 32-bit process (in fact, a different instance of UsrLogon.cmd will now run, the one found in %SystemRoot%\SysWow64 rather than the one in %SystemRoot%\system32\, so be sure to always keep them identical). But wait, even with XenApp installed, the script might still sometimes run as a 64-bit process: when? When you test it manually from Explorer or from a CMD prompt, that’s when J. So, bottom line, practice defensive scripting and make sure your script will run correctly regardless of platform or “bitness”, as follows:
Set TrueSys=%SystemRoot%\\system32\
If Defined PROCESSOR_ARCHITEW6432 Set TrueSys=%SystemRoot%\SysNative
For /F “tokens=3” %%v in (‘%TrueSys%Reg Query HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage /v FavoritesRemovedChanges 2^>NUL: ^| Find /i “Fav”‘) do (
For %%k in (StartPage2 Taskband) do Reg Add HKCU\Software\Microsoft\WindowsCurrent\Version\Explorer\%%k /v FavoritesRemovedChanges /t REG_DWORD /d %%v /f >NUL: 2>NUL:
)
Note that it doesn’t matter which flavor of Reg.exe is used to modify the HKCU entries: as the above-mentioned post stresses, all aspects of a user profile look identical to 32-bit and 64-bit processes.
Later,
Jacques. (@JacqBens)