顽固的桌面残留图标 ⊘ ——顶级AI的败北

顽固的桌面残留图标 ⊘ ——顶级AI的败北

记录一次利用cladue opus 4.8去除图标失败的案例（chatgpt-5.5同样失败）

从文件资源管理器往 Chrome 里的 ComfyUI 拖图片，中途资源管理器卡死，松手处留下一个“禁止放置”光标 ⊘，固定悬浮在所有窗口最顶层。目标：不重启电脑把它去掉。

环境：Windows 11 · 2560×1440 · 涉及 UU远程 / 向日葵 · 当前状态：未解决（征求思路）

TL;DR — 已确认的硬事实

1. 本地存在：本地直接用机（无任何远程）时 ⊘ 就在 → 排除远程客户端缓存。
2. 最顶层悬浮：任何窗口都盖不住它 → 排除壁纸 / 桌面背景层。
3. 鼠标可穿透：WindowFromPoint 命中穿到桌面（SysListView32/Progman），枚举不到对应独立实体窗口。
4. 随分辨率等比缩放移动：切分辨率时它跟着改变相对位置。
5. 扛过 dwm 重启 + explorer 重启：同样大小的“白窗”被 dwm 重启清掉了，但 ⊘ 没有。

已试过且无效：刷新桌面 / 锁屏 / 重绘桌面图标层 / 强制重设壁纸 / 结束拖放图像（ImageList_EndDrag）/ 补鼠标事件+Esc / 重启 explorer / 重启 dwm / 反复结束 GameViewerServer 等覆盖进程。

求助：在不重启电脑的前提下，如何清掉这种“可穿透、最顶层、随分辨率缩放、且枚举不到窗口”的显示残留？

图片对照表（上传图床后把链接填到对应占位）

完整排查对话

🟢 楼主

)

)

（图1–图2：桌面上残留的 ⊘ 图标（红圈/箭头处）以及当时的提问）

看得见我箭头指的这个图标么？这个图标是我之前想把图片拖入 chrome 某个网页里的时候，电脑的文件管理器突然卡住之后留下来的。现在文件管理器恢复正常了，它还留下来了。能不能在不重启电脑的情况下去掉它？

🔴 Claude

看得见，就是桌面上那个带斜杠的小圆圈（⊘）。这是拖拽操作的“禁止放置”光标，在文件管理器卡死的瞬间被“印”在了屏幕上，属于一个残留的画面残影——它并不是真的文件或图标。所以不用重启电脑，强制让屏幕重新绘制一次就能清掉。从最轻到最彻底依次试：

• 拖一个窗口划过它，逼这块区域重绘；
• 按 Win + D 两次（显示桌面 / 还原），让桌面整层刷新；
• 桌面右键 → 查看 → 取消勾选“显示桌面图标”再勾回；
• 任务管理器里对“Windows 资源管理器”点“重新启动”；
• Win + L 锁屏再解锁，整屏强制完整重绘（最稳的兜底）。

按顺序往下试，一般到第 3 或第 4 步就解决了。如果全试过还在，可能不是单纯残影。

🟢 楼主

不行 还在，而且它是在最顶层覆盖其他页面的一个状态。

🔴 Claude

明白了，这就不是单纯的画面残影了——它能盖在其他窗口最上层、固定不动，说明它是一个真正的孤儿窗口：拖拽时系统会创建一个置顶图层窗口（topmost layered window）用来画拖拽图像，文件管理器在拖到 Chrome 的过程中卡死，这个图层窗口没被销毁，被遗留下来。所以刷新桌面、重启资源管理器都清不掉它。

思路：先找出是哪个进程在撑着这个窗口。把鼠标悬到 ⊘ 上别动，运行下面这段读取鼠标位置下的窗口属主：

