使用 Win 10 pro x64 (1909) 独立版（不是域的一部分），具有充足的 CPU 和 RAM 资源。这不是虚拟机或容器，而是裸机工作站。C：是 HDD，1.5 TB，已使用约 400 GB。
在以管理员身份运行的 CMD.EXE 窗口中，当我使用dir /s patternToMatch搜索文件（始终从根目录开始）时，内部目录命令找到第一个匹配的文件（如果有的话），然后永远无法完成。无论我使用什么模式，都没有关系。
它似乎挂了。我可以用 Control-C 中断它。每次都是这样。过去，在装有早期版本的 Win 10 的工作站上，它运行正常。
该模式可以是单个文件名，没有通配符或特殊字符，并且症状似乎不会随着模式而变化。
将 DIRCMD 环境设置为 /s 不会改变症状。
屏幕上没有显示任何错误或消息。我等了几个小时。
我在 eventvwr 中看不到任何可能相关的内容。
所有文件系统都是 NTFS。
工作站有另外 4 个 NVME 驱动器（其中只有 2 个对 Windows 可见，即 D: 和 E:），并且DIR /s从根目录发生时 D: 也会出现相同症状。但 E: 驱动器没有出现症状。
如果我从那里cd c:\users发出dir /s，则症状会重复出现。但如果我cd c:\users\me运行，dir /s则它会找到文件（如果存在）并且不会挂起。
没有报告硬件错误。机器具有制造商提供的最新 BIOS 和固件。
有什么建议么？
更新：
非管理员用户执行搜索时症状没有改变
在 D: (nvme) 上运行 CHKDSK /F 并强制卸载，然后
dir /s使用当前目录运行D:\，症状没有改变，仍然挂起。启动时在 C: 上运行 CHKFSK，需要重新启动，但之后症状没有变化。
我发现在三个 Windows 驱动器 C:、D: 和 E: 中，只有 C: 和 D: 受到此症状的影响。因此，C: 和/或 D: 上的文件系统中一定存在与 chkdsk 无关的因素，而这些因素会影响此症状。我将检查连接点。
答案1
导致该症状的直接原因是 C:\ProgramData\Docker（在 HDD 上）与 D:\ProgramData\Docker（在 NVME 上）是连接点。
清除 Docker-Desktop 缓存并卸载 Docker Desktop，然后删除此连接即可解决此问题。因此，该dir /s命令现在可正常运行。
我不知道这种行为是否是设计使然。
似乎 Windows 版 Docker Desktop 只能与 C:\ProgramData\Docker 一起使用，并且将其作为连接点（利用 NVME 速度进行 docker 构建操作）会产生不良的副作用。