Just now I believe that I did something that I have done without a problem hundreds of times, but this time it seemed to cause screen corruption, and unresponsiveness, within Opus.
The thing that I did was to right click an AutoHotKey script in order to use the right-click menu to compile the script. At some point within that procedure - or, possibly, upon running the compiled program - this occurred:
I have similar experience with right-click context menus. Although for me it happens once in 1-3 days. When it happens, graphics of every opened DOpus window (including tray icon menu) is getting screwed, and only full process reboot fixes that. Happens randomly, but the trigger is always the right-click context menu of a file/directory/directory background. How can I find out what could be an issue here?
And by the way, it is happening since like 13.10-13.11. Not a recent bug.
Open the Windows Task Manager (e.g. via right-click on the taskbar background).
Go to the Details tab.
Right-click the headings (Name, Status, CPU, etc. or similar), and then Select Columns.
About half-way down the list of columns, turn on:
Handles
User objects
GDI Objects
(The three are all close together. List isn't alphabetical.)
Click OK, and drag/resize the columns so they're visible.
Keep that open, and right-click one of the files you've seen the problem with. Do it a few more times, and check if the numbers for any of those three columns keep increasing. It's normal for them to fluctuate a bit, and also sometimes for them to go up the first time something is done, but they shouldn't keep increasing by a large amount over time.
If they keep increasing, that gives us a direction to look in next.
Another thing to try is turning on Preferences / Miscellaneous / Shell Extensions / Hide Windows & third-party items on file context menus (Shift overrides) to see if it has an effect. Since it's happening when you right-click, it's likely (but not certain) a shell extension is involved.
Thank you. Your diagnostic approach seems to be the right one. Here is why.
Each time I right-click-on-an-ahk-script the number of dopus.exe 'user objects' hits a new high and, when the right-click menu closes, the number of those objects remains higher than it was before the right-click. So there does seem to be some sort of leak here! I noticed nothing strange with the GDI objects.
I note also that when the corruption occurred I was doing a lot of right-clicking.
When I disable the extra context menu items, the problem - persistently increasing user-objects - does not occur.
Where then is the problem? With some content menu item? With how Opus handles that (buggy?) item? Both?
The Graphics Device Interface (GDI) has a per-process limit on the number of handles it can open. While the theoretical maximum is 65,536, the actual limit is often lower, influenced by available memory and is typically set to 10,000. This limit can be adjusted through the registry. (c) Google
I will try to increase the limit (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota value) and will see how it's going.
It would seem better to identify the root cause of that high number.
I ran into that when (poorly) building an app and solved it by design change.
Here, it most likely looks like there is a leak somewhere registering gdi objects and not freeing them correctly.
Increasing the limit will just delay the issue, and since it's a system wide parameter, every process will now be able to leak which can lead to more dangerous issues.
Can you think of a way of discovering the culprit(s), other than uninstalling programs (or in some other way removing their context menu items)?
Also: how come the native Windows Explorer does not suffer from the problem (presuming that it does not; I do not think that there I encountered the problem)? I suppose that on way would be to see whether there is an overlap of releant programs between affected users. So, for my part, I see entries from these programs in my context menu:
7-Zip
autohotkey
ESET Nod32 anti-virus
Faststone
SuperAntiSpyware
VLC media player
EDIT: Oh, also, OpenShell.
Further EDIT: I searched the web looking for reports of memory leaks in the above applications - and I found one for 7-Zip and though the report was from years ago the thread at issue does not say that a fix was committed.
Yes, I agree, of course. I've meant it only as a temporary workaround (I have more than enough RAM and GPU memory to not worry about it for now).
I've made a simple DLL that, when injected, produces infinite calls to CreateCompatibleDC(), and I can confirm that this exact behaviour happens again as soon as I get close to the system limit of GDI handles. When I clear all my DCs everything seems to be back to normal without process restart (just with lister reopening).
The new title does not fully represent the problem. I have nothing to do with AHK files, yet I experience the same problem.
I will check with shell extensions disabled (checkbox that you suggested initially), but maybe Opus could implement some system to help monitor these situations?
Thanks. I am afraid that I manage to cast no light: with all the extensions disabled (or, as Opus says, 'blocked'), there is no leak, and with every subset of extensions that I tried (or at least every alphabetically contiguous subset) there is a leak.
Sorry about that. I've changed it again to remove that part.
We do report some problems with context menu extensions, but it's not possible to predict every way 3rd party code might go wrong when running in our process.
Context menu extensions leaking GDI handles (or doing something which causes us to leak them, if the fault is on our side) isn't a common issue, so we would never have thought to monitor it.
It's possible there are multiple extensions (maybe all part of the same package) which have/ or trigger the problem, and they're spread over different parts of the list.
Try re-enabling a few at a time. Once it starts happening, disable some of the ones which were just enabled, to see when it stops happening again. It should be possible to narrow it down to a particular extension in a few steps.
It's only the Context Menu and Context Menu (UWP) extensions you need to worry about. The other types shouldn't be a factor.
Thanks Leo (and PassThePeas). I add that I find that, helpfully, Opus allows sorting items within any given group, e.g. 'context menu', by 'product name'.
I seem to have three leakers. They are:
lock hunter (slight leak)
super antispyware (moderate leak)
Eset (big leak)
So, what now? Should I try to bug reports on each of those programs?
