I'm trying to track down an issue in our MFC code that looks like a resource limitation issue. Memory and CPU look fine. According to the processes tab on the Task manager our GDI objects look in line with other applications, but our USER objects appear to be a factor of 10 greater then other applications.
What is a "USER object" and what are the limits?
Here is a "classic" MSDN article: Give Me a Handle, and I'll Show You an Object
Last time I was tracking down Windows object leaks (which i suspect you have) Process Explorer was handy (handley?). The lower-pane could show some allocated system objects, plus it could do the simple USER, GDI, etc object counting.
The desktop heap, which is a pool of memory where the real "stuff" the handle represents lives (at least some handles, not kernel handles at least). It's sometimes not so much how many handles you have allocated but how much memory each object under that handle is using. You can debug the heap this way. It is a pain to install.
Read all about it here:
Object Categories
The system provides three categories of objects: user, graphics device interface (GDI), and kernel. The system uses user objects to support window management, GDI objects to support graphics, and kernel objects to support memory management, process execution, and interprocess communications (IPC). For information about creating and using a specific object, refer to the associated overview.
and here:
User Objects
User interface objects support only one handle per object. Processes cannot inherit or duplicate handles to user objects. Processes in one session cannot reference a user handle in another session.
There is a theoretical limit of 65,536 user handles per session. However, the maximum number of user handles that can be opened per session is usually lower, since it is affected by available memory. There is also a default per-process limit of user handles. To change this limit, set the following registry value:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuotaThis value can be set to a number between 200 and 18,000.
Mark Russinovich is an expert on the subject. He has written the book "Windows Internals". Luckily, there's not only the book but also an article dating 2019-06-27.
First he describes USER objects:
USER objects get their name from the fact that they represent user interface elements like desktops, windows, menus, cursors, icons, and accelerator tables (menu keyboard shortcuts).
And then continues describing the limits:
A basic limitation imposed by the window manager is that no process can create more than 10,000 USER objects.
and
One fundamental limitation on the number of USER objects comes from the fact that their identifiers were 16-bit values in the first versions of Windows, which were 16-bit. When 32-bit support was added in later versions, USER identifiers had to remain restricted to 16-bit values so that 16-bit processes could interact with windows and other USER objects created by 32-bit processes. Thus, 65,535 (2^16) is the limit on the total number of USER objects that can be created on a session
He also explains the number mentioned by @Tobi:
for historical reasons, windows must have even-numbered identifiers, so there can be a maximum of 32,768 windows per session
I don't know what they are, but I do know they include window handles.
For window handles there is a system wide maximum of about 32000, and a per process maximum of 10000. (This may just be USER object limit, instead of just window handles.)
The number of window handles may be very high if some way you are leaking window handles, or if you use huge amounts of windows. (Note that even simple controls like a text label consumes a single window handle.)