Add-Type @"
using System;using System.Runtime.InteropServices;using System.Text;
public class W {
  [DllImport("user32.dll")] public static extern bool GetCursorPos(out POINT p);
  [DllImport("user32.dll")] public static extern IntPtr WindowFromPoint(POINT p);
  [DllImport("user32.dll")] public static extern IntPtr GetAncestor(IntPtr h, uint f);
  [DllImport("user32.dll")] public static extern uint GetWindowThreadProcessId(IntPtr h, out uint pid);
  [DllImport("user32.dll")] public static extern int GetClassName(IntPtr h, StringBuilder s, int n);
  [StructLayout(LayoutKind.Sequential)] public struct POINT { public int X; public int Y; }
}
"@
Start-Sleep -Seconds 3
$p = New-Object W+POINT
[W]::GetCursorPos([ref]$p) | Out-Null
$h = [W]::WindowFromPoint($p)
$root = [W]::GetAncestor($h, 2)
$procId = 0
[W]::GetWindowThreadProcessId($root, [ref]$procId) | Out-Null
$proc = Get-Process -Id $procId
"句柄: $h  根窗口: $root  属主进程: $($proc.ProcessName) (PID $procId)"

🟢 楼主

我测试了三次，都不一样：

坐标: 1009,967  窗口类名: Chrome_WidgetWin_1  属主进程: chrome  (PID 56392)
坐标: 1010,967  窗口类名: Progman          属主进程: explorer (PID 10260)
坐标: 1005,970  窗口类名: Progman          属主进程: explorer (PID 10260)

🔴 Claude

三次结果说明了关键问题：WindowFromPoint 穿过那个 ⊘ 直接命中了它背后的东西——说明鼠标点击会“穿透”这个图标。这恰好暴露了它的真身：它是一个 click-through 的置顶层窗口（WS_EX_TRANSPARENT + WS_EX_LAYERED），是 OLE 拖放机制创建的“拖拽反馈图像”窗口的标准特征。

所以不能靠“鼠标下面是谁”来找它，得枚举所有顶层窗口，按坐标筛出那个又小又置顶的。

🟢 楼主

报错：无法将 PSMethod 转换为 EnumProc 委托。（回调写法在 PowerShell 里不能直接传方法）

🔴 Claude

这是 PowerShell 把方法转委托的老毛病。把回调写进 C# 内部，让枚举在 C# 里完成，PowerShell 只取结果即可。改用 E2 版本枚举覆盖该坐标、尺寸 < 400 的小窗口。

🟢 楼主

结果：该坐标下没有匹配的小窗口。

🔴 Claude

顶层窗口里覆盖该点的小窗口一个都没有。结合鼠标能穿透到背后，基本锁定：它不是一个“小窗口”，而是一个几乎覆盖整个屏幕的透明置顶层窗口（整张透明、只在那个位置画了个 ⊘），被我用“尺寸 < 400”的过滤排除了。去掉尺寸限制，改成只挑覆盖该点、且带 LAYERED 或 CLICK-THRU 标志的窗口（E3）。

# E3：枚举覆盖指定点、带 LAYERED 或 CLICK-THRU 标志的窗口
if(layered || thru) {
  outp.Add("句柄="+h+" 类名="+cls+" 标题='"+txt+"' PID="+pid
           +" 尺寸="+w+"x"+ht+" "+flags);
}

🟢 楼主

E3 扫描结果：

句柄=47974622 类名=GameViewerPrivateWindowClass 标题='G' PID=44376
  位置=(0,0) 尺寸=2560x1440 LAYERED CLICK-THRU TOPMOST 进程=GameViewerServer
句柄=18618430 类名=CEF-OSC-WIDGET 标题='N' PID=36936
  位置=(0,0) 尺寸=2559x1440 LAYERED 进程=NVIDIA Overlay

🔴 Claude

找到了，元凶是这一行：GameViewerPrivateWindowClass，一个全屏（2560×1440）、分层、点击穿透、置顶的覆盖层，属主是 GameViewerServer。它铺满整个屏幕但完全透明、鼠标能穿透，只在那个位置画了个 ⊘。下面那行 NVIDIA Overlay 是正常的 GeForce 性能浮层，别动。

先试最温和的——隐藏这层（不动进程）；不行再重启 GameViewerServer 这个组件进程。

