图标变白快捷方式打不开怎么办？图标缓存位置与lnk图标字段逐项实测

桌面上的程序图标变成一张白纸、开始菜单里一排软件共用同一个通用图标，可双击照样能打开——这些症状看起来一样，原因却在四条不同的链子上。微软专门讲这个症状的排错页把判据写得很直白："Application shortcuts on the desktop, Start menu, and taskbar show blank icons. This issue can affect both built-in (inbox) and third-party applications. However, double-clicking the blank icon can still open the application."，原因句也只给了两条："The issue is related to problems with the icon cache and the IconHandler subkey."。本文把这两条线索在本机拆开量了一遍：112 个 .lnk 快捷方式的图标字段全部读出来、52 个图标文件逐个探过、四个自造快捷方式逐像素对过、图标缓存目录下 15 个文件逐个称过重量。量完的结果和多数网传教程不一样：图标序号写错不会让图标变白，真正让它变白的是序号指向的那个文件没了；而微软那条删除命令删掉的缓存文件，只有本机真正在用的缓存的千分之一点五。

信息核验时点：2026-11-03（取证机为 Windows 10 专业版，内部版本 10.0.19045；引用的微软「图标显示为空白」排错页更新于 2026-02-12，[MS-SHLLINK] 外壳链接格式页更新于 2025-06-11，ExtractIconEx 与 SHGetFileInfo 两个 API 页更新于 2024-02-23；文中 112 个快捷方式的字段普查、四张自造快捷方式的逐像素比对、图标缓存目录下 15 个文件的体积与最后写入时间、IconHandler 链上四个键的默认值，均在这台机器上以标准用户身份只读取回并留存原始输出；本文没有在这台机器上删除缓存、也没有结束资源管理器进程）

一个快捷方式显示哪张图，是由文件里哪几个字段定的？

图标不是「资源管理器画上去的」，而是按一条固定顺序查出来的。这条顺序的第一站写在 .lnk 文件自己身上：微软的外壳链接二进制格式规范 [MS-SHLLINK] 2.1 节把文件头定义为 76 字节，其中和图标直接相关的只有一项，逐字是 "IconIndex (4 bytes): A 32-bit signed integer that specifies the index of an icon within a given icon location."；而「given icon location」那个位置，是同格式 2.4 节 StringData 结构组里的 ICON_LOCATION 字段，规范原文 "ICON_LOCATION: An optional structure that specifies the location of the icon to be used when displaying a shell link item in an icon view. This structure MUST be present if the HasIconLocation flag is set."。换句话说：图标位置是一个字符串字段，图标序号是文件头里的一个有符号整数，两者配成一对用；字符串里那个逗号后面的数字，最终要和文件头里的序号一致。

本机把四个开始菜单目录和两个桌面上的 .lnk 全走了一遍，共 112 个文件（当前用户桌面 6、公共桌面 14、机器级 Programs 72、当前用户 Programs 20）。文件头的两条硬约束全部满足：HeaderSize 等于 0x0000004C 的有 112 个，LinkCLSID 等于 00021401-0000-0000-C000-000000000046 的有 112 个——后者正是规范里写死的 "This value MUST be 00021401-0000-0000-C000-000000000046."，也正好是下面 IconHandler 那条链上要用的同一个 GUID。

那行 HasExpIcon 值得单独说一句，因为网上流传的一种「读快捷方式」脚本按这个位判断图标路径要不要展开环境变量，本机的数正好相反：置了该位的 23 条，图标串全是绝对路径（公共桌面上的 Google Chrome 和 Microsoft Edge 两条就是典型，标志位设着、串里一个百分号都没有）；串里带 %windir% 这类变量的 46 条，一位都没设。所以拿标志位去决定要不要调用环境变量展开函数，在这台机器上会把 69 条全判错。可靠的判据只有一条：读出来之后看串里还有没有百分号，本机展开后残留百分号的有 0 条。

序号写错会让图标变白吗？本机 112 个快捷方式给的答案是否定的

先明确规则。微软 Registering Programs with Client Types 页对 DefaultIcon 那个「文件路径,序号」写法给了逐字口径："If IconIndex is a positive number, the number is used as the index of the zero-based array of icons stored in the file. For example, if IconIndex is 1, the second icon is loaded from the file." 以及 "If IconIndex is a negative number, the absolute value of IconIndex is used as the resource identifier (rather than the index) for the icon. For example, if IconIndex is -3, the icon whose resource identifier is 3 is loaded from the file."。.NET 的 Icon.ExtractIcon 页同一件事说得更短："Positive numbers refer to an icon index in the given file. Negative numbers refer to a specific native resource identifier in a PE (.dll, .exe) file."

