Skip navigation
All Places > Administration > Blog > 2011 > March

Internet Explorer 9 was recently released by Microsoft. Due to an unfortunate timing coincidence (similar to that of the Windows 7 SP1 release date), we will not be able to officially qualify IE9 for use with SolidWorks 2011 SP03, which is due to be released soon.


If you are on SolidWorks 2011 SP03 or earlier, we recommend testing IE9 in your own environment (network, PDM, addins, graphics cards/drivers, anti-virus, etc.) before deploying it on production or mission critical systems.


Please note that Internet Explorer updates typically impact greater portions of SolidWorks functionality, relative to an OS service pack update. We'll post more information about known issues as they become available here.



1. IE versions prior to IE9 that are supported by Microsoft will continue to be supported for the lifecycle of SolidWorks 2011.

(Please refer to the Microsoft Support Lifecycle website for more information on IE lifecycles.)

2. SolidWorks 2010 will not be officially qualified for use with IE9. You may certainly install IE9 for use with SW2010 and report any issues found, but those issues will likely be fixed only in SW2011 SP04 or later.


Known issues as of March 15, 2011 :

1. Searching for files and folder from the SolidWorks Search bubble shows javascript error and does not return any results.

If you are frequently seeing a warning that says "SolidWorks has detected that your system resources are running low" or are seeing the sldworks.exe process using up a large number of GDI handles, please read on.


In SolidWorks 2011 SP03, we have addressed three workflows that were known to cause a run up in GDI handle usage and the warning message to appear (possibly followed by a crash in SolidWorks). The forum thread that kicked this off:


1. Working on SolidWorks Drawings that have GTOLs (specific to Windows 7):


This one came from Lindsay Dalziel from the above thread. We could not reproduce it in house and none of our automated test suites were reporting this failure. It was also reported that the problem did not occur on an older Windows XP 32-bit machine and got dramatically worse on a brand new Windows 7 x64 machine with a much higher configuration.


It seemed to happen when GTOLs were present in the drawing and that the problem happened more after actively working on such a drawing for a day.


The root cause turned out to be a behavioral change in Windows 7. WinXP recycles DeviceContext handles way more aggressively than Win7 does. So the same piece of code, which was being executed during mouseovers on GTOLs, was working as designed in WinXP, but not on Win7.


I apologize for the aggravation this bug has caused and I'm pleased to report that the issue is fixed in SW2011 SP03.


2. Browsing from the File->Open dialog to a folder with a "large" number of SolidWorks files (specific to Windows 7):


This one came from Charles Culp from the above thread. This is related to the functionality that shows the thumbnails for SolidWorks files in the Windows Shell,  i.e. Windows Explorer, File->Open and File->Save dialogs, etc. and was somewhat trickier than the first issue. The engineering problem here is the tradeoff between performance and cache size.


Extracting a thumbnail out of a SolidWorks file can be a potentially expensive operation depending on various things. For example, depending on what your shell settings are (view as list, thumbnails, large/med/small icon, etc.), the handler has to resize the image. Also, file access times affect performance.


Imagine browsing to a low-speed network share with a lot of SolidWorks files. The Windows Shell asks the thumbnail handler to extract and return the image in a specific size for EACH file in the folder. Both the shell and the SolidWorks handler has its own techniques of optimizing performance and caching, which sometimes conflict with each other.


We have reduced the effect of this issue by capping the amount of images cached by the shell handler. This should reduce the occurrence of the GDI handle depletion issues in such cases.


3. Opening and closing subassemblies / parts from the master assembly (NOT specific to Windows 7):


I alluded to this workflow in the above thread.


The most common workflow we're aware of that causes GDI handle usage to go up is: opening up part/sub-assembly document(s) from within an assembly by using the "Open Part" or "Open Assembly" command in the feature tree and then later closing the opened document. SolidWorks "holds on" to the GDI handles required for such documents until the master assembly is closed.


I also said :


The change required in the code to fix this is pretty fundamental to how parts, assemblies and drawings operate with each other in SolidWorks, so it's possible that the fix may cause problems in areas outside of just the core workflow in assemblies, e.g. API, 3rd-party addins, our own addins, hole wizard / dimensions / other GDI-heavy commands, etc.

We're taking a cautious approach to this fix, rather than just making the change and hoping for the best. We should have some news around this issue around the 2011 SP03 time frame - please watch this space.


The good news: we have a fix for this problem in SW2011 SP03. We have identified and thoroughly tested all the areas of our code that this change might affect. However, one area that this change leaves open is the SolidWorks APIs that does anything with document handling (open file, close file, etc.). Since we don't have all the number of macros and addins outside of what we ship, we're making this fix available only via a registry key in SP03.


In other words, this fix is "opt-in" for SP03. If you regularly use the "open part/sub-assembly from parent assembly" workflow and are seeing the resources low message, you should immediately see the benefits by turning on the fix as described in the KB article S-054140. If you use any addins, macros, etc. you will be helping us shake out any unknown problems by turning on the fix in SP03. This is optional, of course, but would help us greatly in identifying and getting those issues addressed in SP04.


In SP04 and onwards, we are planning to turn the fix on by default and leave a registry option to turn the fix off. In other words, this fix will be "opt-out" in SP04.


Finally, a plug for our Early Visiblity Program: You can read more details about the program and sign up here: By signing up, you will get early access to SP03 and be able to try out these changes related to GDI handles to try for yourself if they resolve your issue.