| Rev # | Date | Description |
|---|---|---|
| 1.0 | Oct 2012 | Original Document Created |
| 2.0 | Nov 2014 | Added “Slow Save…” example |
| 3.0 | Dec 2016 |
|
| 3.1 | March 2019 |
|
| 4.0 | May 2023 |
|
Note
All SolidPractices are written as guidelines. You are recommended to use these documents only after properly evaluating your requirements. Distribution of this document is limited to Dassault Systèmes SolidWorks employees and VARs. This document may not be posted on blogs or any internal or external forums without prior written authorization from Dassault Systèmes SolidWorks Corporation. This document was updated using version SOLIDWORKS 2023 SP2.1 and 3DEXPERIENCE R2023x FD02.
Preface
This SolidPractice document provides information about the Windows® Process Explorer system utility. Process Explorer is a tool that you can use to solve problems during remote engagements. The tool is especially helpful when communicating with customers via remote communication applications such as GoToMeeting®. This document uses actual SOLIDWORKS® Technical Support illustrations to demonstrate the wide range of uses for this tool. The SOLIDWORKS Technical Support team hopes that this information inspires you to find additional creative uses to help solve difficult and complex customer cases.
Your Feedback Requested
We would like to hear your feedback and also suggestions for new topics. After reviewing this document, please take a few minutes to fill out a brief survey. Your feedback will help us create the content that directly addresses your challenges.
Background
The Process Explorer system utility is a valuable troubleshooting tool to help solve difficult technical issues for the SOLIDWORKS customer base that runs the Windows operating system (OS). The size, accessibility, and amount of system information available within the tool make it a great asset for live debugging. This tool can also provide that extra bit of information that conventional troubleshooting steps fail to produce while troubleshooting undesirable SOLIDWORKS behavior in a Windows environment.
Downloading and InstallingDownloading
Run or save the file directly from http://live.sysinternals.com/procexp.exe.
Download the file to a local hard drive from https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer.
Installing
No installation is necessary. Simply run the ‘procexp.exe’ file.
Notes:
It is not necessary to run the tool with administrative permissions. However, some functionality is limited.
For full functionality, it may be necessary to set ‘Run as Administrator’ permissions with the default User Account Control (UAC) settings.
Client computer support: Windows 8.1® and later OS.
Server support: Windows Server® 2012 and later OS.
Type of Information
Think of Process Explorer as a more advanced Windows Task Manager. There is a lot of information that is relevant to common SOLIDWORKS troubleshooting scenarios that involve file management, system resources, anti-virus, and security. Here is a list of the type of information available within this utility.
System Resources
Virtual Address Space
Total Physical RAM
Available Physical RAM
Graphics Device Interface (GDI) Objects
User Objects
GPU Memory used
List of dynamic-link libraries (DLL’s) that load under the ‘SLDWORKS.exe’ process
Version of DLL’s that load
Path of DLL’s that load
Handles that load
List of child processes that run under the‘SLDWORKS.exe’process
Path of processes that run
Powerful search capability to quickly locate files and DLL's in use
System Resources
When investigating issues live on a computer, use the Process Explorer utility to validate low resource situations. This is a great resource to review system level and application resource usage in one place. The critical resources for optimal performance and stability with SOLIDWORKS are memory and desktop objects. This includes GDI and User objects.
The top pane displays all of the running applications. It includes customizable columns that allow you to track many different system resources. The following example depicts many items that relate to Process Memory.
The status bar is also very useful. It provides information that relates to the overall health of the system.
If you know that the previous image is from a Windows 10 64-bit OS, you can quickly determine that this system is in a healthy state. Any abnormal behavior is most likely not due to a lack of resources.
Thirty one percent of the physical RAM is in use.
The OS committed 46.40% of available virtual memory.
The GDI Objects and USER Objects counts are well below the 10,000 limit.
The Virtual Size is not an issue on a 64-bit system because the limit is 1,073,741,824 kilobytes (KB) or eight terabytes (TB) per process.
Here is another example from the same system. In this example, the performance of the SOLIDWORKS application or any other Windows application is a concern because Commit Charge is near 100%.
To customize the display of columns, right-click on any of the column headers and then click on Select Columns. The Select Columns dialog box appears and provides a tabbed list of system metrics available by area.
To view a comprehensive list of system resources used by theSLDWORKS.exeprocess:
In the process tree, right-click on SLDWORKS.exe > click on Properties > and then click on the Performance tab.
To view a summary of resources in use by the system, go to View > System Information.
Note:
If you want to see the Kernel Memory limits, install the WinDbg debugging utility. Then, configure the Microsoft® symbols path, and browse to the location of the dbghelp.dll file within the Windbg installation. It is rare to need information about the Kernel Memory limits.
To view the Kernel Memory limits as well as other properties for each process such as Disk and Network, you must run Process Explorer locally as administrator under the default User Account Control (UAC) settings.
Graphics processing unit (GPU) memory
Beginning with Process Explorer version 15, you can view the amount of GPU memory in use at the process level and system level.
This metric is very useful to help understand if users running the SOLIDWORKS application are maxing out on the amount of dedicated Video Card Memory on their systems. To view the GPU memory usage:
Go to View > System Information, and then click the GPU tab.
In the previous image depicts an 8 GB graphics card that is consuming 2.8 GB of dedicated Video Random Access Memory (VRAM). Adding and sorting the GPU counters in the Process Explorer top pane displays the processes that contribute to the dedicated VRAM.
In the following image, the SOLIDWORKS application is using approximately 1 GB of video VRAM.
A breakdown of the GPU memory is available on the GPU Graph tab for the process properties as shown in the next image.
Exercise
Try the following steps in the SOLIDWORKS application and monitor the GPU counters to observe the impact on the graphics resources.
Open multiple windows.
Turn on RealView.
Increase the image resolution.
Use transparency (editing parts in the assembly context).
Lower Pane: DLL’s and Handles
The lower pane is useful for viewing the DLL files that load within the SOLIDWORKS process. This is very powerful and helps to isolate suspicious third-party add-ins or applications that load into the SOLIDWORKS address space. It is also possible to determine the versions of SOLIDWORKS DLL’s and locate files that the SOLIDWORKS application uses in the background.
To display the lower pane, either press Ctrl-L or go to View > Lower Pane View.
DLL view
To display the DLL view, either press Ctrl-D or go toView>Lower Pane View>DLLs.
In the previous image, notice that the Version and Company Name for DLL’s loaded into sldworks.exe process. The image path shows that these DLLs are from SOLIDWORKS 2023 Service Pack 2.1. You may show other columns such as Path to discover installation locations for SOLIDWORKS or other third party applications.
Exercise
To determine if there are any unusual third-party DLL’s loaded within the SOLIDWORKS process:
Enable the lower pane view.
Add the Path column from the DLL tab.
Look for DLL’s with paths that point to non-Windows or non-SOLIDWORKS locations.
Another technique is to sort the Company Name column and look for unfamiliar names and paths.
How to identify suspicious third-party DLL’s
In the Process column, select the SLDWORKS.exe process.
DLL’s that load within the SLDWORKS.exe process appear in the lower pane.
Right-click on a column in the lower pane and then click on Select Columns.
Select the check boxes for the Path and Company Name columns.
Sort by Path and visually scan for locations other than:
[SOLIDWORKS Installation Path]
C:\Windows\
Temporary locations
Note: You can sort by Company Name to isolate suspicious DLL’s.
Handles view
The Handles view displays files in use by the SOLIDWORKS process. Some of the items that the Handles view display include are:
Location of the SolidWorksPerformance.log file
Location of the swxJRNL.swj file
Location of open SOLIDWORKS files
Location of temporary files (such as files used for virtual components, equations, Visual Basic for Applications (VBA), etc.)
To display the Handles view, either press Ctrl-H or go to View > Lower Pane View > Handles.
Exercise
On a computer running the SOLIDWORKS application, use the Handles view to locate the SolidWorksPerformance.log, swxJRNL.swj, and FileAccess.log files.
List of Child Processes
The Process Explorer utility can display a list of parent-child relationships for running processes. For example, in the following image, notice that the sldProcMon.exe process appears directly beneath the SLDWORKS.exe process. This indicates that sldProcMon.exe is a child process of the SLDWORKS.exe process. The SLDWORKS.exe process launches sldProcMon.exe.
Example:Curious what process is responsible for the generating high quality drawing views in the background?
The sldbgproc.exe process runs as a child process and is responsible for the background calculation of high quality drawing views in the SOLIDWORKS drawings environment.
Path of Running Processes
Pointing to the name of each process within the Process column displays a tool tip of the path for the process. To view details about a process, right-click on the process and then click on Properties. The Image tab displays the path of the process, the command that launches the process, and the current directory of the process.
Information on the Image tab is useful when investigating behavior that involves SOLIDWORKS child processes or helper processes. Use this information to help validate the path of the processes, command line parameters, and parent processes used during launch.
The previous image shows the Image tab for ENOPLMCSAClient.exe. ENOPLMCSAClient.exe also known as the, PLM Collaborative Services Adapter (PLMCSA), client is a helper process that connects SOLIDWORKS to the 3DEXPERIENCE Platform for the Design with SOLIDWORKS and SOLIDWORKS Connected 3DEXPERIENCE Applications. You may see details such as:
Installation location using Path
Name of parent process that launched the process using Parent
Command line passed to the process during launch using Command Line
Note: The Image tab also displays whether the process is running as a 64-bit or a 32-bit application.
Exercise
Run SOLIDWORKS RX 2023 > select Click here to launch SOLIDWORKS while bypassing Tools/Options settings and discover the command line used during launch using Process Explorer.
Process Explorer Search
This powerful feature searches for any file or DLL that is open in memory, as well as the process or service that owns that file or process.
Exercise
Have you ever wondered where a virtual component is stored? Let us find out.
Create a new assembly.
Insert a new part with the name Part1^Assem1.
In Process Explorer, go to ‘Find’ > Find Handle or DLL (Ctrl-F).
Type Part1^Assem1 and click Search.
The search returns one matching item. You can see that the file actually loads in a temporary file location. Clicking on the item in Process Explorer highlights the process and location of the file handle in the lower pane.
This is a great troubleshooting feature, and can help you learn about what goes on under the hood in the SOLIDWORKS application.
SOLIDWORKS Technical Support Examples:Error: "A journal file could not be created. Auto recover will not work. Another session of SOLIDWORKS may already be running on this machine."
Problem: This error occurred when starting a SOLIDWORKS session, even when no other instances of SOLIDWORKS were running.
Troubleshooting Details:
Occurred randomly on Windows 7 x64
Occurred on multiple client computers
Started occurring after upgrading from Windows XP 32-bit to Windows 7-64 bit
Verified that another SOLIDWORKS process was not running at the time of the error
Using Process Explorer to find the root cause
Historically, the SOLIDWORKS software cannot create another swxJRNL.swj file when that file is in use by another SOLIDWORKS process. Initially, it was thought that perhaps another process or service unrelated to SOLIDWORKS was using this file, and not releasing it after closing the SOLIDWORKS application.
The Technical Support Engineer (TSE) used Process Explorer to test this theory.
First, the TSE went to Find > Find Handle or DLL and conducted a search for swxJRNL.
The search results revealed that the Hpmup091.bin file was holding on to the swxJRNL.swj file. Clicking on the process name highlighted the process in the process tree list. From here, the TSE was able to analyze the properties of hpmup091.bin. Refer to the next image.
Based on the file path of C:\windows\system32\spool\Drivers\X64\3\, the Hpmup091.bin file appeared to be a printer driver.
This information led to additional logical tests to confirm the behavior, and provided a complete solution.
The additional testing showed that the HP® Universal Printing PCL 5 driver would appear as a child process under the SLDWORKS.exe process. The HP process would remain resident in memory after printing any document in the SOLIDWORKS application. When exiting SOLIDWORKS, the driver would remain in memory with a handle to the journal file. This meant that upon starting the SOLIDWORKS application again, the software could not create a new journal file because the HP driver had ownership of the file.
After ending the hpmup091.bin process, it was possible to run the SOLIDWORKS application without any issues.
The long-term solution was to upgrade the printer drivers. This investigation led to publication of Knowledge Base solution QA00000111243.
SOLIDWORKS crashes during any operation where Excel launches (bend tables, design tables, etc.)
Problem: The observation was that the SOLIDWORKS application crashed every time the Excel application started within the SOLIDWORKS software. For example, every attempt to insert a bend table or design table resulted in a SOLIDWORKS crash.
Troubleshooting Details:
The following actions did not resolve the issue:
Repair the Microsoft Office® installation
Repair the SOLIDWORKS installation
Reset the SOLIDWORKS settings by renaming the following registry entry: HKEY_CURRENT_USER\Software\SOLIDWORKS
An attempt to replicate the issue using the customer’s settings was unsuccessful.
Using Process Explorer to find the root cause
The SOLIDWORKS TSE used the GoToMeeting application to conduct a live investigation of the customer’s computer. Once connected, the TSE ran the Process Explorer utility to see if there were any third-party DLL’s interfering with the SLDWORKS.exe process.
Tip:For issues like this that are specific and repeatable only in a customer’s environment, the following exercise is useful:
Open the Process Explorer application on the client computer with the issue.
If the lower pane is not in view, go to View > click on Lower Pane View.
Go to View > Lower Pane View > DLLs.
In the Process list, click on SLDWORKS.exe.
The lower pane displays the DLL’s that load within the SLDWORKS.exe process.
Right-click on a column in the lower pane and then click on Select Columns
Activate the check boxes for the Path and Company Name columns.
Sort by Path and visually scan for locations other than:
[SOLIDWORKS installation path]\
C:\Windows\
Temporary locations
Note: You can sort by Company Name to isolate suspicious DLL’s.
In the previous image, a sort by Company Name displays a collection of DigitalPersona® DLL’s within the SLDWORKS.exe process. Because this issue was only repeatable in the user’s environment, the next step was an attempt to keep these third-party DLL’s from loading into the SOLIDWORKS software. A quick investigation using Google™ search and a review of the location of these DLL’s established that the following executable files were responsible for the behavior.
Closing the SOLIDWORKS application stopped these processes. After restarting the SOLIDWORKS software, the next attempt to insert a design table again resulted in a crash. A look at Process Explorer showed that these DLL’s were still active. Further investigation revealed that the Biometric Authentication Service was responsible for the executable files.
The SOLIDWORKS TSE disabled the service and restarted the workstation, after which those executable files were no longer running.
The next attempt to run the SOLIDWORKS application and insert a design table succeeded!
Another possible technique would have been to use the Microsoft System Configuration (MSCONFIG) utility to disable all non-Microsoft services and then restart the computer. However, while this would resolve the issue, it would not reveal the root cause of the problem.
Slow save in the SOLIDWORKS Conceptual Designer 3DEXPERIENCE application.
Problem: An assembly consistently took between 93 and 110 seconds to save in the SOLIDWORKS Conceptual Designer tool.
Troubleshooting Details:
Determined the size of the assembly structure
The size of the assembly file was 35 MB
The size of the assembly file with referenced components was 51 MB
The 15 child components consumed only 15 MB
Using Process Explorer to find the root cause
To determine how many components were modified and saved during a save operation, the SOLIDWORKS TSE rebuilt the assembly and performed a save.
The TSE then:
Opened the Process Explorer utility.
Accessed the application properties, by right-clicking on the 3DEXPERIENCE.exe process > Properties> Disk and Network.
Performed a save.
The Send Bytes property indicated a transfer of 39.5 MB of data to the server. After saving again, the result was the same.
The amount of data for this file seemed excessive considering that there were only 15 components and mates in the FeatureManager® Design tree.
At this point, the TSE:
Removed all components from the tree and then saved the assembly. There was no change to the Send Bytes property. There was 39.5 MB of data transfer.
Deleted the motion study within the assembly and the file. Again, there was no change. There was 39.5 MB of data transfer to the server.
Looked for hidden objects within the assembly. Bingo!
This complex geometry looks like it could consume 30+ MB of space!
This was the ”swept volume” body that the motion study includes. Manually deleting this from the graphics area and then saving the file again reduced the file size to 69 KB.
Without using the Process Explorer utility, it would have been very difficult to determine the root cause for this scenario.
Slow open using the Design with SOLIDWORKS 3DEXPERIENCE Application (3DEXPERIENCE Add-in)
Problem: An assembly document with one referenced part document took an unusually long time to open in SOLIDWORKS with nothing in the local work folder.
Troubleshooting Details:
Confirmed the structure of the SOLIDWORKS assembly using the Checkout_Response.xml file and 3dexperience-log.json
Confirmed the download is the bottleneck using the timestamps associated with the download command for the Checkout_Request.xml and Checkout_Response.xml.
Use Process Explorer to determine amount of data transfer during download
The TSE then:
Opened the Process Explorer utility.
Accessed the application properties, by right-clicking on the ENOPLMCSAClient.exe process > Properties> Disk and Network.
Reproduced the scenario and reviewed the Receive Bytes after the open process completed.
Confirmed the single SOLIDWORKS part document was approximately 59 MB by reviewing the size of the file within the local work folder. This confirmed why the open procedure was unusually long for the simple assembly product structure.
We hope that you find this document informational and useful and request that you leave a brief feedback about the topics that you want us to cover in the next revision of this document. Click here for a complete list of SolidPractices documents available from DS SOLIDWORKS Corp.