负数是资源编号，不是下标。这条规则决定了本机那 18 条负序号里有 3 条注定取不到图：讲述人（narrator.exe,-1）、屏幕键盘（osk.exe,-1）、iSCSI 发起程序（iscsicpl.dll,-1）——这三个文件里的图标是「命名」的而不是「编号」的，不存在资源号为 1 的那张图。可它们在开始菜单里的图标一直是正常显示的。原因在 ExtractIconEx 这个取图函数的返回值语义上，微软 ExtractIconExW 页（2024-02-23 更新）逐字写着："If this value is –1 and phiconLarge and phiconSmall are both NULL, the function returns the total number of icons in the specified file."——-1 是个特殊值，专用于「问总数」。本机实测正是这个形状：对 narrator.exe 传 -1 并给出真实句柄数组，函数返回 3（该文件的图标总数），两个句柄却都是空；osk.exe 返回 1、iscsicpl.dll 返回 2，同样一个句柄都不给。

这就产生了本文最重要的一条判据纠正：网传那段「图标坏了」的检测代码长这样——把两个句柄参数当成输出数组传进去、最后一个「取几个」传 0，然后看返回值是否为 0。这个写法测的是「本次成功取出了几个」，永远返回 0。官方 Return value 段写得很清楚："If the nIconIndex parameter is any value other than -1 and either phiconLarge or phiconSmall is not NULL, the return value is the number of icons successfully extracted from the file."。本机同一段代码跑出「图标总数为 0」的记录有 60 行（同一软件在机器级和用户级开始菜单各有一份快捷方式，重复行都算进去了），而把两个句柄参数改回真值、把「取几个」传 1，同一条记录立刻返回 2 个大图标加小图标句柄。正确的问总数姿势，和「问这一格能不能取到图」的正确姿势，是同一段代码里的两个入口——把句柄参数声明成普通指针、传零，就得到总数；声明成真输出、传 1，就得到句柄：

$src = @'
using System;
using System.Runtime.InteropServices;
public static class IconProbe {
  [DllImport("shell32.dll", EntryPoint="ExtractIconExW", CharSet=CharSet.Unicode)]
  static extern uint Probe(string file, int idx, IntPtr big, IntPtr small, uint n);
  [DllImport("shell32.dll", EntryPoint="ExtractIconExW", CharSet=CharSet.Unicode)]
  static extern uint Fill(string file, int idx, out IntPtr big, out IntPtr small, uint n);
  [DllImport("user32.dll")] static extern bool DestroyIcon(IntPtr h);
  public static uint Count(string file) {                 // 问总数：两个句柄传 NULL
    return Probe(file, -1, IntPtr.Zero, IntPtr.Zero, 0);
  }
  public static bool Has(string file, int idx) {          // 问这一格：句柄传真数组
    IntPtr a, b;
    Fill(file, idx, out a, out b, 1);
    bool ok = a != IntPtr.Zero || b != IntPtr.Zero;
    if (a != IntPtr.Zero) { DestroyIcon(a); }
    if (b != IntPtr.Zero) { DestroyIcon(b); }
    return ok;
  }
}
'@
Add-Type -TypeDefinition $src
[IconProbe]::Count("C:\WINDOWS\system32\imageres.dll")        # 本机返回 337
[IconProbe]::Has("C:\WINDOWS\system32\Taskmgr.exe", -30651)   # True
[IconProbe]::Has("C:\WINDOWS\system32\Taskmgr.exe",  30651)   # False：正数会越界

微软那页对句柄本身还有一句收尾要求："When they are no longer needed, you must destroy all icons extracted by ExtractIconEx by calling the DestroyIcon function."，所以上面那段用完就释放。