[K]::ShowWindow($ghost, 0)            # SW_HIDE 先尝试隐藏
# 不行再：
Get-Process GameViewerServer | Stop-Process -Force

🟢 楼主

（图3–图4：更新 UU 远程后，桌面多出一个大白窗（左：Claude 对话窗；右：被控桌面 23:15））

不行，没用。我刚才更新了一下 UU 远程，现在又多了一个大窗口悬浮了。

（图5：PowerShell 卡在 >> "@（here-string 未结束），所以 Add-Type 还没真正执行）

（PowerShell 一直停在 >> "@，提示“没有任何作用”。）

🔴 Claude

两个白窗加上那个 ⊘，基本能确定都是 GameViewerServer 在作妖——它其实是网易 UU 远程的后台组件（不是向日葵，我前面那句猜错了，但进程没认错）。刚更新 UU，它重启了这个组件，结果不光 ⊘ 没清掉，又多画了一个全屏白色 overlay。

另外：你贴的 PowerShell 停在 >> "@，说明 Add-Type 那段还没执行完——多行 here-string 需要再按一次回车结束。先回车让类建好，再扫描。

ShowWindow 隐藏没用，是因为进程还活着会立刻重画。别再单独隐藏窗口，直接结束这个进程最干脆。

🟢 楼主

问题是我现在在用 UU 远程控制这个电脑啊。

🔴 Claude

啊，这就是关键背景——你现在看到的整个画面是 UU 远程的远程桌面，GameViewerServer 正是 UU 在被控端渲染远程画面、画远程光标用的核心组件。结束它，很可能直接把你这条远程连接的画面掐了。所以有问题的进程，恰好就是维持你这块屏幕的进程。

（询问：你现在操作这台电脑的方式是“只能通过 UU 远程”，还是“人就在这台电脑旁”？）

🟢 楼主

我用向日葵登录了，退出了 UU 远程，但是它还在。

结束: GameViewerServer  PID=53908
完成
$res = [E3]::Find(1140, 570)   # 找不到类型 [E3]（新窗口，类没了）

🔴 Claude

情况好多了：你换成向日葵登录、退出了 UU，维持画面的已经不是 UU 了，刚才那条 Stop-Process 成功结束了 GameViewerServer，不会再断画面。[E3] 报“找不到类型”是因为这是新开的 PowerShell 窗口，类没了，重新粘一遍即可。重新扫描验证。

🟢 楼主

（重新定义 E3 后两次扫描，GameViewerServer 又回来了：）

===== 扫描点 1009,967 / 1140,570 =====
句柄=35396222 类名=GameViewerPrivateWindowClass 标题='G' PID=68104
  位置=(0,0) 尺寸=2560x1440 LAYERED CLICK-THRU TOPMOST 进程=GameViewerServer
句柄=920762 类名=CEF-OSC-WIDGET 标题='N' PID=52624
  位置=(0,0) 尺寸=2559x1440 LAYERED 进程=NVIDIA Overlay

🔴 Claude

画 ⊘ 的还是 GameViewerServer（新 PID 68104——你杀了 53908，它又自动重启了一个）。被杀后会被守护进程/服务自动拉起，所以单纯 Stop-Process 治标不治本。先看 UU 进程家族，或直接从托盘彻底退出 UU。

🟢 楼主

（图6：桌面白窗换了位置；右下角弹出向日葵“光无垠正在远程桌面”通知（23:27））

（执行了 Get-Process … GameViewer|uu|UULauncher … Stop-Process 后）就是换了个位置。

🔴 Claude

这条 Stop-Process 跑完没报错，但白窗只是换了个位置又出现——守护进程在你杀掉后立刻又把它拉起重画，每次重启位置会变。光靠杀进程断不了根。

另外提醒：右下角弹出“光无垠正在远程桌面”——说明现在有人正通过向日葵连进这台机器。如果不是你自己的设备在连，留意一下。

要彻底断根，得先看清是哪个服务/进程在当守护：列出 UU 相关进程 + 相关 Windows 服务。

