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 SP03 and 3DEXPERIENCE R2023x FD03.

Preface

This document introduces the Process Monitor tool, which can help you troubleshoot difficult environmental issues within the Windows® operating systems that affect the SOLIDWORKS products. This tool is useful for investigating an issue in real time or as part of a post-mortem analysis.

The purpose of this document is to demonstrate the wide range of uses for this tool through actual SOLIDWORKS Technical Support examples. We hope that this document will inspire you to find additional creative uses to help solve seemingly difficult and complex customer issues when the usual troubleshooting procedures are unsuccessful.

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

For many years, the SOLIDWORKS Technical Support team has used the Process Monitor tool to troubleshoot difficult system and environmental issues that affect the usage of SOLIDWORKS.

Process Monitor is a Windows Sysinternals tool. The Sysinternals website includes an online repository of applications that help you to troubleshoot Windows-based applications. Process Monitor is a free system utility that logs real time file system, registry, network, and process/thread activity for all processes within a Windows environment. Prior to the introduction of Process Monitor, separate utilities like Registry Monitor and File Monitor provided the functionality for capturing this activity.

One of the key benefits of Process Monitor is the non-destructive filtering capability that File Monitor and Registry Monitor lacked. This data filtering method makes Process Monitor a very handy tool for identifying the root cause of system issues that contribute to undesirable behavior within the SOLIDWORKS products.

Use Cases

Process Monitor has the capability to provide a behind the scenes look at system activity. For example, it is possible to review file activity, Windows Registry activity, and network operations from SOLIDWORKS.

Here is a short list of the types of SOLIDWORKS-related investigations in which Process Monitor is especially useful:

• Permission issues

• System-specific performance issues

• File or registry access behavior

1. Setup

2. Download

The Process Monitor tool is available on the Sysinternals website at:

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

• To run or save the program file directly, click http://live.sysinternals.com/procmon.exe

• To download the application files, click http://download.sysinternals.com/files/ProcessMonitor.zip

Run

Process Monitor does not require installation. Just run the procmon.exe file.

When running Process Monitor, consider the following:

1. Supported operating systems

• Process Monitor runs on Windows 8.1 or Windows Server 2012 and later operating systems.

1. Run as Administrator

   Right-clickthe .exethen clickRun as Administratorfrom the shortcut menu.

2. Keyboard and mouse control in remote session tools

• It is not possible to remotely control Process Monitor when using remote session tools such as GoToMeeting™ or Zoom with User Account Control (UAC) enabled.

  1. Solutions:

     • Send the user instructions about how to capture the Process Monitor log (QA00000110123).

Investigating Permission Issues

Process Monitor is an excellent tool for validating permission issues.

How do I know whether an issue is due to insufficient permissions?

It is not an exact science to know for sure whether an issue is due to insufficient permissions. Here are some examples of situations where Process Monitor is useful for troubleshooting a possible permission issue.

• Error messages in the application indicate a permission issue.

  1. “Error 1406. Could not write value SOLIDWORKS Office Installed to key….”

  2. "SOLIDWORKS FloXpress failed to save data into [file location]. Make sure the folder is not write-protected"

• The issue is not reproducible with the local administrator account.

• There is strange behavior that is not reproducible in any other environment.

  1. False error messages

  2. Crashing or hanging

How do I use Process Monitor to troubleshoot a permission issue?

in the Result column.

You must first define the context of the issue to successfully capture and interpret a Process Monitor log.

1. Example: Using the result column to verify insufficient permission

in the File > Properties > Custom dialog box. To investigate, you capture a Process Monitor log while the user attempts to edit the custom property listing.

In many cases, the resulting Process Monitor log will include thousands of events even for one process. Use the Process Monitor filter to hide all of the irrelevant events in the log and focus on the events that result in ACCESS DENIED.

The filtered log below shows ACCESS DENIED results while the user attempts to access the properties.txt file. Based on this log, you determine that adding write permission for the user to the file C:\ProgramData\SOLIDWORKS\SOLDIWORKS 2023\lang\english\properties.txt will probably resolve the issue.

1. Technical Support Case Study: Permissions

2. Problem:

The following error appears every time the user starts a SOLIDWORKS session:

“Error 1406. Could not write value SOLIDWORKS Office Installed to key \SOFTWARE\SOLIDWORKS\SOLIDWORKS 2012\Setup. Verify that you have sufficient access to that key, or contact your support personnel.”

1. Troubleshooting details:

• The user has local administrative rights.

• The same problem occurs with another account.