判据修好之后，本机 17 组「不同的图标文件加负序号」里有 3 组取不到句柄，14 组取得到。取不到的这 3 组屏幕上显示的是什么？逐像素比对给出答案：iSCSI 发起程序那条快捷方式显示的图片，和 iscsicpl.dll 的第 0 张图加箭头几乎完全一致——排除左下角的箭头区域后，855 个像素里只差 41 个，而且散在边缘（同一张图走不同缩放路径的抗锯齿差）；换成第 1 张差 649 个，换成目标程序 iscsicpl.exe 的第 0 张差 213 个。外壳在序号取不到时，悄悄回落到同一个图标文件的第一张图。讲述人和屏幕键盘同理：它们的 .lnk 显示图和「直接看目标程序的图标再加箭头」逐字节相同（差的像素正好只落在左下角那块，共 169 个像素）。

结论很直接：序号写错，最多是「显示成另一张图」或「显示成这个文件的第一张图」，不会变白。所以「图标变白」这个症状的排查顺序里，改序号应当排在很后面。

图标真的变成通用图，本机复现出的是哪几种样子？

在只读前提下，可以不改任何系统设置就把各种坏法复现出来：在当前用户目录下的一个临时文件夹里造 4 条快捷方式，各自把「目标」和「图标」设成在或者不在，然后用外壳的取图接口把它们的大图标（32×32）取出来，逐字节算哈希并互相比对。四条的结果分成两种完全不同的图：

这张表里有三件事值得记下来。

第一，目标死不死，跟图标长什么样无关。「目标丢了」和「一切正常」这两条快捷方式的大图标哈希一模一样，小图标也是同一张。所以看到图标还是熟悉的程序图，不能推断目标还在；看到图标变了，也不能推断快捷方式坏了。反过来说，「图标白了但双击能用」这个微软列为症状的组合，在本机完美复现——图标早就落到通用图上了，双击照打。

第二，图标文件不在时，外壳给的是「通用文档」那张图，不是白纸。本机的通用文档图与「一个没有关联的未知扩展名文件的图标」逐字节相同（只差左下角那块 169 像素的箭头）。这意味着用户口中的「变白」在多数情况下其实是「变成了系统通用图」：文件还在、目标还在，只有 .lnk 里那串图标路径指向的东西没了。

第三，同一个「取不到」在 exe 和 dll 上的落点不一样。对本机 notepad.exe（只有 1 张图）填 1、99、-1、-99 四种坏序号，四种渲染结果逐字节相同，都是那张空白应用窗口图；而给 imageres.dll 填 337（该文件共 337 张，下标 0 到 336）或者一个荒谬的 -99999，结果和「通用文档图加箭头」逐字节相同。dll 越界出的是文档图，exe 取不到出的是应用图——两种都不是白，但都很容易在截图里被叫成「图标没了」。

顺着第二点就能找出本机最容易批量中招的真实风险：图标文件放在哪儿。把 52 个自定义图标文件按物理位置分堆，落在 C:\WINDOWS\System32 的 34 个（服务 38 条快捷方式），Program Files 下 9 个（15 条），当前用户 AppData 下 3 个（7 条），C:\WINDOWS\Installer 的安装缓存目录里 1 个（4 条），System32 之外其他 Windows 目录 3 个，SysWOW64 下 2 个。其中 11 条快捷方式的图标不在程序自己的安装目录里，而在「清理软件最爱动」的缓存目录中：4 条指向 C:\WINDOWS\Installer\{一串 GUID}\AppIcon，3 条指向当前用户 AppData 下一个按哈希命名的 .ico 文件，2 条指向用户目录里的安装程序缓存图标，2 条指向 Windows\Installer 里另一份缓存。这几类目录由安装程序自己维护，一旦被人手工清空或被「腾空间」类工具当垃圾删掉，对应的快捷方式会同时变成通用文档图加箭头——而程序本身完全能打开，因为目标路径根本不受影响。这也是本文给「图标变白」的第一判据：先按图标路径 Test-Path，别先动缓存。

那个快捷方式箭头是叠上去的，跟图标坏没坏是两件事

很多人把「箭头没了」和「图标白了」当同一个故障。本机量下来它们分属两层。外壳取图接口 SHGetFileInfo 的官方页 SHGetFileInfoW 把箭头明确定义为叠加层：SHGFI_LINKOVERLAY 的原文是 "Modify SHGFI_ICON, causing the function to add the link overlay to the file's icon. The SHGFI_ICON flag must also be set."，SHGFI_ADDOVERLAYS 是 "Apply the appropriate overlays to the file's icon. The SHGFI_ICON flag must also be set."。本机按这两个标志去取「目标程序加叠加」的图，再和「直接取那条 .lnk」的图逐像素比：讲述人、记事本、Google Chrome 三条全部 0 个像素之差，也就是逐字节相同；而不加叠加层时两者差 169 个像素，差的像素全部落在横坐标 0 到 12、行号 19 到 31 这块 13×13 的矩形里——正好是左下角那块箭头。32×32 一共 1024 个像素，箭头占 169 个，约六分之一。

