SOLIDWORKS GDI Objects Limit: How to Fix the 10,000 Crash With the Registry

If SOLIDWORKS warns that it is running low on system resources, its icons go blank, and then it closes without an error, check its GDI objects. Windows lets one program hold 10,000 of them by default. You can see the count in Task Manager and raise the limit with one registry value, GDIProcessHandleQuota.

I see this every few weeks on customer machines, usually on long working days or on computers that run SOLIDWORKS batch jobs for hours. Here is how I check it and how I fix it.

What GDI objects are

Windows draws every window, icon, font and bitmap with GDI objects. SOLIDWORKS creates them for each open document, drawing view, PropertyManager page, task pane and add-in. They should be released when you close a file, but not all of them are. Over a long session the number climbs, and when it reaches the limit Windows refuses to create more. SOLIDWORKS can no longer draw its own interface, and it crashes.

Signs you are hitting the limit

• The SOLIDWORKS Resource Monitor warns that system resources are running low, even though you have plenty of free memory.
• Toolbar icons, menus or dialogs show up blank or half drawn.
• SOLIDWORKS closes without an error after hours of work, or in the middle of a long batch job such as a PDM task or a macro that processes many files.
• Task Manager shows SLDWORKS.exe close to 10,000 GDI objects.

Check the GDI object count in Task Manager

The GDI objects column is hidden by default. To show it:

1. Press Ctrl+Shift+Esc to open Task Manager and go to the Details tab.
2. Right-click any column header and choose Select columns.
3. Tick GDI objects, and USER objects while you are there, then click OK.
4. Find SLDWORKS.exe in the list and read its GDI objects value.

A few thousand is normal. What matters is the trend: open and close a few files and watch the number. If it keeps climbing and never comes back down, something is not releasing its objects. If it passes 8,000, save your work and restart SOLIDWORKS before it crashes.

Raise the limit in the registry

The limit is set by GDIProcessHandleQuota. You need administrator rights, and the change applies to every program on the computer, so back up the registry first.

1. Press Windows+R, type regedit and press Enter.
2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows.
3. Double-click GDIProcessHandleQuota, select Decimal and enter 20000.
4. Do the same for USERProcessHandleQuota and enter 15000. USER objects hit the same kind of wall with large assemblies and many open windows.
5. Restart Windows. The new limits only apply after a restart.

To set the same values on many computers, save this as a .reg file and run it, or push it with your usual deployment tool:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]
"GDIProcessHandleQuota"=dword:00004e20
"USERProcessHandleQuota"=dword:00003a98

The values are hexadecimal: 4e20 is 20,000 and 3a98 is 15,000. If you prefer PowerShell, run this in an elevated window:

$key = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows'
Set-ItemProperty -Path $key -Name GDIProcessHandleQuota -Value 20000 -Type DWord
Set-ItemProperty -Path $key -Name USERProcessHandleQuota -Value 15000 -Type DWord

How high should you go?

Microsoft allows GDIProcessHandleQuota between 256 and 65,536, and USERProcessHandleQuota between 200 and 18,000. Do not go straight to the maximum. All programs in your Windows session share one pool of about 65,536 GDI handles, and raising the limit does not add memory. One program allowed to take almost the whole pool can starve everything else. I use 20,000 for GDI objects and 15,000 for USER objects, which gives SOLIDWORKS plenty of room without risking the rest of the system.

Fix the cause too

A higher limit buys time. If the count keeps climbing, find what is holding on to objects:

• Add-ins. Turn them off one at a time in Tools, Add-Ins and watch whether the count still climbs.
• Long sessions. Restarting SOLIDWORKS once or twice a day resets the count.
• Batch jobs. Macros, PDM tasks and API tools that open thousands of files in one session should close every document and restart SOLIDWORKS between batches.
• Your own code. If you write SOLIDWORKS add-ins or macros, see SOLIDWORKS API memory access violations caused by GDI object count and unreleased COM objects for the coding side of this problem.

FAQ

Do I need to restart the computer?

Yes. Windows reads the limits when it starts, so the new values apply after a restart.

Does this change affect other programs?

Yes, the limit applies to every program on the computer. With the values above that is not a problem, which is why I do not recommend the maximum.

Will more RAM fix it?

No. The GDI limit is a count of objects, not an amount of memory. A computer with 64 GB of RAM still stops SOLIDWORKS at 10,000 GDI objects unless you raise the limit.

Should I set this on the PDM task host as well?

Yes. Task hosts run SOLIDWORKS for hours without anyone watching, so they reach the limit faster than workstations do.

Need help with this?

Blue Byte Systems supports SOLIDWORKS and SOLIDWORKS PDM environments every day. If SOLIDWORKS keeps crashing after the change, or the leak comes from an in-house macro or add-in, book a call and we will help you find it. For ongoing help, see our Enterprise Support Services.