GDI Objects Test

An object is a data structure that represents a system resource, such as a file, thread, or graphic image. An application cannot directly access object data or the system resource that an object represents. Instead, an application must obtain an object handle, which it can use to examine or modify the system resource. There are three categories of objects: user, GDI, and kernel. GDI objects support graphics. Here is a list of the GDI objects used in Windows:

  • Bitmap
  • Brush
  • Device Context (DC)
  • Enhanced Metafile
  • Enhanced-metafile DC
  • Font
  • Memory DC
  • Metafile
  • Metafile DC
  • Palette
  • Pen/extended pen
  • Region

GDI objects support only one handle per object, and only the process that created the object can use the object handle.

If an application creates a lot of these objects, without properly destroying references to the object (by closing the associated handle), then there will be multiple GDI objects occupying memory on the system for each object created. If this GDI leak is really bad, this can eventually bring a server to its knees, and cause all types of problems (slow logons, registry issues, system hangs, and so on).

If such fatalities are to be avoided, administrators should closely monitor the number of GDI object handles created by every user to the Microsoft RDS server and proactively detect potential GDI leaks. This is where the GDI Objects test helps. This test periodically checks the GDI object handles created by each user to the Microsoft RDS server, reports the total number of handles created per user, and promptly notifies administrators if any user is creating more GDI handles than permitted. This way, the test brings probable GDI leaks to the attention of administrators. In addition, administrators can use the detailed diagnosis of the test to know which process is responsible for the GDI leak (if any).

Target of the test : A Microsoft RDS server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each user to the Microsoft RDS server being monitored

Configurable parameters for the test
Parameters Description

Test period

This indicates how often should the test be executed.

Host

The host for which the test is to be configured.

Port

Refers to the port used by the Microsoft RDS server.
GDILimit

Specify the maximum number of GDI object handles that a user to the Microsoft RDS server can create. By default, this value is 10000.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Total GDI objects

Indicates the total number of GDI handles that this user has created.

Number

The detailed diagnosis of this measure, if enabled, provides the process-wise breakup of the GDI handles created by the user. In the event of a GDI leak, this information will enable you to figure out which process initiated by the user spawned the maximum number of GDI handles, and is hence responsible for the GDI leak.

Percentage of GDI objects

Indicates what percentage of the configured gdilimit is the total number of GDI object handles created by this user’s processes.  

Percent

This value is calculated using the following formula:

Total GDI objects/GDILimit * 100

A value close to 100% is a cause for concern, as it indicates that the count of GDI handles for the user is fast-approaching the permitted gdilimit. This hints at a potential GDI leak. You can then use the detailed diagnosis of the Total GDI objects measure to identify which process initiated by the user is spawning the maximum GDI handles and is hence contributing to the leak, and probe further. 

The detailed diagnosis of the Total GDI objects measure, if enabled, provides the process-wise breakup of the GDI handles created by the user. In the event of a GDI leak, this information will enable you to figure out which process initiated by the user spawned the maximum number of GDI handles, and is hence responsible for the GDI leak.

gdiobjdd

Figure 1 : The detailed diagnosis of the Total GDI objects measure