Using Win 10 pro x64 (1909) standalone (not part of domain), with plenty of CPU and RAM resources. This is a not a vm or container , it is a bare-metal workstation. C: is an HDD, 1.5 Terabytes with around 400 GB used.
In a CMD.EXE window running as Administrator, when I use the
dir /s patternToMatch to search for files (always starting from the root), the internal dir command finds the first matching file (if there is one) and then never completes. It does not matter what pattern I use.
It seems to hang. I can interrupt it with control-C. It happens every time. It worked ok in the past on this workstation with earlier builds of Win 10.
The pattern can be a single file name, with no wildcards or special characters, and the symptom does not seem to vary with the pattern.
Setting DIRCMD environment to /s does not change the symptom.
There are no errors or messages shown on screen. I waited a couple of hours.
I can't see anything in the eventvwr that might be relevant.
All filesystems are NTFS.
The workstation has 4 other NVME drives (of which only 2 are visible to Windows, i.e D: and E:) , and D: also shows the same symptom when
DIR /s happens from the root. But the E: drive does not show the symptom.
cd c:\users and issue a
dir /s from there, then the symptom repeats. But if I
cd c:\users\me and run
dir /s then it will find the file(s) if they exist and not hang.
There are no hardware errors reported. The machine has the latest BIOS and firmware from the manufacturer.
symptom does not change with a non-admin user performing the search
ran CHKDSK /F on D: (nvme) with forced dismount, then run
dir /swith current directory
D:\, symptom is not changed, still hangs.
ran CHKFSK at boot time on C: , needed reboot, but the symptom is unchanged afterwards.
I find that of the three Windows drives C: and D: and E:, only C: and D: are impacted by this symptom. So there must be something in the filesystem(s) on C: and/or D: , not relevant for chkdsk that influences the symptom. I will check for junctions.