顺便说一件网上很少提的事：这些标志位的数值本身是坑。本文第一版比对脚本把 SHGFI_ADDOVERLAYS 当成了 0x2000，而 0x000002000 在官方页里是 SHGFI_EXETYPE，那一页还写着这个标志 "This flag cannot be specified with any other flags."。结果一整批「看起来正常」的哈希其实来自一次非法调用，前面表里那些逐字节相同结论是在换成正确的 0x20 之后重新跑出来的。同理，把 SHGFI_ICONLOCATION 写成 0x4（那是 SHGFI_SHELLICONSIZE）、SHGFI_TYPENAME 写成 0x200（那是 SHGFI_DISPLAYNAME），会得到两个空字符串加返回值 1，很容易让人误读成「外壳说没有图标位置」。

SHGFI_ICONLOCATION 返回的东西还不能当判据用，本机的三种表现是这样的：讲述人那条回的是原样吐回、连环境变量都没展开的 %windir%\system32\narrator.exe 加序号 -1（这个序号前文已经证明取不到图）；Google Chrome 那条存的是绝对路径、且就是目标程序本身，外壳回了一个空字符串加序号 0；而完全没有存图标位置的 computer.lnk，外壳回的是 C:\Windows\System32\imageres.dll 加序号 -109——这个值和本机在注册表 HKCR\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\DefaultIcon 里读到的「此电脑」默认图标逐字一致。也就是说这个接口给出的是 IconHandler 随手报的一个字符串，既可能报出一个它自己满足不了的序号，也可能该报的时候报空。官方页对这行的措辞其实已经预告了这一点：那个值是 "as returned by the IExtractIcon::GetIconLocation method of the file's icon handler"。

想核对「磁盘上到底存了哪个图标串」，唯一可靠的是读 .lnk 本身（文件头的序号加 StringData 里的 ICON_LOCATION），或者用 COM 的 CreateShortcut 读 IconLocation 属性；本机两条路径读出的序号 112 条完全一致。

图标缓存到底在哪？官方那条 DEL 删的不是在用的那批

微软那页的成因句只点了两样东西——图标缓存和 IconHandler 子键，它给的第一步操作原文是：先 "Save any open work before you begin, as you need to restart Windows Explorer."，然后打开任务管理器结束 Windows Explorer 进程，用 "File > Run new task" 以管理员身份起 cmd.exe，执行两行：

CD /d %userprofile%\AppData\Local
DEL IconCache.db /a

再起 explorer.exe 收尾，并给出这一段的预期效果："This process clears the icon cache and restores the display of your taskbar icons."

本机把这条命令的目标和实际在用的缓存分别称了重量。

三个数放在一起，问题的形状就出来了：%LOCALAPPDATA%\Microsoft\Windows\Explorer 目录下 15 个 iconcache_*.db 共 78,408,064 字节，其中 10 个是恰好 24 字节的空壳，全部数据压在 5 个文件里的 78,407,824 字节上；而官方命令删的是同级目录根上那个 121,206 字节的老式 IconCache.db，它自成一式（本机读到的文件头前 8 个字节是 48 00 00 00 加 "Win4" 四个字符）。新那批文件的头是 43 4D 4D 4D，两种格式互不相干。那个 24 字节的空壳群最后一次写入是 2026-06-18，也就是系统装好那天之后就没再动过——它们对应的尺寸档（96、768、1280、1920、2560、宽条、EXIF、搜索请求等）在这台机器上从来没被填过内容。同目录里还有 15 个 thumbcache_*.db 共 102,177,520 字节，那是缩略图缓存，管的是图片文件的预览小图，跟程序图标无关，两个数字不要混用（这个目录总计 32 个文件、181,150,832 字节）。

