5

Нужные страницы

Translate

Search

Friday, October 6, 2017

Crashing Solidworks and the threshold of system resources

I think everyone who modeled in Solidworks came across an unexpected program closure. Bouncing solid quite often, but as a rule, when complex models are opened and closed intensively or when they are saved, which is especially unpleasant.
Do not all fall for the curvature of developers, they are trying to create a quality product. The reason for the unexpected collapse of Solidworks is the limitation of Windows that the process can only access 10,000 GDI objects.

What is GDI?

GDI objects are used to draw window elements that are not in the graphics area in SolidWorks. For maximum performance, the graphics area uses OpenGL, which gives more direct access to the equipment for video processing. GDI objects are used for the chrome graphic area, so every time a new document is opened, the number of GDI objects used by SOLIDWORKS will increase. Prior to this, SOLIDWORKS 2011 SP4, if the part was opened in the assembly and its own window, when this window was closed, it would not free these GDI objects. The default behavior is now to release these descriptors, but not all of them are released.

Why is this all due to the failure of SOLIDWORKS? Windows has a default limitation that one process can access only 10,000 GDI objects. Because SolidWorks does not release all objects when the document is closed, the number it uses increases continuously with each new document and gradually approaches the limit set in Windows.




Is it possible to use this knowledge to predict when SOLIDWORKS will knock out? 


Predicting a SOLIDWORKS crashing

As it was written above, this is not technically a failure, if SOLIDWORKS reaches the limit of 10,000 by object, Windows completes the process. This is not caused by a code error or by problems with shared memory access or anything else that causes a crash. It's just that Windows believes that SOLIDWORKS consumes too much resources and closes it to get those resources back. But since there is a certain number at which it closes, you can predict when it will happen. In fact, it's easy to control. Just follow these steps:


  • Open task manager (you can right click on the task bar and click task manager). 
  • Click View, Select Columns…
Select Columns in Windows Task Manager


Check off GDI and User Objects and click OK

Display GDI Objects
Now, the task manager will display the current value of the GDI and USER objects for each process



Display GDI Objects
Display GDI ObjectsIf a part is opened and closed several times the number of GDI objects it uses does not increase. SOLIDWORKS releases all handles every time.  The same applies to assemblies as well.  The problem is only encountered when a part is open in an assembly and it is opened in its own window and then closed.  
How to troubleshoot this crash problems

How can this problem be avoided? Do not keep your assemblies open unless you need them to be, and monitor your task manager periodically to see how many objects you are using.  Closing SOLIDWORKS and opening it will reset this count.  Furthermore you can increase the maximum number of GDI Objects a process can use by following these settings:
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota 

  • Sets the number of GDI objects, the range of values is 256 ~ 65536, the default is 10,000.


  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota 

  • Sets the number of descriptors, the range of values is 200 ~ 18000, the default is 10 000.
Increase the values and reduce the risk of Solidworks failure. When changing the parameters, switch to the decimal system of the calculus.

P.S.
When writing an article for testing, the parameters were reduced to 1500, after the Solidworks Resource Monitor warning, after some time the Solidworks was crashed. 

The same manipulations apply only to the GDI problem, if SolidWorks Resource Monitor writes that there is not enough memory, then the problem will be to add RAM or unload other programs.



By the materials of the blog javelin-tech

No comments:

Post a Comment