🟢 楼主

UU 我能关的都关掉了。

===== UU 相关服务 =====
 Status   Name              DisplayName
 ------   ----              -----------
 Stopped  GameViewerService GameViewerService

Get-Process GameViewerServer  → 找不到名为 GameViewerServer 的进程

🔴 Claude

好消息：GameViewerServer 进程已经没了，守护服务 GameViewerService 也是 Stopped。背后没东西再拉活它了。但你那段扫描是旧输出。屏幕上的白窗很可能只是进程被杀后留在屏幕上没被擦除的最后一帧残影。先重新扫描确认，再刷新画面。

🟢 楼主

我要在不重启的情况下去除。重启我当然知道能去掉。

===== 扫描点 1009,967 / 1140,570 / 750,380 =====
句柄=920762 类名=CEF-OSC-WIDGET 标题='N' PID=52624 进程=NVIDIA Overlay
（GameViewerServer 已彻底消失，只剩 NVIDIA Overlay）

🔴 Claude

我没在让你重启电脑——下面的方法都不需要重启电脑。三个点都只剩 NVIDIA Overlay，GameViewerServer 已彻底没了。所以屏幕上的白窗如果还在，就是纯画面残影，只能靠强制重绘那块屏幕来擦掉：

• Stop-Process -Name explorer -Force（重启资源管理器，不是重启电脑）；
• Win + L 锁屏再解锁（整屏强制完整重绘，零风险）；
• 用 RedrawWindow 强制全屏重绘；
• 拿任意窗口在白窗位置来回拖动，逼系统重画。

🟢 楼主

都不行。

🔴 Claude

“锁屏再解锁会强制整屏完整重绘，如果连它都擦不掉，那这个白窗根本不在这台主机的画面里。”——我当时的推断：白窗可能卡在“向日葵远程客户端”那一侧的陈旧解码帧（脏矩形增量编码导致旧帧不刷新）。

做个决定性验证：让主机自己截一张图，检测白窗位置的真实像素（白窗中心 / ⊘ 位置 / 美洲狮背景对照）。

Add-Type -AssemblyName System.Drawing
$bmp = New-Object System.Drawing.Bitmap 2560,1440
$g = [System.Drawing.Graphics]::FromImage($bmp)
$g.CopyFromScreen(0,0,0,0,$bmp.Size)
# 采样三点 RGB，并保存 host_shot.png

🟢 楼主

（图7：主机自己截的图 host_shot.png：白窗 + ⊘ 真实存在于主机画面里）

白窗中心   (750,385)  RGB=(255,255,255)
⊘位置      (676,648)  RGB=(255,255,255)
美洲狮对照 (1500,750)  RGB=(255,255,255)   ← 连背景对照点也是纯白

# GDI 取色（GetPixel）复测：
原白窗 (750,385)       RGB=(255,255,255)
美洲狮对照 (1500,750)  RGB=(255,255,255)
左侧桌面图标区(300,400) RGB=(47,47,47)     ← 这点取到真实壁纸深色

🔴 Claude

两个发现：① host_shot.png 是主机自己拍的，白窗和 ⊘ 真实存在于主机画面里——排除“向日葵客户端缓存”的猜测；② 左侧图标区取到 (47,47,47) 真实壁纸色，证明 GDI 能读到真实屏幕。那白窗就是一个实打实盖在桌面上的不透明窗口。

之前所有扫描都漏了它，原因找到了：我的 Find 只收集带 LAYERED / CLICK-THRU 标志的窗口，而这个白窗两个标志都没有（普通不透明窗口），每次都被过滤掉。改用不带标志过滤的版本（E4）重扫。

🟢 楼主

[1] 类名=Chrome_WidgetWin_1 标题='鹹d枃e鯪thV媖Yuh ' PID=4696 尺寸=2575x1407 进程=chrome
[2] 类名=Progman PID=59828 尺寸=2560x1440 进程=explorer
[3] 类名=Windows.UI.Core.CoreWindow PID=11908 进程=TextInputHost
[4] 类名=CEF-OSC-WIDGET PID=52624 LAYERED 进程=NVIDIA Overlay

