It seems that somewhere in DO there is a leak of GDI objects, perhaps after calling the context menu something is not being freed?
Closing the lister does not help (GDI objects are not cleared, unlike, for example, explorer.exe). Ultimately, this leads to an unpleasant situationsituation where DO freezes, and the only thing that helps is restarting the process. No logs/dumps are saved.
see media below:
Have you eliminated third party context menu handlers? They’re more likely to cause a leak than opus itself, as least based on past issues.
Hello, thank you for your prompt reply.
Yes, disabling DO elements from the context menu helps. GDI handles stop increasing, but I have DO set as a replacement for Explorer, and it is inconvenient for me to press Shift every time.
I also open the context menu in the same folder, but using explorer.exe. In Task Manager, you can see that the number of GDI objects increases and decreases after closing the menu. This does not happen in DO (even if I close the lister). The number of GDI objects only increases. As soon as there are about 10,000 of them, DO naturally starts to malfunction. I have to restart it, which is inconvenient.
Are there any ways to locate the problematic extension? I enabled context_menu_debug but didn't understand where to look. There are no messages in Dbgview. (DO is not run as an administrator.)
That confirms the problem is in a shell extension something else has installed. (Almost certainly, at least.)
You can see a list of shell extensions under Preferences / Miscellaneous / Shell Extensions, in the Context Menu and Context Menu (UWP) categories.
Try disabling groups of those at a time to narrow it down to a particular extension. That's probably the quickest way to isolate it.