顺手回答一个常被拿来当动机的问题：这 78 MB 该不该为了腾空间删。本站那篇 C 盘红了怎么办？先弄清空间被谁占走，再按能腾出的量逐个处理 的口径是「先认清每块空间换回来要付什么代价」。图标缓存的代价很具体：它是纯生成物，删了会重新长回来，长回来的过程是把每个图标重新取一遍、重新合成一遍，这段时间里图标显示会闪、会变通用图。想删之前先量一下自己的量级：本机这 78 MB 占 C 盘的比重，几乎肯定小于同目录那 102 MB 缩略图，也小于任何一份系统还原点。真要清，官方路径给的收益只到「显示恢复正常」，不给空间。

还有一个执行层面的观察，能解释为什么官方步骤必须「先结束资源管理器」：本文在资源管理器正常运行的时候，尝试以独占方式打开 iconcache_idx.db 读取，直接被系统拒绝，报「文件正由另一进程使用」；而同一目录的 iconcache_48.db 用同样的独占读方式能打开。也就是说，那批文件里至少索引那一份是被外壳进程握着的——不结束资源管理器，缓存文件删不干净。本文没有真的去删，所以不评价删完之后多久长回来。

IconHandler 那条链上，本机四个键读出来是什么？

官方第三步要求核对三处，原文依次是："Navigate to HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler, and then check the (Default) value."、"In the following example, the value is {00021401-0000-0000-C000-000000000046}."、"Navigate to the HKEY_CLASSES_ROOT\CLSID{00021401-0000-0000-C000-000000000046}" 并要求 "Make sure that the (Default) value in this key is Shortcut."、"Make sure that the (Default) value in this key is C:\Windows\System32\windows.storage.dll."（这条对应 InProcServer32 子键）。

本机以标准用户身份逐字读出来，四处全对，而且和文档里的示例值一字不差：HKCR\lnkfile\shellex\IconHandler 的默认值是那个 GUID；HKCR\CLSID\{...46} 的默认值是 Shortcut；它的 InProcServer32 默认值是 C:\Windows\System32\windows.storage.dll（本机该文件 8,053,376 字节，文件版本 10.0.19041.4522）。往外多读三处，都是判断「这条链有没有被人动过」时有用的：

• 同一个 CLSID 下没有 LocalServer32 子键（本机读为键不存在）。这条链是进程内组件，图标是在资源管理器进程里画出来的，所以不存在「单独起一个服务进程出图」这种故障。
• HKCR\lnkfile 本身除默认值 Shortcut 之外，还有四个值：EditFlags 为 1、FriendlyTypeName 为 @shell32.dll,-4153、IsShortcut 与 NeverShowExt 是空字符串值。后两个是「隐藏 .lnk 扩展名并把它当捷径对待」的开关，本机全部存在。子键四个：CLSID、shellex、tabsets 以及 shellex 下的 ContextMenuHandlers、DropHandler、IconHandler、PropertySheetHandlers。
• HKCR\piffile\shellex\IconHandler 是同一个 GUID——老式 .pif 程序项文件和 .lnk 走同一条出图链；而 .url 网页快捷方式用的是另一个 CLSID {FBF23B40-E3F0-101B-8488-00AA003E56F8}。桌面上一片图标变样时，先看清楚受影响的是不是同一种链接文件：只有 .url 变了说明和外壳链接那套缓存无关。
• 当前用户下有一处覆盖：HKCU\Software\Classes\lnkfile 存在，且带 shellex 子键。HKCR 是机器级和用户级的合并视图，所以查这条链不能只看 HKCR，得把 HKCU 那份也读一遍。本站那篇 双击打不开文件默认应用被抢回怎么办？文件关联三层记录与打开方式残留项实测清理 已经把「同一个键在 HKLM 和 HKCU 各有一份、用户级优先」这件事量过一遍（本机 711 个扩展名里 249 个只在当前用户那一侧），图标这条链是同一个道理。

另外两个常被教程拉进来的键，本机的真实状态是「不存在」：HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Icons 和 HKCU 下的同名键都不存在（Shell Icons 是教程里改默认图标、去箭头时让新建的那个键）。而 ...\Explorer\ShellIconOverlayIdentifiers 在机器级存在、有 9 个子键（OneDrive1 到 OneDrive7、EnhancedStorageShell、Offline Files），用户级不存在。这 9 个是「图标左上角那枚小徽标」的注册表来源，和右下角的箭头是两码事；OneDrive 装过后图标上多出的云朵或勾就是这个列表画上去的。