🔴 Claude

白窗没在列表里，但藏着一个嫌疑：一个 Chrome 窗口标题是一串乱码、尺寸几乎全屏、位置 (-7,-7)。乱码标题 + 全屏 + 置顶，很像一个渲染卡死的 Chrome 窗口。先核实 PID 4696 是不是卡死（看 Responding）。

$p = Get-Process -Id 4696
$p.MainWindowTitle; $p.Responding

🟢 楼主

进程: chrome  PID=4696
标题: '移除文件管理器残留图标 - Claude - Google Chrome'
响应中: True

🔴 Claude

真相：PID 4696 这个 Chrome 窗口，就是你正在用的、显示着这段对话的 Claude 页面（标题写得明明白白），响应中 = True，完全正常。我们很可能从某一步起，把“你的 Claude 浏览器窗口”误当成了那个幽灵白窗。它当然杀不掉——因为它是你正在用的工具本身。千万别对 PID 4696 做任何关闭操作。

🟢 楼主

不对，小图标的上方的的确确有个白色的长方形小窗口。

🔴 Claude

你是对的，我收回判断。桌面中间确实有一个独立的白色长方形小窗口，它上沿压着、下方紧贴着那个 ⊘，这俩是一体的；而 PID 4696 是你的 Claude 窗口，只是位置碰巧重叠被我混为一谈。这次彻底不设任何过滤，把覆盖该点的每一个可见窗口连同尺寸全列出来（E5）。

🟢 楼主

（白窗中心 736,379 附近，零过滤 E5 扫描）

覆盖该点的全部窗口（共 4 个，顶层在前）：
[1] 类名=CEF-OSC-WIDGET PID=52624 尺寸=2559x1440 LAYERED 进程=NVIDIA Overlay
[2] 类名=Windows.UI.Core.CoreWindow 标题='緥n' PID=6680 尺寸=943x491 位置=(0,1)-(943,492) 进程=SystemSettings
[3] 类名=Windows.UI.Core.CoreWindow 标题='W' PID=11908 尺寸=2560x1440 进程=TextInputHost
[4] 类名=Progman 标题='P' PID=59828 尺寸=2560x1440 进程=explorer

🔴 Claude

列表里冒出一个新面孔：943×491 的独立窗口，类名 Windows.UI.Core.CoreWindow（UWP 窗口），属主进程 SystemSettings（Windows“设置”应用）。推断：文件管理器卡死那一刻，一个半初始化的“设置”窗口卡住了，只画出白色窗口底（标题乱码）。结束 SystemSettings 进程即可，系统自带、无害。

Get-Process SystemSettings | Stop-Process -Force

🟢 楼主

仍然不行。（SystemSettings 也结束了，白窗依然在。）

🔴 Claude

那它也不是真凶。我们反复“猜一个→杀掉→还在”，是因为一直靠肉眼估坐标 + 单点扫描，每次都可能撞到旁边别的窗口。换个不靠猜的精确办法：用 WindowFromPoint 对 ⊘ 做命中测试，把命中窗口连同整条父子链打印出来。

🟢 楼主

== 命中点: 669,645 ==
【leaf】 类名=SysListView32     PID=59828(explorer)
【root】 类名=Progman          PID=59828(explorer)
【父链】SysListView32 → SHELLDLL_DefView → Progman （全是 explorer 桌面层）

🔴 Claude

决定性结果：⊘ 那个点命中的是 SysListView32 → SHELLDLL_DefView → Progman，全是 explorer（桌面图标层）。WindowFromPoint 会跳过透明穿透窗口、命中第一个“实心”窗口，它返回桌面，说明那个点上没有任何独立实体窗口挡着。这意味着 ⊘ 不是一个窗口——它要么画在桌面图标层上，要么是 DWM 合成层里的陈旧内容。先强制让桌面图标层（SysListView32 / DefView / Progman）自己重绘。

