Severe Virtual Memory Usage Issue When Opening Large SMB Directories in Directory Opus

Help & Support
1

Problem Description:

When I open a network path via SMB in Directory Opus that contains a large number of subfolders (e.g., 3000 folders), the dopus.exe process commits an enormous amount of virtual memory. According to VMMap, this memory remains committed even after the directory contents have fully loaded and are no longer needed.

As a result, the system starts to slow down significantly, and if I open another similarly large folder, other applications on the system crash due to insufficient memory.

For instance, the Windows Event Viewer shows the following warning:

Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: dopus.exe (21240) consumed 58,869,440,512 bytes...

Troubleshooting & Observations:

  • I followed the guide: How to find components causing memory leaks.
    • The first non-Windows component listed is dopus.exe, indicating it is responsible for the excessive memory commitment.
  • Using VMMap:
    • When browsing local paths with even thousands of subfolders, this issue does not occur—memory is committed temporarily and properly released after loading.
    • The problem only occurs on SMB network paths with large content.
    • When fewer items are present, memory is also released correctly.
  • I do not have any third-party plugins installed in Directory Opus.

Environment:

  • Directory Opus version: Directory Opus 13.14 Build 9215 x64 | OS 10.0 (B:26100 P:2 T:1) SP 0.0
  • OS: Windows: Windows 11 professional, 24H2
  • CPU: AMD Ryzen 7 6800H with Radeon Graphics 3.20 GHz
  • Physical memory: 32 GB

image
image2556×1596 377 KB

Please advise if there’s any known fix, configuration tweak, or diagnostic method I can try to further narrow down the cause. This issue is currently severely affecting system stability when browsing large network directories.

THANKS!

1 Like
2

Can you post a screenshot of the Opus window so we can see which details it's displaying?

Have you checked what happens when File Explorer shows the same folder?

Is flat view or expandable folders being used?

3

Sure. This is what happened when opening a folder that contains 2710 subfolders👇

4

BTY, I've noticed that when opening SMB network folders in Directory Opus, the loading speed is much slower than Windows File Explorer (As shown in the previous video). I’ve also compared it with a basic WebDAV browser I wrote using Python's webdav4 library — surprisingly, even that loads faster than DOpus in many cases.

Hopefully this can be improved in a future update.

5

Could you save those VMMap results, zip and send them via private message? We should be able to use those to see which code is allocating the memory.

(File > Save As in VMMap after the results you want are visible in it.)

6

Sorry, but I’ve tried multiple times and still wasn’t able to save the results — even with folders that contain fewer items.
Is there any workaround, or maybe some other info I could provide to help?

7

What goes wrong? Is it an issue in VMMap or Opus?

8

It's VMMap. It takes a loooong time but still failed to save the .mmp results. I can only save the .csv and .txt results.
dopus.txt (114.2 KB)
dopus.csv.txt (269.5 KB)

9

The txt/csv versions don't include the stack data we need, unfortunately.

Do you mean VMMap seems to be freezing when saving the data? Or is there an error message? How long did you wait for it to complete?

10

When the remote SMB folder was still loading in Directory Opus (abount 40G virtual memory was committed by dopus at that time), I saved vmmap's analysis results as file1. This operation took approximately 15 minutes to complete (significantly longer than expected).

After the SMB folder fully loaded in Directory Opus, I attempted to save another vmmap result as a .mmp file. vmmap.exe immediately entered a "Not Responding" state. VMMap.exe began consuming increasing amounts of system memory (see attached screenshot). After 4 hours, the memory usage had grown up to 18G, yet the export operation never completed.

During a prior export attempt under similar conditions, the system triggered a Blue Screen of Death.