TC leaks GDI handles on opening the rightclick menu

[HolgerK]

As these bugs can also happen in explorer(or any other file manager) and TC can of course not work around it then (only the resources of the current process will be freed), the only solution that would help most people is to fix such bugs at the source and not to try to work around.

Regards
Holger

[Mithaldu]

And now you explain to me how people are supposed to identify the source if they do not get a single indicator or hint as to what the source might be.

It took me literally more than a year as well as a number of lucky coincidences to even get to this point.

[HolgerK]

And now you explain to me how people are supposed to identify the source if they do not get a single indicator or hint as to what the source might be.

They usual ask elsewhere in a computer problems related forum?

Sorry, but following your argumentation even a virus scanner should be integrated into TC.

Regards
Holger

[Mithaldu]

They usual ask elsewhere in a computer problems related forum?

That was a rethorical question.

Here's what will really happen: The average computer user will think it's Windows' fault being unstable and reboot it every week. They won't even get the idea that that sort of behavior might be odd since there is a complete lack of indicator of a cause and the behavior goes along with Windows' reputation.

Even if they asked in a technical forum it's very unlikely that many people there would even know that:
* "my app's title bar went black"
* "all my icons are in 16 colours"
* "when i type the cursor moves but no letters appear"
* "app x opens a new window but it stays grey and freezes"
Are indicators of a GDI issue, as opposed to a gfx-card/gfx-driver/memory/whatever issue. So they'll run the poor dude through a gauntlet of hardware checks, probably get him to buy new stuff, but do nothing to fix his problem because the root cause is so damn random.

Sorry, but following your argumentation even a virus scanner should be integrated into TC.

Ja, aber nur wenn man Till Eulenspiegel heisst.

More serious answer: No, it would not, since Windows itself already handles that by performing continuous security updates and warning the user if no AV is present or the AV is not up-to-date. TC would not be at the root for this and the actual root already handles it.

[HolgerK]

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

How should an option (turned off by default) should help any average computer user?

Regards
Till (der der Eule den Spiegel entgegen hält)

[Mithaldu]

The automatic restart of TC should be optional, not the checking itself.

The checking wouldn't even need very much cpu or whatever, since once per hour would be fine. If the GDI count is too high, pop up a window stating that there might be a problem with it, offer to restart TC, to start doing it automatically or to stop checking.

This would inconvenience noone, give the more technically inclined a hint as to how to fix things and make it possible for the less technically inclined to ignore the issue.

[HolgerK]

2Mithaldu
If you think it would be a good function for a file manager just post a suggestion here.
Maybe you will get some support then and convince Christian to implement such a function.
For me i will stop this endless discussion here.
I don't need such an option, and I don't think it's usefull.
Last time I run in such a problem was at the time I used Win NT4.0. Okay may be I'm not an average user.

Regards
Holger

[j7n]

This problem hasn't been an issue on any NT system, which on which GDI resources are plentiful compared to 9x, even when Total Commander is left running for weeks. However, I still like to my systems to work perfectly, and avoid restarting when at all possible.

I've tracked down this problem on my installations to UnlockerShellExtension. Other shell extensions, even with graphics on the menu, did not cause the problem, nor did TC when all ContextMenuHandlers were disabled.

Image: http://dl.dropboxusercontent.com/u/61700377/screens/total-gdi-leak-0.png

total-gdi-leak-1.png

At this stage my test system became unstable, pressing Print Screen was only possible after a few other processes were closed.

To identify the cause of this problem all shell extensions must be disabled, TC restarted, and the extensions added back one by one, again, each time restarting TC, and testing for the leak.

Shell extensions are registered in these registry keys. An extension might also be defined for each file type/extension.

Code: Select all

HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Directory\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Folder\ShellEx\ContextMenuHandlers

Copy the CLSIDs to Notepad, and remove all shell extensions. Then add them back into the original keys, one by one.

To mitigate GDI leaks occurring in any application on Windows XP, when enough memory is available, increase the respective limits imposed on each process as well as the system total resource pool. It may or may not work in other versions of Windows NT.

Code: Select all

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]
"GDIProcessHandleQuota"=dword:00002710
"USERProcessHandleQuota"=dword:00002710

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems]
"Windows" ....  SharedSection=1024,3072,512

Code: Select all

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]
"GDIProcessHandleQuota"=dword:00004000
"USERProcessHandleQuota"=dword:00004000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems]
"Windows" ....  SharedSection=1024,8192,512

Articles:
http://stackoverflow.com/questions/9723470/whats-the-upper-limit-on-gdi-objects-for-one-process-in-windows-7
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724291(v=vs.85).aspx

Reboot. Now test if the limit has been increased beyond 10,000 with the offending ContextMenuHandler active by holding down Shift-F10 with the mouse pointing at a file. This simulated about 25 right-clicks per second, leaking GDI at that rate.

Screenshot of my other system with the patch: http://dl.dropboxusercontent.com/u/61700377/screens/total-gdi-leak-2.png

[HolgerK]

This may be a dangerous hack:

Even if a program goes haywire, there's still around 20,000 objects available for the other programs to use. One of them might even be Task Manager, which the user fired up in order to kill the runaway program.

Regards
Holger

[j7n]

In my case the problems began (couldn't print screen, or paste the result in IrfanView), at about 11500 handles, out of which 10,000 were consumed by TC. So the default limit won't be enough to save the situation. My respect for TC increased greatly: it didn't crash and could be closed gracefully.

The most import part of my suggestion is to increase the memory space (desktop heap) that can be used for all applications.

Since Vista SP1 the default was already increased to 12 MB. The adjustment brings one of the few NT6 improvements to XP. I don't know what the limits of Win2000 are exactly, so I only advise this for XP/2003.

[HolgerK]

The most import part of my suggestion is to increase the memory space (desktop heap) that can be used for all applications.

You should pay attention to what Mark said in his blog:

Unlike USER objects, GDI objects aren’t allocated from desktop heaps; instead, on Windows XP and Windows Server 2003 systems that don’t have Terminal Services installed, they allocate from general paged pool; on all other systems they allocate from per-session session pool.
...
The GDI object memory limit on these systems is therefore the paged pool limit, as described in my previous post, Pushing the Limits of Windows: Paged and Nonpaged Pool. However, when Terminal Services are installed on the same Windows Server 2003 system, you can see from the non-zero session pool usage that GDI objects come from session pool

Still thinking that such hacks do not increase the overall stability of a system.
Much easier to restart an application, or to deactivate faulty context menu handlers and replace the functionality with an command line tool.

Regards
Holger