foreach($h in @($listview,$defview,$progman)){
  [RD]::InvalidateRect($h,[IntPtr]::Zero,$true)
  [RD]::RedrawWindow($h,[IntPtr]::Zero,[IntPtr]::Zero,0x04A5)
  [RD]::UpdateWindow($h)
}

🟢 楼主

（图8：强制重绘桌面图标层 + 发送桌面刷新，均成功执行，但大白窗与 ⊘ 仍在）

（两段都跑成功了，桌面图标层也重绘了，白窗和 ⊘ 纹丝不动。）

🔴 Claude

两段都成功却纹丝不动，排除了“画在桌面图标层”。结合命中穿到桌面、枚举又找不到实体窗口，只剩一个解释：它是 DWM（桌面窗口管理器）合成层里的残留——当年那个 overlay 的画面被 DWM 缓存进合成纹理，窗口销毁后这块合成内容没被正确失效。清 DWM 残留的标准做法是重启 dwm.exe（不是重启电脑，屏幕黑闪约 1 秒，所有窗口/连接不受影响）。

Stop-Process -Name dwm -Force   # 或 taskkill /F /IM dwm.exe

🟢 楼主

（图9：重启 dwm 后：大白窗消失了，但左侧的 ⊘ 仍在）

白窗消失了，但是 ⊘ 还在。

🔴 Claude

重启 dwm 起作用了——大白窗没了，证明它确实是 DWM 合成层残留。现在只剩 ⊘。它扛过 dwm 重启，说明它被某个进程主动、持续地画在那个固定位置：每次屏幕重绘都被重新画回来。重新用命中测试精确抓它，并用零过滤 E5 扫它那个点。

🟢 楼主

== 命中点: 1004,962 ==  【leaf】SysListView32 PID=59828(explorer)
--- 覆盖该点的全部窗口 ---
句柄=39199526 类名=GameViewerPrivateWindowClass PID=58436(GameViewerServer)
  尺寸=2560x1440 LAYERED THRU TOP    ← 又回来了
句柄=920762   类名=CEF-OSC-WIDGET    PID=52624(NVIDIA Overlay) LAYERED
句柄=656418   类名=Windows.UI.Core.CoreWindow PID=11908(TextInputHost)
句柄=526412   类名=Progman           PID=59828(explorer)

🔴 Claude

GameViewerServer 又自动重启了（新 PID 58436），有一个全屏 LAYERED+THRU+TOP 的覆盖层——画 ⊘ 的就是它；dwm 重启没清掉 ⊘，是因为这进程一直活着，dwm 重建合成树时它又把 ⊘ 画回去。要断根：先禁用守护服务再杀进程。

🟢 楼主

这个和 UU 和向日葵没关系，你所说的覆盖层是我在 UU 远程这个电脑的原因。你不要被误导。这个标志我说过了是从文件资源管理器拖图片到 chrome 里的 comfyui 界面的时候触发的。你好好想想办法。

🔴 Claude

你说得对，我被那个全屏覆盖层反复带偏了。重新抓住你一开始就说清楚的事实：这是一次没有正常结束的 OLE 拖放——从资源管理器拖图片到 Chrome 里的 ComfyUI，中途资源管理器卡死，拖放状态机卡在中途，⊘（拖拽“禁止放置”光标图像）没被释放。dwm 重启清得掉白窗却清不掉 ⊘，说明 ⊘ 是仍处于活动/显示状态的系统拖放图像，要从拖放状态本身下手。

• 方法一：ImageList_DragLeave / ImageList_EndDrag / ReleaseCapture 强制结束拖拽图像层；
• 方法二：补一次完整的鼠标按下→松开 + 一次 Esc，给卡住的状态机发“结束”信号；
• 方法三：在桌面空白处真实地发起并正常完成一次新的拖放（框选再松开），覆盖旧状态。

🟢 楼主

都不行。

🔴 Claude

