Our team is occasionally receiving pop-ups inside Epicor that says they have reached their resource limit and asks if they would like to increase it from 10,000 to 18,000. Can anyone explain in what file this limit is set so that we can increase it proactively. Currently, we have to log them out and then re-log in as an admin and open new windows until we receive this pop-up.
Thank you!
I believe this is referring to GDI Objects. It is a system-wide setting, adjusted in the Windows registry. Adjusting that setting will require local admin permissions on the PC.
Registry Path: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Windows \ USERProcessHandleQuota
For more information about GDI Objects / User Handles: User Objects - Win32 apps | Microsoft Learn
User Object Limit - one of my favorite presentation topics at Insights. I usually discussed this in the āClient Internals Part 2ā session but it appears the Client Internals sessions have been retiredā¦
The Epicor pop-up asking about increasing the limit is monitoring the use of āUser Objectsā - Andrewās registry key reference above is correct. While GDI Objects can be a problem (Big Red X where an Image or Complex control should display), it is really the User Objects that the Epicor Client is concerned about.
By default, Windows has a āper-processā limit of 10,000 User Object Handles with a total limit of 64K for all processes in an instance of Windows. The Registry setting can be modified to allow a maximum of 18,000 for a single process. Each UI Control in a Form is allocated at least one User Object Handle and since the Epicor UIs tend to have a large number of controls, it is pretty easy to approach the limit. I believe that a single instance of the Quote UI consumes over 2,000 User Object Handles. The Handles exist for the duration that a UI exists - even if it is not visible (memory cached for example).
The Epicor Client does not know in advance how many User Objects are needed to launch an individual UI so it cannot proactively prevent a client failure due to hitting the limit. In general, when the limit is reached the user will get an error message from Windows - usually something about not being able to āAllocate a Windows Handleā. In order to display that error message Windows needs to be able to allocate some User Object Handles and if not enough Handles were recovered after the initial limit was hit, the Epicor Client and all associated UIs will just vaporize.
There is no way to increase more than 18000?
Not that we are aware. This is a long standing Windows limit in a mature area of the system.
May I be the first to say that I REALLY enjoyed those presentations - got a LOT out of them.You and Brian do a great job of presenting boring techie info in an enjoyable manner!
We are seeing this now that weāve upgraded to 10.2.300.9 when we didnāt see it with 10.1.500.17. Our customer service folks open 2 each of the quote/order/customer entry screens normally. Now they are lucky to get all 3 open just one time before the UI errors and vaporizes. But itās not a GDI/Resource error like before, itās just a minimal āGPF-likeā error. Food for thought. Iām planning a regedit GDI increase later today to see if that fixes it.
Hey Mike - glad you found the sessions helpful and entertaining!
You should add some additional counters to the Windows Task Manager so you can see what resources are being consumed - Task Manager > Details Tab > Right Click on Grid Header and select āSelect Columnsā. You should add User Object to see how you are doing against the 18000 limit and GDI Objects if you suspect issues (usually big red X in grids) with that counter.
You might also try using Epicor64.exe instead of Epicor.exe - that will not help with the User or GDI Objects but can help if your issue is memory size related.
Rich - thanks, Iāll add those to my analysis this afternoon! Also need to check the leaks - Iāve got a few simple customizations and bpmās in the mix so I need to check those too.
Was just thinking I need to pull out the notes from last year/year before and āsee what Rich saidā 
Hi Mike,
Weāre seeing the same thing after upgrading from 10.2.200 to 10.2.500.
Iām getting inundated by requests from support asking why they cant have the same amount of windows open as before the update.
I have increased the registry key for all users to 18000 but they are still seeing regular UI crashes.
Did you ever manage to solve this issue, or have any reason why Epicor is behaving differently after the update?
nothing more than was discussed earlier in the thread. We didnāt have memory leaks, we just had folks who wanted 2 customer windows and 4 quote windows open at the same time and anything else they opened took them over the limit - even it was another app - so we had āthe talkā about how windows cannot be controlled but if the limit is what they use, then it must be for the best for everyoneā¦ etc. etcā¦
For the most part, my folks are happily working around it.
I have one user that just brought this issue to my attention. We have been on 10.2.300 for a couple of years, so it was a bit surprising that it is just coming up now.
We have the Epicor client running in Citrix sessions. Does that change the dynamic here at all?
Would we look to make this change on the Citrix server, or on the userās workstation?
I tried to look at User Objects and GDI Objects on the Citrix server for Epicor.exe, but they all display zero. When I open multiple Epicor screens on my own workstation, the object counts for wfica32.exe donāt go much over 100.
Theoretical question with regard to this limit. The Kinetic interface would eliminate this issue due to the nature of the UI - correct?
I donāt think itās theoretical at all 
And I think you are correct.
Iām not a web expert and have not explored this question yet - but Iāll take a stab.
Everything displayed inside a browser is some form of code, and so it has to have an effective limit - either in Windows controlled RAM used by the browser or within the browser itself (downloaded JS/Angular code, HTML5 code, etc.). But it wonāt be affected by the same limit of GDI objects that Windows has to handle as part of the UI.
Others here will know better and may even have some idea of the correct answer with regards to limitation inside the browser.