最后补一条官方页给的托盘场景判据，因为它和图标链共用同一层外壳。微软原文："If the network or internet icon is missing from the taskbar, check if this policy setting is in place: User Configuration\Administrative Templates\Start Menu and Taskbar\Hide the notification area." 本机 HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 键不存在，HKLM 侧存在但只有四个值（ForceActiveDesktopOn、NoActiveDesktop、NoActiveDesktopChanges、NoRecentDocsHistory），没有隐藏通知区域相关的那项——这台机器的托盘图标缺失不能赖策略。

官方三步各自实际动了什么？标准用户能走到第几步

把微软那页的三个步骤按「权限要求」和「会不会留下副作用」拆开：

第一步：删缓存加重启资源管理器。 它需要管理员身份起 cmd.exe，原文要求 "Type cmd.exe and create a task with administrative privileges."。副作用写在最前面那句提示里：会结束 Windows Explorer 进程，所有资源管理器窗口关掉。删的是那个 121 KB 的老式文件——按本文实测，这一步碰不到机器上真正在用的那 5 个文件。安全用户如果直接双击执行这条 DEL，在资源管理器还活着的时候大概率删不动（同目录的索引文件已经演示了「正由另一进程使用」这种拒绝）。

第二步：重新注册外壳体验宿主。 官方给的整行是：

Get-AppXPackage -AllUsers | Where-Object {$_.InstallLocation -like "*ShellExperienceHost*"} | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

这条命令带 -AllUsers，必须管理员；它重装的是 ShellExperienceHost（开始菜单和搜索面板的那个宿主进程，本机读到 1 个实例在跑）。官方在这步末尾的要求是 "Restart the system to ensure the changes take effect."。也就是说这一半影响的是「开始菜单这一屏能不能画出来」，而不是单个图标的内容——本文的取证显示，开始菜单里那 92 条快捷方式的图标字符串和字段全都完好，问题一般不出在这个宿主上。

第三步：核对 IconHandler 那三个键。 这一步是读，标准用户就能做完（本文全程就是这个身份），而且不需要动注册表。官方那段注册表警告句照录在这里，因为多数转述都把它省了："Important: This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly..."。本页给的处置是「检查并验证」，没有给出改值的具体写法；本机三处值与示例完全一致，所以既不用改也无处可改。

顺带把很多教程里的那条命令说清楚：ie4uinit.exe -show。本机 C:\WINDOWS\System32\ie4uinit.exe 257,024 字节、文件版本 11.00.19041.4522，在这个文件的二进制里确实能读到 -show、-ClearIconCache 以及 In CmdShowIcons、In CmdClearIconCache、ShowIconsCommand 这些字符串——开关是真的。但微软没有为 ie4uinit.exe 的命令行列过参数文档，它也不在那份排错页的三步里。C:\Windows\System32\shell32.dll 里同样只读到一个 IconCache.db 字样的字符串。所以对这条命令的合理定位是：未文档化的历史遗留开关，能跑，但它不是官方处置，也不会更新那 5 个在用的缓存文件。

遇到图标变白，按什么顺序查？五步全部只读

下面这五步在标准用户下都能做完，不需要结束资源管理器，也不需要管理员。

第一步：把图标字符串读出来，看它指向的文件在不在。

$sh  = New-Object -ComObject WScript.Shell
$dir = "$env:APPDATA\Microsoft\Windows\Start Menu\Programs"
Get-ChildItem $dir -Recurse -Filter *.lnk | ForEach-Object {
  $s = $sh.CreateShortcut($_.FullName)
  $p, $i = $s.IconLocation -split ','
  $exp = [Environment]::ExpandEnvironmentVariables($p)
  [pscustomobject]@{
    Name = $_.Name
    TargetOk = (Test-Path ([Environment]::ExpandEnvironmentVariables($s.TargetPath)))
    IconFile = $exp
    IconOk   = (Test-Path $exp)
    Index    = [int]$i
  }
}

用 COM 而不是手工解析二进制，是因为本机比对过：文件头的序号和 COM 报出的序号 112 条零不一致，两个来源可信度相同。这一步就能把「图标文件不见了」这一大类挑出来，而且顺带把「目标不见了」分开——两者互不相干，本文已实测。

第二步：只对 IconOk 为 False 的那几条改图标。 右键、属性、更改图标、重新指一次，或者干脆按本站那篇 Windows 文件资源管理器效率指南：那些被忽略但极好用的操作怎么用 的做法，从程序安装目录里重新选那个 exe。改完不需要重启，图标会自己变。