拖放相关的招都不奏效，说明 ⊘ 已经不是“活动拖放状态”，而是一块纯视觉残留。它扛过 dwm 重启、又不属于任何可枚举窗口——推断它被烤进了 explorer 桌面图标层的绘制内容里。既然温和重绘清不掉，那就重启 explorer（销毁重建整个桌面外壳；不是重启电脑，且资源管理器正是当初卡死的源头，最对症）。

Stop-Process -Name explorer -Force; Start-Sleep 2; Start-Process explorer.exe

🟢 楼主

还是没有用。切换分辨率的时候，它也会跟着一起调整相对位置。

🔴 Claude

“切分辨率时 ⊘ 会跟着等比例调整相对位置”——这条当时让我转向：能跟着分辨率缩放移动的，似乎不是固定像素的本地残留，于是我推断它在向日葵控制端的远程画面里（被控端画面按比例缩放贴在控制端窗口里）。解决办法都在控制端：切画质 / 最小化还原 / 断开重连 / 重启本地向日葵客户端——全程不动被控机。

🟢 楼主

不可能，我之前现成用电脑的时候就存在着。

🔴 Claude

这条又是决定性的——你本地用机（无任何远程）时 ⊘ 就已存在，那它就是本地的东西，跟远程无关，我那个“在控制端”的判断错了。结合“本地 + 跟分辨率缩放”，我转而推断它被画在了壁纸/桌面背景层（壁纸按分辨率缩放贴合）。验证 + 解决：强制重设一次桌面壁纸，让 Windows 重新生成背景位图；或临时换纯色背景看 ⊘ 是否消失。

$cur = (Get-ItemProperty 'HKCU:\Control Panel\Desktop' -Name WallPaper).WallPaper
[WP]::SystemParametersInfo(20,0,"",0x03); Start-Sleep -m 300
[WP]::SystemParametersInfo(20,0,$cur,0x03)

🟢 楼主

也不可能，它悬浮在所有窗口之上。

🔴 Claude

又一条硬约束：它悬浮在所有窗口最顶层，任何窗口都盖不住它——那它绝不可能在壁纸层（壁纸在最底层）。把全部确认为真的硬事实求交集：① 本地存在；② 置顶；③ 随分辨率等比缩放移动；④ 扛过 dwm/explorer 重启；⑤ 鼠标可穿透（命中穿到桌面）。能同时满足这五条的，正是那个 GameViewerPrivateWindowClass 全屏 LAYERED+THRU+TOP 覆盖层——它开机自启常驻、平时透明看不见，⊘ 被印在了它这块画布上。

（建议：杀 GameViewerServer 进程 + 紧接着重启 dwm，把它画布的最后一帧也一起抹掉；若被守护拉活则临时禁用服务。）

🟢 楼主

还是不行，别禁用了，我还得远程呢，给我恢复的指令。

🔴 Claude

先恢复——把服务改回自动启动，别影响你远程：

Set-Service GameViewerService -StartupType Automatic
Start-Service GameViewerService
Get-Service GameViewerService | Select-Object Status, StartType, Name

诚实讲：本地能想到的层——合成层、外壳、桌面图标层、壁纸、拖放状态、各种覆盖进程——全试遍了都不奏效。这个 ⊘ 的特征组合（本地、置顶、可穿透、随分辨率缩放、扛 dwm/explorer 重启、且枚举不到对应独立窗口）非常反常，卡在了一个没能定位到的显示状态里。在“不重启电脑”前提下，我手里已没有更多稳妥的招。这类顽固显示残留，重启电脑是最干净可靠的解法，开机后必然消失、不复发（除非再次触发同样的拖拽卡死）。

折中验证：把显示器物理关掉再开 / 拔插视频线，让显卡重新输出整帧；若连这都清不掉，基本可确定软办法已穷尽。

整理说明

本文为人机排查对话的完整整理；过程中 AI 多次提出并自我推翻假设（孤儿窗口 → GameViewer 覆盖层 → 远程缓存帧 → 浏览器窗口 → SystemSettings → 桌面图标层 → DWM 合成残留 → 壁纸层），最终在“不重启”约束下未能根治，发帖征求更好思路。