TC leaks GDI handles on opening the rightclick menu

[Mithaldu]

(This has been a problem in earlier versions too.)

Short description:
Certain actions that cause TC to render GUI elements, make it allocate GDI handles, but not free them up. This causes TC to accumulate more and more of them over time. This is a problem as they are a limited ressource. A lack of GDI handles available in the system can cause GUI drawing to fail in TC and worst of all, also in other programs. (I usually notice this is happening when other programs I'm using start getting corrupted UI.)

Steps to reproduce:
1. Fresh install of 7.55 public beta 1
2. Install MS Technet Process Explorer: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
3. Run Process Explorer
4. in Process Explorer, right-click column titles, click "select", enable "GDI Objects" in "Process Memory" tab
5. Run TC
6. Note current GDI handle count for TC process and watch it over next few actions
7. Rightclick any file or directory and hold button pressed to open the windows context menu
8. Repeat 7. a few times

Observed behavior:
After each opening of the context menu the GDI count rises a bit and lowers a bit after closing it again. It does however not lower back to its original level. Over time the GDI count will keep rising with repeat of this procedure.

Expected behavior:
GDI count should always return to the same level after such actions.

Additional notes:
I think the little timer bar that pops up is at fault here.

I did not do a very thorough search for other actions that can cause this. I highly suspect there are more.

[petermad]

I think the little timer bar that pops up is at fault here.

Have you tried with ContextProgress=0 to disable that ?

[Mithaldu]

Where/how would i do that? I looked through the settings dialog and couldn't find something to that effect.

[MVV]

Where/how would i do that? I looked through the settings dialog and couldn't find something to that effect.

Press F1, choose paragraph 4.b - it describes all INI keys including this one. You will find it in [Configuration] section - so you just need to add it into this section of wincmd.ini.

[HolgerK]

2Mithaldu

I don't think TC is to blame here.

1. The drawing of the context menu is done by a system function
2. Even Explorer.exe sometimes shows memory leaks in context menus.
3. The theoretical limit for GDI handles is 2^32 (per process!)
4. In opposite to Explorer it is very simple to restart TC to free GDI resources
5. Some shell extensions are doing things like owner drawn menu items. They may load bitmaps objects and cache them for later use, or even forget to free them after drawing.

For GDI-object debugging purpose NirSoft:GDIView is the better choice than ProcessExplorer.
For temporary deactivating suspicious colorful context menu entries NirSoft:ShellExView is the first choice.

Regards
Holger

[Boofo]

TaskInfo is also a good choice to view GDI handles.

[Mithaldu]

Where/how would i do that? I looked through the settings dialog and couldn't find something to that effect.

Press F1, choose paragraph 4.b - it describes all INI keys including this one. You will find it in [Configuration] section - so you just need to add it into this section of wincmd.ini.

Thanks. Tested it and it still happens with that off.

I don't think TC is to blame here.

Alright, you make some good points there. Though there is one i need to qualify:

3. The theoretical limit for GDI handles is 2^32 (per process!)

"In theory." In practice it is sufficient to have a process use 2000-4000 in order to cause GUI drawing operations to corrupt or outright fail system-wide. I know this because i tend to leave my box and thus also the programs running for weeks on end and usually have this problem pounce on my unawares.


Also, i seriously hope that this is not going to be the end solution:

4. In opposite to Explorer it is very simple to restart TC to free GDI resources

Even if the problem cannot be outright fixed in TC, I don't think it would be unfair to ask for a feature of having it check its GDI object count in regular intervals and prompt the user for a restart if it goes above 2000 or just plain restart itself if it has been idle for a while.

[HolgerK]

2Mithaldu
Did you tried this:

For temporary deactivating suspicious colorful context menu entries NirSoft:ShellExView is the first choice.

I dont think that TC should monitor GDI Resource usage and restart itself (or the system ) just because a faulty shell extension is wasting system resources.

Regards
Holger

[Mithaldu]

Did you tried this:

Not yet, but i will.

I dont think that TC should monitor GDI Resource usage and restart itself (or the system ) just because a faulty shell extension is wasting system resources.

I was not talking about the system. And obviously this should be an option, not something forced. More importantly though:

I do not think that I should need to monitor GDI usage manually and restart it manually.

(Please don't tell me i really need to explain why i think this repetitive and easily automated task would be better handled by software than requiring me to waste my time on it.)

[ND]

Running TC 7.55b1 on WinXP Pro SP3, I did not reproduce the problem. I used default Task Manager (enabled the "USER Objects" and "GDI Objects" columns), and the GDI Objects number never increased past +10 after first starting the test, no matter how many times I opened the context menu, and no matter what kind of files/directories.

1. The drawing of the context menu is done by a system function

Since that is the case, I too suspect a faulty Shell Extension here. My system must be clean :) since it's not showing this problem.

2. Even Explorer.exe sometimes shows memory leaks in context menus.

@ghisler(author): Please don't implement any "GDI objects monitoring" in Total Commander. I would consider this "bloat", because this "feature" does not belong in TC (the problem can appear also outside TC). There are more important features needed in TC (the Suggestions thread is full of them).

[Mithaldu]

2Mithaldu
Did you tried this:

For temporary deactivating suspicious colorful context menu entries NirSoft:ShellExView is the first choice.

Update on this: Just spent an hour poking through things (as a programmer i have lots of tools installed which i need to earn my daily bread). Rightload was the culprit and i can live without it.

This fixed the problem for me.

However i must say that a GDI watcher would still be a good thing. Not every user is as technical as I am, and it is unfair to not help those when the cause is known and a workaround easily done.

[ghisler(Author)]

Indeed I'm not aware of any GDI leak in the TC right click context menu, but Explorer extensions may of course have such leaks.

[Mithaldu]

Brilliant. People who have this problem will find completely unrelated programs mysteriously corrupted. In order to figure out what's going on they need to make the lucky guess of blaming GDI object limits, guess that it's the context menu, guess that it's the extensions in there and to boot dig through a ton of registry entries, pray that the culprit is not a critical tool and if it is, hope they can get that author to fix it, and if not, keep manually monitoring and restarting TC.

You're in a perfect situation to at least take the first three steps out there, as well as the last one.

But your answer is merely "Pfft, I could help, BUT: Not my turf!"

You really don't give a damn about your customers, huh?

[HolgerK]

2Mithaldu

Don't you think you've posted your complaint in the wrong forum?

http://developer-community.com/forums/index.php/board,1.0.html

Regards
Holger

[Mithaldu]

No, this is exactly the right forum. TC is the only component that's at the root of this and the only thing able to address it in a global manner.

Rightload will not be the only extension to exhibit such behavior. Getting them to fix it still leaves people without a fix who have other extensions with the same problem or still use an older version of that extension. (There's no auto-update mechanism.)

Even a simple warning to ask people to investigate their extensions if the GDI count explodes would be perfectly fine.

Don't look at it from the perspective of how to do the least work possible, but of how to help the most people.

Edit: In fact, i just noticed similar leaking on my Win 7 box, which does not have rightload installed, only Winrar and TortoiseSVN. (And trying too do stuff with GDIView flat out crashed it, nice.)