第三步：IconOk 为 True 但图不对，才去数序号。 用前面那段定义好的两个入口：

[IconProbe]::Count($iconFile)              # 该文件一共几张图
[IconProbe]::Has($iconFile, $index)        # 这一格取不取得到，看 True 或 False

取不到就把序号改成 0 试一次。本机 3 条取不到句柄的记录（讲述人、屏幕键盘、iSCSI 发起程序）正是靠这个回落才照常显示，所以这一改最多是「换回第一张图」，不会有别的风险。

第四步：整类文件图标都不对，查文件关联那条 DefaultIcon。 微软 How to Assign a Custom Icon to a File Type（2021-01-08 更新）给的机制是 "When no custom default icon is assigned to a file type, the desktop and Windows Explorer display all files of that type with a generic default icon."，位置是 ProgID 或扩展名下的 DefaultIcon 子键，写法 "If there is more than one icon in the file, the path should be followed by a comma, and then the index of the icon."。本机非 exe 目标的快捷方式走的正是这条路：.txt 的 txtfile 指向 imageres.dll,-102，.chm 的 chm.file 指向 hh.exe,0，.html 的 htmlfile 指向 iexplore.exe 的 -17 号；.exe 和 .msc 的 DefaultIcon 值都是 %1——官方 How to Create Icon Handlers 页的原文是「To register an icon handler, you must still have the DefaultIcon subkey, but its default value must be set to "%1"」，引号里那个百分号加 1 的意思就是从文件自己身上取图。这几条链上的值只要有一处坏，受影响的是一整类文件，不是单个快捷方式，这就和「图标缓存坏了」区分开了。

第五步：只有到这一步才轮到缓存和 IconHandler。 判据是前面四步都正常，但改动已经做了、显示就是不刷新。这时才按官方三步的顺序走：先只读地核对 IconHandler（第三步，零风险），再决定要不要执行删缓存加重启资源管理器（第一步），最后才碰需要重启的那个 ShellExperienceHost 重注册（第二步）。反过来先做第二或第一步，是把「显示不刷新」当成「数据坏了」来治，代价最大、命中率最低。

常见问题 FAQ

图标变白和快捷方式失效是一回事吗？

不是，而且在本机上它们连现象都不重叠。失效指的是目标找不着，本文造的「目标不存在、图标文件健康」那条快捷方式，大图标和完全健康的对照条逐字节一样，都是记事本图标加箭头。变白指的是取图环节失败，本文造的「图标文件不存在、目标健康」那条照样显示通用文档图，双击照样打开记事本。所以正确的用法是把两者当两个独立读数：图标正常不代表目标还在，目标丢了不代表图标坏。判断目标是否在，用 Test-Path 读 .lnk 的 TargetPath（要先把环境变量展开，本机 69 条图标串里 46 条带变量，目标路径同理）；判断图标是否坏，看图标文件在不在、序号取不取得到句柄。

双击那个白图标还能打开程序，是不是说明没坏？

恰恰相反，这就是微软那份排错页列的症状本体。逐字引文："Application shortcuts on the desktop, Start menu, and taskbar show blank icons. This issue can affect both built-in (inbox) and third-party applications. However, double-clicking the blank icon can still open the application."。原因很直白：出图链和启动链是两条链。启动用的是链接里存的目标路径加参数加工作目录（本机 112 条里 HasArguments 30 条、HasWorkingDir 85 条），出图用的是 ICON_LOCATION 加 IconIndex 那一对。后一对坏了，前一对可以完全没事。这也是为什么「图标对了」不能证明快捷方式健康。

我要不要删掉那批 iconcache 文件重新生成？

先确认自己在治什么。本机那 5 个有内容的文件（16、32、48、256 四档加索引）是显示层的东西，不是图标的数据源——微软那页讲图标处理器时把它的定位说得很清楚："The Shell adds the icons to its cache to expedite subsequent calls to the handler."，缓存只是为了少跑几次取图。所以如果 .lnk 里那串图标路径指向的文件已经不见了，删缓存删一百遍也还是同一张通用文档图，因为源头没了，重建只是把「源头没了」这件事重新渲染一遍。本文在本机没有执行删除，也就没法给「删完之后多久长回来」的时间数——这条只能按官方那句预期读：清掉缓存的效果是 "restores the display of your taskbar icons"，前提是那一层真的坏了。要判断这一点，先看图标不对的是不是一批互不相关的程序、且它们的图标文件全部健在，两个条件同时成立才值得动手。

