Skip navigation
All Places > Administration > Blog > Author: Vajrang Parvate


5 Posts authored by: Vajrang Parvate Employee

SolidWorks and Enterprise PDM 2013 SP0 have been tested and certified for use with Microsoft Windows 8 (64-bit only).


1. Only Windows 8 RTM (Release To Manufacturing) and later versions are supported.

Windows 8 "Release Preview" and "Consumer Preview" versions are not supported.


2. 32-bit is not a supported platform for Windows 8 for SolidWorks and Enterprise PDM except for :

eDrawings, Enterprise PDM Contributor and Enterprise PDM Web Client, which are supported on both 32-bit and 64-bit versions of Windows 8.


3. Use of SolidWorks and Enterprise PDM 2012 SP05 or earlier on Windows 8 is not supported.


Please see for more details.


Known issues:



- None -


Enterprise PDM

1. SPR 670068: Running Enterprise PDM Design Checker task fails with "Failed to Run Design Checker" error on Windows 8.

2. SPR 670692: Integrated search causes crash on Windows 8.



Q: Will SolidWorks run on Windows RT or ARM-based tablets ?

A: No. SolidWorks requires Intel or AMD processor(s) capable of running 64-bit Windows 8.


Q: Which versions of Windows 8 is SolidWorks 2013 supported on ?

A: SolidWorks 2013 is supported on the Professional and Enterprise editions of Windows. Use of SolidWorks on Basic / Home editions of Windows is not supported.

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.

Windows 7 SP1 was recently released by Microsoft. Due to an unfortunate timing coincidence, we will not be able to officially qualify Win7 SP1 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 Win7 SP1 in your own environment (network, PDM, addins, graphics cards/drivers, anti-virus, etc.) before deploying it on production or mission critical systems.


Early indicators on our internal Win7 SP1 tests are tracking healthy so far, and barring any major unforeseen issues, we expect to announce support for Win7 SP1 with SolidWorks 2011 SP04.



1. Win7 SP0 will continue to be supported for the lifecycle of SolidWorks 2011.

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

Most of you probably know that on Windows 32-bit, each process (exe) has access to only half (2GB) of the maximum possible of 4GB "addressable memory" and the other half is reserved by the OS kernel (more background on this here). So when memory intensive applications like SolidWorks start reaching the 2GB addressable limit, the obvious reaction is why does the OS need as much as half the address space. Greedy Windows, you think.


You start Googling around or someone recommends using this magic switch Windows has that lets you increase the available address space to 3GB. That's better - take that, Windows. Now you can open and create larger assemblies and drawings than you could before. Fast forward to a few months later - you're starting to see the pinch in performance with your increasingly larger designs. You already have 4GB physical RAM on your 32-bit OS, so the only possible quick avenue of a performance boost (short of a full system upgrade) is to upgrade your graphics card.


So you spend time researching, spend money on the best graphics card for your money, install the latest and greatest certified drivers. Since you're in a bit of downtime, you might also install the latest system upgrades and SolidWork service pack. You can't wait to get back on your project.


Except - disaster. SolidWorks is now crashing randomly. How can that be ? You have the best card - everybody on the forum and your VAR said so, you have the latest certified drivers, the latest system updates, the latest SW service pack... Ah - that must be it. The latest service pack must be the fault. So you go back to your old service pack. But the crashes continue. Stupid software - hosed my machine again, you say. Your project is now way behind schedule and you have a bitter taste in your mouth.


What exactly happened here ?


Think back to when you turned on the /3GB switch. It's not usually very well understood, even among software developers (because most software developers operate in the "user address space", not the "kernel driver space"), what the reserved kernel address range is for. It is required for mapping all the devices, drivers and device memory you have on your system. This is colloquially known as the PCI memory hole.


On a test machine which has a mid-range workstation graphics card with 512 MB video RAM, the memory holes the PCI / AGP buses and the video card resources take up a total of 1334MB.


Now think back to that super duper video card you bought with 1 GB of VRAM - after that upgrade, Windows probably ran out of kernel addresses to map the device resources to. So smaller assemblies/drawings work fine, but when you start going up in usage of graphics card memory, it can lead to unpredictable behavior, i.e. random crashes.


So why did Microsoft introduce this /3GB switch in the first place ?


It was originally introduced for server-based processes such as SQL server or Exchange server and the like, before 64-bit became the common platform it is today. The key point here is that these server-based processes are CPU/RAM-intensive, but not device-intensive and especially not graphics card-intensive. So the server hardware doesn't have the devices that need the kernel-reserved addresses. In this case, it is indeed "greedy Windows" and the /3GB switch works well here. Of course, today no respectable IT admin would run a 32-bit server anyway, so this is no longer an issue. In fact, even at a consumer level you'd have to go to a lot of trouble to buy a new machine with 32-bit Windows. At a SolidWorks-user level, more users use 64-bit than 32-bit today.


So do yourself a favor - push the right buttons to upgrade to 64-bit. But if you can't upgrade right away for whatever reason, at least don't use the /3GB switch as a stop-gap.