• The same problem occurs after repairing the SOLIDWORKS installation.

• The same problem occurs after reinstalling SOLIDWORKS.

• UAC is disabled.

• You verified that the user has write permission to the following registry keys:

  • HKEY_LOCAL_MACHINE\Software\SOLIDWORKS 2012\setup

  • HKEY_CURRENT_USER\Software\SOLIDWORKS 2012\setup

1. Using Process Monitor to find the root cause:

1. Share the Knowledge Base solution QA00000110123 with the customer to deliver instructions about capturing a Process Monitor log and sending it to you.

2. file from the customer in Process Monitor.

• In the red rectangle, notice how many events were included in a 1-minute capture!

1. Filter for events that have a result of ACCESS DENIED.

• .

  1. Do we know the context of the error?

     • Yes, the error message comes from Windows Installer (msiexec.exe).

1. Continue filtering to show only events that have a result of ACCESS DENIED and a process name of msiexec.exe. Then scroll to the bottom of the Process Monitor log.

You can filter on the fly without opening the Filter menu by right-clicking on an item within the log and choosing to include or exclude the item.

1. There are many events with a result of ACCESS DENIED. We shall ignore the file events and focus on the registry events. According to the “1406” error message, the issue relates to SOLIDWORKS registry keys. Based on this, focus on the registry keys within the red rectangle as possible culprits.

2. Recommend that the user check the permissions on these registry keys.

1. Resolution

• The user did not have write permission to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SOLIDWORKS\Licenses\

• Adding write permission for the user to the Licenses key and subkeys solved the issue.

• The misleading error message was reported to the SOLIDWORKS R&D team.

Investigating Performance Issues

There are times when network activity or excessive file activity causes delays in SOLIDWORKS. This type of problem is often specific to a customer’s environment. You can use Process Monitor to help identify the performance bottleneck from a system perspective. This technique is useful only for system-related slowdowns that are not reproducible in another environment.

Examples:

• SOLIDWORKS is slow to start.

• The File > Open dialog box is slow to open.

How do I use Performance Monitor to find a performance bottleneck?

1. Establish and document the sequence of events that results in slow performance for the customer. Record the amount of time that it takes to complete the operation in the customer’s environment.

2. Capture a Process Monitor log while the user performs the exact sequence of events. Stop the capture immediately after the last step. If you do not have access to capture the Process Monitor log in the customer’s environment, share the Knowledge Base solution QA00000110123 with the customer to deliver instructions about capturing Process Monitor log and sending it to you.

3. Open the log in Process Monitor and add a column called Relative Time. Right-click the existing columns in Process Monitor > click Select Columns > click in the box next to Relative Time > click OK. This column shows the time that elapsed relative to the start of the capture. This information helps you keep track of the sequence of events in your investigation.

1. Make sure that the following buttons are active: Show Registry Activity, Show File Activity, Show Network Activity and Show Process/Thread Activity.

2. Filter to show only events that relate to the process, such as sldworks.exe, where the performance issue occurred. Scroll down the log and look for gaps in the relative time between events.

• If the Process Monitor log is very large, save the log to the .csv file format. Open the .csv file in Excel and use the filtering tools within Excel to help find the gaps that lead to the bottleneck. This process is especially useful when tracking down performance issues that relate to network communication attempts to a server.

• > click File Summary… or Registry Summary… to see the number of times that specific files, folders, file types, or registry paths are accessed in a capture. Compare the summary to a baseline capture from a “good” system to see if anything stands out.

• If the above techniques do not yield any obvious clues, try the following:

1. Click Tools > click Count Occurrences.

2. Change the Column filter to Result.

3. Click the Count button.

4. Look for the value BAD NETWORK PATH.

The BAD NETWORK PATH value means that the network path cannot be located. Sometimes you may see a delay due to a timeout while waiting for a network computer to respond.

1. Example: Comparing registry summaries to find a performance bottleneck

Compare the registry summary for two Process Monitor logs:

• 

• 

Did you notice the difference?

When starting SOLIDWORKS 2008, there were over 18,000 access events for the registry path: HKEY_CURRENT_USER\Software\SOLIDWORKS\SOLIDWORKS 2008\User Interface\General-Bar1

• SOLIDWORKS Technical Support reported this issue to the R&D team.

1. Example: Using ‘Count Occurrences’ to find a performance bottleneck

Problem:

> Properties > Custom dialog box takes 8 seconds for any document.

Root cause analysis:

The custom property listing in the File > Properties > Custom dialog box referenced a network path that was no longer accessible. The customer specified this path in the Tools > Options > File Locations dialog box. Another effect of this problem was that opening the Tools > Options > File Locations dialog box also resulted in the same delay.

1. Technical Support Case Study: Performance

2. Problem:

The File > Open operation in SOLIDWORKS consistently takes 10-14 seconds for the customer.

1. Troubleshooting details:

• The same problem occurs after resetting the SOLIDWORKS user settings.

• The same problem occurs after repairing the SOLIDWORKS installation.

• The problem also occurs for other users at the customer’s site.

• The problem goes away after unplugging the Ethernet cable.

1. Using Process Monitor to find the root cause:

1. Share the Knowledge Base solution QA00000110123 with the customer to deliver instructions about capturing a Process Monitor log and sending it to you.

2. Open the .pml file from the customer in Process Monitor.

3. Add the Relative Time column.

4. Filter for events that relate to the sldworks.exe process. We know that the user performed the File > Open operation within sldworks.exe.

5. value is approximately 19 seconds, which seems reasonable.

• Confirm that the customer captured only the File > Open workflow.

1. Scroll to look for a relatively large time gap in the Relative Time column.

2. Discover a 10-second gap.

• During this time, there were some attempts to connect to a server through port number 25734.

• 

1. Ask the customer about the use of that server.

1. Resolution:

1. The customer previously used that server for SNL. Although the server was no longer in use, it was still in the server list on the SNL client computers.

2. Removing the obsolete server from the server list eliminated the delay when performing the File > Open operation.

3. The SOLIDWORKS Technical Support team documents this behavior in the Knowledge Base solution QA00000111704.

Exploring File or Registry Access Behavior

There are times when Process Monitor is useful for determining where and how SOLIDWORKS finds a particular file or registry value. In particular, Process Monitor can help you understand how a specific operation or workflow will potentially affect a customer.

How do I use Performance Monitor to find key files?

Use

File Summary

and

Registry Summary

to identify files or registry values that SOLIDWORKS accesses.

Example: Using File Summary and Registry Summary to find key files

In this example, a customer reports an issue with generating costing reports from SOLIDWORKS. Other attempts to resolve the issue were unsuccessful.

To understand what happens when you generate a costing report, you capture a Process Monitor log while you perform this workflow.

Use

File Summary

and

Registry Summary

to find some key items that might be worth investigating.

and CostingReport_Machine.dot are key files that SOLIDWORKS accesses during the costing report generation. A quick search in the SOLIDWORKS Knowledge Base for “report word error” returns the solution QA00000119106, which could be relevant to this investigation.

1. Technical Support Case Study: Search Routine

2. Problem:

It takes longer to open subassemblies from assemblies in SOLIDWORKS 2012 SP2 compared to SOLIDWORKS 2011 SP4.

1. Troubleshooting details:

• The System Administrator received reports of this issue from multiple users.

• The System Administrator wondered whether the search routine had changed.

• You were unable to reproduce the issue using the customer’s files, folder structure, and SOLIDWORKS version.

1. Using Process Monitor to find the root cause:

The customer captured two Process Monitor logs while opening the same subassembly from the top-level assembly. One log is for SOLIDWORKS 2011 SP4, and the other log is for SOLIDWORKS 2012 SP2. In each case, the user opened the assembly in lightweight mode and then captured the Process Monitor log while opening the subassembly.

1. Compare the two logs.

   1. 

• Notice that there are only 151 events. The total relative time is less than 1 second.

  1. 

• Notice that there are 1,309 events. The total relative time is 1.39 seconds.

1. Compare the Path column in both logs. Discover that SOLIDWORKS 2012 went through the file search routine for every nested subassembly, while SOLIDWORKS 2011 did not.

2. Theorize that a difference in SOLIDWORKS settings between SOLIDWORKS 2011 and SOLIDWORKS 2012 caused the different behavior when opening or resolving components.

1. Resolution:

1. Some users had enabled the Automatically load components lightweight system option in SOLIDWORKS 2011, and disabled this option in SOLIDWORKS 2012. This was not obvious until comparing the Process Monitor logs because in both versions, Large Assembly Mode would have caused the top-level assembly to open in lightweight mode anyway.

2. Enabling the Automatically load components lightweight option in SOLIDWORKS 2012 made the open subassembly behavior similar to SOLIDWORKS 2011.

1. Technical Support Case Study: Registry Value

2. Problem:

SOLIDWORKS Rx crashes on startup with an error “sldRx has stopped working”.

1. Troubleshooting details:

• The same problem occurs after repairing the SOLIDWORKS installation.

• The same problem occurs after uninstalling and reinstalling SOLIDWORKS.

• The same problem occurs after uninstalling and reinstalling the Symantec™ anti-virus program.

• Collecting and analyzing a dump file from the WinDbg debugging tool did not yield useful information.

1. Using Process Monitor to find the root cause:

1. Share the Knowledge Base solution QA00000110123 with the customer to deliver instructions about capturing a Process Monitor log and sending it to you.

2. To create a baseline for comparison, capture a Process Monitor log while you perform the same workflow on your computer.

3. Open the .pml file from the customer in Process Monitor.

4. Compare the two Process Monitor logs.

5. Notice a difference near the end of the logs.

1. Resolution:

1. A comparison of the two logs indicated that the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Nls\Sorting\Versions\(Default) was missing a value on the customer’s computer.

2. In the baseline Process Monitor log from your computer, the same registry key contained a value of 00060101.00060101. You removed the 00060101.00060101 value and reproduced the crash on your computer. This test confirmed the cause of the crash.

3. You advised the customer to carefully add the value 00060101.00060101 to the registry key HKEY_LOCAL_MACHINE System\CurrentControlSet\Control\Nls\Sorting\Versions\(Default).

4. SOLIDWORKS Technical Support documents this behavior in the Knowledge Base solution QA00000116270.

Troubleshooting installation issues

Most cases may be resolved by using various logs such as the verbose Windows Installer logs or the SOLIDWORKS Installation Manager logs. However, there might be corner cases where the installation logs do not provide enough information to discover the root cause.

How do I configure and use Process Monitor for installation issues?

Installation issues may take time to reach the failure point. If you run a Process Monitor capture for an entire installation, the resulting .pml file may be larger than 1 GB. There is a technique you can use to avoid this.

There is an option within Process Monitor that limits the number of events.

The option is History Depth. You need to launch Process Monitor, set the History Depth, close Process Monitor, and then restart Process Monitor for the History Depth setting to take effect.

Follow these steps:

1. Press Shift and right-click on the file procmon.exe >

   Run as Administrator

   .

2. Click the Options menu > click History Depth…

3. Click Enable ring buffer > click Limit to > Enter 1 within the Minutes textbox.

4. Close Process Monitor.

5. Press Shift and right-click on the procmon.exe file >

   Run as Administrator

   .

6. Begin the Process Monitor capture.

Confirm Flight Recorder (Max length 1 minutes) within the bottom of the Process Monitor Application window.

1. Start the SOLIDWORKS installation and reproduce the installation failure.

2. Stop the Process Monitor capture.

3. Click File > Save > choose All Events and Native Process Monitor Format (PML) > choose the name of the file and location > click OK.

4. Compress the .pml file and attach the file to the Service Request.

1. Technical Support Case Study: “The Installation Manager failed to register DesignCheckerResult.ocx…”

2. Problem:

SOLIDWORKS installation failed with the error, “The Installation Manager failed to register DesignCheckerResult.ocx “C:\Windows\system32\regsvr32.exe” /s “C:\Program Files\SOLIDWORKS Corp\SOLIDWQRKS\dsgnchk\DesigncheckerResult.ocx” returned 0x3"

1. Troubleshooting details:

• Attempted to resolve by using relevant Knowledge Base solutions

• Reinstalled all SOLIDWORKS prerequisites

• Verified permissions and Windows Updates

1. Using Process Monitor to find the root cause:

1. Provided steps to capture Process Monitor capture using a smaller History Depth setting.

2. Opened the .pml file.

3. Applied the following Process Monitor filters:

• Process Name is Regsvr32

• Detail contains

  DesignCheckerResult

1. Located the file activity with

   DesignCheckerResult.ocx

   .

2. Theorized that the command "C:\Windows\system32\regsvr32.exe" /s "C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS\dsgnchk\DesignCheckerResult.ocx" failed to find C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS\sldgridasu.dll, which is a dependent Dynamic-Link Library (DLL) file and this might be causing the failure.

1. Resolution:

• Researched Dynamic-Link Library (DLL) Search Order

• Recommended adding the SOLIDWORKS installation path to the Path environment variable.

• Added C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS to the 'Path' System Environment Variable.

  1. This resolved the issue.

Conclusion

The Process Monitor tool will help you troubleshoot difficult customer issues by providing insight into the activity that occurs behind the user interface. As you become more familiar with this tool, it will lead you to solve many issues for your customers.

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.