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.

If I 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.

Any suggestions?


  • symptom does not change with a non-admin user performing the search

  • ran CHKDSK /F on D: (nvme) with forced dismount, then run dir /s with 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.

  • 1
    /a is attributes, it's expecting a second value like /a:D for Directories or /a:H for hidden files. What are you trying to achieve with /a? – spikey_richie Feb 14 at 13:25
  • Try set dircmd=/s && dir PATTERNTOMATCH . BTW, what is the pattern you are trying to match? Please click edit and provide that information. – K7AAY Feb 14 at 17:21
  • @spikey_richie: A bare /a is also valid and will show all files regardless of their attributes (i.e. normal and hidden/system). – user1686 Feb 14 at 17:34
  • If the file-system does not respond correctly it is usually a good time for a chkdsk C: /F run... – Robert Feb 14 at 18:43
  • @mao Have you tried to identify in which directory the command hangs? e.g. via Sysinternals ProcessMonitor and filtering for file events of cmd.exe. – Robert Feb 14 at 19:04

The immediate cause of the symptom was that C:\ProgramData\Docker (on HDD) was a junction to D:\ProgramData\Docker (on NVME).

Clearing Docker-Desktop cache and uninstalling Docker Desktop, then removing this junction resolved the symptom. So the dir /s command behaves correctly now.

I don't know if this behaviour is a by design or not.

It seems that Docker Desktop for Windows could only work with C:\ProgramData\Docker and making that a junction (to exploit the NVME speed for docker build actions) has undesirable side effects.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.