追查AppData\LocalLow里的乱码文件一场从文件头INSC开始的溯源现象C:\Users\用户\AppData\LocalLow根目录下不断冒出名字像乱码、没有扩展名的文件删了还会再长出来。结论它们是 Intel 核显驱动的着色器缓存Shader Cache文件名是 64 位十六进制的缓存哈希文件头魔数INSC就是IntelShaderCache。不是病毒不是乱码。排查机器机械革命MECHREVOYAOSHI 系列Intel Arrow Lake NVIDIA RTX 5070 Ti LaptopIntel 核显驱动 32.0.101.6629。一、结论问题答案这些文件是什么Intel 显卡驱动的着色器缓存条目文件名为什么像乱码它是缓存内容的哈希值64 个十六进制字符本来就没有扩展名文件头INSC是什么Intel Shader Cache 的魔数在 Intel 自己的驱动 DLL 里能搜到是病毒吗不是。所有者是当前用户属性是Archive NotContentIndexed内容是纯二进制能删吗能。实测 19 个文件全部未被占用删掉只影响首次加载时的着色器编译速度为什么删了还会回来只要 Intel 核显还在参与渲染驱动就会重新写怎么根治切独显直连MUX让核显不参与渲染基本上就是intel 核显驱动不知道出了什么bug把着色器缓存文件写错位置了。也可以直接右键文件属性把所有乱码文件设为隐藏眼不见心不烦。注意网上那个LocalLow 出现乱码文件的帖子里被标记为答案的建议是执行rd /s /q %USERPROFILE%\AppData\LocalLow\。千万别照做——LocalLow里躺着几十个游戏的存档目录。那个帖子的评论区就有人照做之后游戏进度全没了、恢复不了。二、乱码文件如下图就是这些数字字母文件名没有后缀实际上并不是乱码应该是某种id 或者hash。所有文件的内容特征都是以INSC开头后面跟一段疑似是日期的文本之后就全是乱码显然文件本身应该是某种二进制格式。用INSC 前缀在LocalLow 下搜索一共87 个文件分布在两个位置位置数量体积扫描时刻LocalLow\根目录就是乱码文件所在处1999,716 字节约 97 KBLocalLow\Intel\ShaderCache\681,507,576 字节约 1.4 MB注Intel\ShaderCache是活的——驱动随时在写。我前后两次测量同一个目录字节总数从 1,501,107 变成 1,507,576因为有些 26 字节的空壳在中间被填上了载荷。数量稳定体积会漂移。两个位置的文件名重合 0 个——所以根目录那批不是Shader 下面文件的副本或残留而是各自独立写出来的条目。这也是第一个强信号LocalLow\Intel\ShaderCache是 Intel 的正规目录而根目录那批是跑错了地方。三、INSC是什么去驱动二进制里找答案猜测没有意义直接验证。我把文件头按字节拆开看 LocalLow\ed8b7e4b...c1d97 (38,706 字节) 0 49 4e 53 43 67 7d 06 00 INSCg}.. 8 00 02 00 46 65 62 31 38 ...Feb18 16 32 30 32 35 32 30 32 39 20252029 24 34 35 cb a9 06 76 ee 4a 45...v.J 32 15 ed fb a1 95 7a 2d c7 .....z-. 40 ae b2 10 42 a0 18 c3 84 ...B....肉眼就能读出两段东西魔数INSC以及 ASCII 字符串Feb182025202945。这明显是一个编译器构建时间戳__DATE__/__TIME__风格即2025-02-18 20:29:45。那么问题变成哪一家的代码是 2025 年 2 月 18 日构建的看一眼显卡Get-CimInstanceWin32_VideoController|Select-ObjectName,DriverVersion,DriverDateName : NVIDIA GeForce RTX 5070 Ti Laptop GPU DriverVersion : 32.0.16.1714 DriverDate : 2026/9/17 Name : Intel(R) Graphics DriverVersion : 32.0.101.6629 DriverDate : 2025/2/18 ← 对上了Intel 核显驱动的日期正是2025/2/18与文件头里的构建戳同一天。接下来是决定性的一步在 Intel 自己的驱动二进制里搜INSC。驱动 UMDUser Mode Driver位于C:\Windows\System32\DriverStore\FileRepository\$dirC:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_9fadbfb5f574c7ebGet-ChildItem-LiteralPath$dir-File-Includeig*.dll|ForEach-Object{$txt[System.Text.Encoding]::ASCII.GetString([System.IO.File]::ReadAllBytes($_.FullName))if($txt.Contains(INSC)){{0} v{1}-f$_.Name,$_.VersionInfo.FileVersion}}结果17 个 Intel 驱动组件里都有这个魔数且版本号全部是32.0.101.6629igd10um64xe.dll D3D10/11 UMD igd12um64xe2.dll D3D12 UMD igd12um64xeh.dll D3D12 UMD (Xe-HPG) igd12um64xel.dll D3D12 UMD (Xe-LPG) igd9trinity64.dll Trinity 世代 UMD igvk64.dll Vulkan ICD igxelpgicd64.dll OpenGL ICD npu_level_zero_umd.dll Intel NPU UMD ...另有 9 个 32 位版本但这还不是铁证——某个字符串出现在 DLL 里和这个 DLL 写这种文件是两回事。真正的铁证来自构建戳逐字比对组件构建戳64 位驱动 DLLigd10um64xe/igd12um64xe2/igvk64/igxelpgicd64…Feb18202520294532 位驱动 DLLigd10um32xe/igd12um32xe2…Feb182025201453LocalLow根目录 19 个文件Feb18202520294519/19Intel\ShaderCache68 个文件Feb18202520294566 个Feb1820252014532 个文件里嵌的构建戳与 64 位驱动 DLL 的构建戳完全相同而 32 位 DLL 是另一个戳——这直接锁定了写入者Intel 的 64 位用户态显卡驱动。Intel\ShaderCache里那两个...1453的文件则是 32 位驱动组件写的说明同一个目录会收纳两种位宽的条目。最后把 DLL 里的 UTF-16 字符串捞出来答案就写在 Intel 自己脸上Intel Shader Cache Command Queue Prrocessing Thread ← 注意 Intel 自己的拼写错误 Prrocessing \Intel\ShaderCache ShaderCacheForceDisabled OfflineShaderCacheHarvestTargetDirectoryINSC Intel Shader Cache旁证齐全到不需要再猜。四、排除某个游戏写坏了的可能时间戳交叉比对对根目录每个文件找出前后 3 分钟内LocalLow下其他文件的写入活动$rootGet-ChildItem-LiteralPath$ll-File-Force$othersGet-ChildItem-LiteralPath$ll-Recurse-Force-File-ErrorAction SilentlyContinue|Where-Object{$_.DirectoryName-notlike$ll-and$_.DirectoryName-notlike*\Intel*}foreach($fin$root){$near$others|Where-Object{[math]::Abs(($_.LastWriteTime-$f.LastWriteTime).TotalSeconds)-lt180}{0} {1} - {2} 个同期文件-f$f.LastWriteTime,$f.Name.Substring(0,16),$near.Count}结果19 个文件里没有一次与游戏存档目录的写入时间重合只匹配到Microsoft\CryptnetUrlCache这种系统证书缓存的噪音。也就是说这些文件是驱动自己的后台线程写的跟游戏进程无关。占用测试确认它们是不是像网上说的无法删除$root|ForEach-Object{try{$fs[System.IO.File]::Open($_.FullName,Open,Write,None);$fs.Close();FREE$($_.Name)}catch{LOCKED$($_.Name)}}根目录那 19 个19/19 全部FREE可以独占打开随时可以删。但同样的测试打到Intel\ShaderCache时出现了本次排查最直观的一幕——有 4 个文件直接被拒绝访问Exception calling OpenRead: The process cannot access the file ...\Intel\ShaderCache\121f266ebbe7bcb5... because it is being used by another process.挨个验证这 4 个文件改用FileShare.ReadWrite才能读进去注意Length取自目录列表不需要打开文件$fs[System.IO.File]::Open($p,Open,Read,ReadWrite)# 允许共享读写结果 4 个全都是合法的INSC文件驱动戳Feb182025202945长度分别是 195,042 / 99,311 / 26 / 26 字节。这就是这些文件删不掉的真相不是权限问题也不是病毒锁文件而是驱动此刻正开着它们。缓存目录里的文件处于滚动占用状态——刚才测前 5 个是FREE回头看就发现 4 个被占住了。重启或让驱动释放句柄之后即可删除这也解释了为什么微软 QA 里有人说无法删除、还会持续增加。那么到底是谁在写看看谁加载了 Intel 的驱动Get-Process|ForEach-Object{try{$m$_.Modules|Where-Object{$_.ModuleName-match^(igd1[02]um|igvk|igxelpgicd|igd9trinity)}if($m){{0,-28} PID {1,-7} {2}-f$_.ProcessName,$_.Id,$m[0].ModuleName}}catch{}}本机当时的输出10 个进程EpicGamesLauncher PID 33796 igd10umt64xe.DLL explorer PID 21996 igd10umt64xe.DLL LockApp PID 2868 igd10umt64xe.DLL PowerToys.ColorPickerUI PID 17292 igd9trinity64.dll PowerToys.QuickAccess PID 17204 igd10umt64xe.DLL PowerToys.ShortcutGuide PID 17340 igd10umt64xe.DLL RuntimeBroker PID 33264 igd10umt64xe.DLL SearchHost PID 13720 igd10umt64xe.DLL StartMenuExperienceHost PID 6032 igd10umt64xe.DLL TextInputHost PID 34152 igd10umt64xe.DLL这份名单彻底解释了行为特征写缓存的不是某个游戏而是任何在 Intel 核显上渲染的进程——桌面explorer、开始菜单、搜索、锁屏、输入法候选窗、PowerToys 都在列。这就解释了为什么你不打游戏的时候这些文件也会增加你删掉之后它们很快又回来桌面上随便点几下就有新的着色器要编译数量是慢慢涨而不是一次爆发每次出现新着色器组合才会写一条。五、为什么会跑到LocalLow根目录正常位置是LocalLow\Intel\ShaderCache\那 19 个为什么会落在上一层在驱动 DLL 里能读到一条相对路径字符串.\Intel\ShaderCache同时还有SHGetKnownFolderPath读取系统已知文件夹API。合理推断是缓存路径 已知文件夹基准路径 相对子路径拼接而成当Intel子目录的解析或创建失败时条目就退化落到了基准目录本身也就是LocalLow根。驱动里还带着\\?\长路径前缀和相关错误字符串Failed creating read operation、Failed to write the file.、Error opening file:、Cache file header corrupted!也印证了这条写盘路径上有失败分支。不过具体的bug 逻辑就没必要追查进去了反正就算知道了也没用。时间线指向驱动/系统更新这个诱因时间事件2026-10-06 00:14:01LocalLow\Microsoft目录重建2026-10-06 00:18:36LocalLow\Intel目录创建同时出现第一批根目录文件2026-10-06 00:30:18LocalLow\NVIDIA目录重建2026-10-06Intel(R) Icls组件安装安装日期202610062026-10-06 00:18 ~ 00:37根目录文件爆发式出现14 个2026-10-07 ~ 10-10零星增加00:01 / 00:54 / 19:35 / 01:40 各一批一次显卡驱动/系统更新之后开始出现之后零星增长——完全符合缓存的行为特征。另外Intel\ShaderCache一直在活跃更新最近一个文件是 10/10 23:56说明缓存机制本身工作正常只是部分条目写错了位置。六、INSC文件格式备忘把 87 个文件的结构总结如下offset 从 0 开始偏移长度内容04魔数INSC49 4E 53 4347版本/标志位。有内容的条目为67 7d 06 00 00 02 0026 字节空壳全为001115驱动构建时间戳ASCII格式Mmmddyyyyhhmmss实测Feb182025202945 2025-02-18 20:29:452616缓存键哈希/类 UUID每个文件都不同42变长编译后的着色器数据块两个有意思的观察26 字节的文件占了整整 44 个共 87 个——它们只写了头部、没有任何载荷是空壳条目。体积分布极度长尾最小的 26 字节最大 656,842 字节根目录那 19 个总共不到 100 KB。对照属性也能佐证这是驱动缓存Attributes Archive, NotContentIndexedNotContentIndexed不被 Windows 搜索索引是驱动缓存的典型属性——系统自己也知道这类文件不该进索引。七、怎么处置方案 1不治本但安全定期清理只删LocalLow根目录里64 位十六进制 无扩展名的文件绝不碰任何子目录$llJoin-Path$env:USERPROFILEAppData\LocalLowGet-ChildItem-LiteralPath$ll-File-Force|Where-Object{$_.Name-match^[0-9a-f]{64}$}|ForEach-Object{# 双保险确认魔数真的是 INSC 才删被占用的文件跳过下次再清try{$fs[System.IO.File]::Open($_.FullName,Open,Read,ReadWrite)$bNew-Objectbyte[]4;$fs.Read($b,0,4)|Out-Null;$fs.Close()if([System.Text.Encoding]::ASCII.GetString($b)-eqINSC){Remove-Item-LiteralPath$_.FullName-Force}}catch{Write-Warning(跳过被占用$_.Name)}}实测这段的匹配逻辑在本机精确命中 19 个文件 / 99,716 字节且不触碰任何目录我实测时只做了统计没有真的执行删除。代价下次进游戏要重新编译着色器首次加载会略卡一下。不影响任何存档。方案 2根治推荐用笔记本自带的控制中心本机是机械革命控制中心切换独显直连MUX。核显不参与渲染后Intel 驱动就不会再生成这些缓存。注意切换前先确认外接显示器接在哪块显卡的输出上本机同时接了内置 BOE 面板和外接显示器避免切完外接屏没信号。方案 3驱动注册表开关不建议驱动里存在这个值名HKLM\SOFTWARE\Intel\Display\igfxcui\3D\ShaderCacheForceDisabled本机不存在该键即处于驱动默认状态。理论上置1可禁用着色器缓存但代价是每次运行都要重新编译全部着色器游戏卡顿会明显很多。除非你完全无法忍受这些文件否则不建议。方案4眼不见心不烦要是担心删了会影响什么就直接右键文件属性把“隐藏”勾上。八、⚠️ 反面教材那条被标记为答案的删除命令在 微软 QA 的locallow 文件夹里出现大量乱码文件 帖子里答复给出的根治方法是rd /s /q %USERPROFILE%\AppData\LocalLow\这是一条会毁掉游戏存档的命令。LocalLow不是缓存目录它是 Unity 等引擎存放用户数据的标准位置——存档、配置、进度全在里面。本机LocalLow下有 60 多个游戏目录那个帖子的评论区里就有用户执行后留言“把我游戏数据全删除了还恢复不了我真无语了啊”。正确的做法是只按文件名模式和魔数精确匹配、只删根目录的那几个文件。一个简单的判别规则名字是 64 个十六进制字符、没有扩展名、文件头是INSC→ 驱动缓存可删。名字是目录、里面有.json/.dat/.sav/.es3之类 → 游戏数据别碰。关于着色器缓存能不能删微软 QA 的另一条 回答 也确认LocalLow\Intel\ShaderCache里是临时的编译着色器数据删除是安全的。附一行自查脚本不确定自己机器上LocalLow里的可疑文件是不是同一类跑这个$llJoin-Path$env:USERPROFILEAppData\LocalLowGet-ChildItem-LiteralPath$ll-Recurse-Force-File-ErrorAction SilentlyContinue|ForEach-Object{try{# FileShare.ReadWrite避免漏掉正被驱动占用的文件$fs[System.IO.File]::Open($_.FullName,Open,Read,ReadWrite)$bNew-Objectbyte[]26;$n$fs.Read($b,0,26);$fs.Close()# 用 -ge 4 而不是 -eq 26即使只读回部分字节也不漏判见方法论第 7 条if($n-ge4-and[System.Text.Encoding]::ASCII.GetString($b,0,4)-eqINSC){[pscustomobject]{路径 $_.FullName 大小 $_.Length 驱动戳 if($n-ge26){[System.Text.Encoding]::ASCII.GetString($b,11,15)}else{短文件}修改 $_.LastWriteTime}}}catch{}}|Format-Table-AutoSize如果驱动戳显示Feb182025202945或类似Mmmddyyyyhhmmss的字符串就说明你遇到的和我这次是同一回事。排查环境Windows 11 · Intel® Graphics 32.0.101.6629 · NVIDIA GeForce RTX 5070 Ti Laptop GPU · MECHREVO YAOSHI Series (Arrow Lake)