快捷方式里那个箭头能不能去掉？

能，但那不是修图标，而是换一张图。本文量到的结构是这样：箭头是一个叠加层，占 32×32 里左下角 13×13 那一块、共 169 个像素，外壳接口用 SHGFI_LINKOVERLAY 或 SHGFI_ADDOVERLAYS 把它和图标本体合成，讲述人、记事本、Chrome 三条去掉叠加层后与目标程序的图标逐字节相同。也就是说：箭头是后盖上去的，图标本体一个像素都不受影响。所以「箭头没了」通常是叠加层那一档出问题（本机在 HKLM\...\Explorer\ShellIconOverlayIdentifiers 下读到 9 个注册项，OneDrive 那 7 个都在里面，这类标识的名额有限，装的东西多了会挤掉），而「图标变成通用图」是取图环节出问题，两条链不要混。网上流行的「新建 Shell Icons 键改默认图」这一手，在本机的前提就不成立：HKLM 和 HKCU 两侧的 Shell Icons 键都不存在，那是需要自己新建的键，不是系统默认配置的记录。

负数序号是不是写错了？为什么 ,-1 也能显示？

大多数情况下不是写错，而是撞上了两个规则的交点。规则一是负数等于资源编号（官方两处口径一致）；规则二是 -1 是 ExtractIconEx 的专用问数取值，官方措辞是 "If this value is –1 and phiconLarge and phiconSmall are both NULL, the function returns the total number of icons in the specified file."。本机那三条 ,-1 恰好落在交点上：文件里没有编号为 1 的资源，-1 又只能用来问总数，于是取图失败；屏幕上还能看到图，是因为外壳退回到了那个文件的第一张。所以「,-1 显示正常」不是这个写法可靠，而是它掉进了一个看起来一样的兜底结果。判断一个负序号到底取没取到，唯一可靠的办法是给真句柄变量调一次、看句柄空不空，本机 14 组能取到、3 组取不到，靠的都是这个判据。

改完图标或者换了缓存，什么时候才算真生效？

看的是有没有人通知外壳，而不是等多久。微软那篇自定义图标文档把这条列为第三步，逐字是 "Call the SHChangeNotify function to notify the Shell to update its icon cache."。这就是为什么「在属性里改了图标但另一个目录里那条还是旧的」会发生：改 .lnk 只写了文件本身，缓存里那条旧位图还在按路径记着。本机能直接观察到的另一面是，那批缓存文件的写入时间分布在几个不同时刻（16 那档停在 11 月 1 日、256 那档停在 11 月 2 日 13:52、48 那档停在 20:00:09），说明它们由外壳按各自节奏更新，不是改一次全部重来。想快速看到结果，办法是让这一层整个失效（也就是官方第一步），或者干脆把图标指向一个新位置——新位置必然触发一次取图。

写在最后

把本文这一串实测排下来，「图标变白」这个症状的排查顺序其实和网上的热门顺序相反。第一位是图标文件还在不在：69 条存了自定义图标的记录里，11 条的图标文件落在安装缓存或用户目录缓存这类会被清理工具端掉的地方，而它一旦没了，屏幕上得到的是通用文档图加一个箭头，程序照样能打开；第二位是序号取不取到句柄：判据只能是句柄，不能是返回值，本机的 3 组负序号取不到句柄却显示正常，就是因为外壳替它回落到第一张图；第三位是文件关联那条 DefaultIcon，它管一整类文件，本机 .txt、.chm、.html 三类目标就是这么出图的；第四位才是 IconHandler 链和缓存，前者标准用户可只读核对且本机与官方示例值一字不差，后者是显示层的加速件，官方那条 DEL 命令在本机删的是 121,206 字节的老式文件，而真正在用的那 5 个文件共 78,407,824 字节、其中一个还被资源管理器占着。至于「快捷方式失效」，它是目标路径的问题，和图标长什么样逐字节无关——这是本文四个结论里最容易当场验的一条：造一条目标不存在的快捷方式，它的图标和完好那条一模一样。

本文所有注册表读取、字段普查与逐像素比对结果核验于 2026-11-03，取证机为 Windows 10 专业版 10.0.19045、以标准用户身份执行；缓存文件删除与资源管理器重启两类动作未在该机执行。以微软官方文档与后续系统版本为准。