SOLIDWORKS Performance Diagnosis & Troubleshooting

01 Isolate the Layer First

"It's slow" is not a diagnosis. Four independent layers can produce identical complaints, and each has entirely different remedies. Almost all wasted troubleshooting effort comes from working on the wrong layer.

Before changing anything, establish where the cost is being incurred. A large assembly that takes minutes to open, a drawing that lags while panning, a vault search that hangs, and a rebuild that stalls are four different problems that engineers will report using the same words.

WorkstationDriver, memory, storage, endpoint protection

ModelStructure, references, geometry, configurations

NetworkLatency dominates, not bandwidth

ServerArchive throughput and database performance, separately

Scope and currency

Diagnostic tooling and its capabilities change between releases. The method here is release-independent; verify specific tool names and locations against the documentation for the release in service.

02 A Diagnostic Method

Step 1Get a specific, reproducible caseWhich file, which operation, how long. "Assemblies are slow" cannot be investigated; "this assembly takes four minutes to open and thirty seconds to rotate" can.
Step 2Establish the scopeOne user or many? One file or all files? One machine or the whole fleet? This single question eliminates most of the possibility space immediately.
Step 3Establish when it changedHas it always been slow, or did it change? A change points at an update, a policy push or a data growth threshold rather than at design.
Step 4Test the same file on a known-good machineSeparates the model from the workstation in one step, and is the highest-value single test available.
Step 5Test a known-good file on the affected machineThe complementary test. Together these two localise the fault to model or machine with near certainty.
Step 6Measure before and after any changeRecord the operation time. Without a number, an improvement cannot be distinguished from a good mood.
Step 7Change one thing at a timeApplying five remedies at once means never learning which one worked, and carrying four unnecessary changes forward permanently.

The two-test triangulation

Steps 4 and 5 together resolve the majority of cases in about ten minutes. Slow file on every machine, fast file on the affected machine → it is the model. Every file slow on one machine only → it is the workstation. Everything slow for everyone → it is the server or the network.

Do these before touching a setting. The instinct to start adjusting graphics options is strong and usually wastes an afternoon.

03 Workstation Layer

Where one machine is affected and others are not. Four causes account for the overwhelming majority.

Workstation causes, symptoms and checks
Cause	Characteristic symptom	Check
Uncertified or updated graphics driver	Visual artefacts, missing display modes, instability under large assemblies	Driver version against the certification listing for the release in service
Endpoint protection scanning	Slow open, save and vault check-in; interactive work feels normal	Whether documented exemptions are actually applied on this machine
Memory exhaustion	Progressive slowdown as more is opened; heavy disk activity; eventual instability	Memory consumption while the affected assembly is open
Storage	Slow open and save specifically; other operations unaffected	Whether working files and the vault cache are on local solid-state storage
Redirected folders	Slow open and save; the configured path looks correct	The resolved physical path of working folders and the vault cache
Accumulated local state	Gradual degradation over months; unusual interface behaviour	Whether resetting the user profile settings restores performance

Fleet-wide symptoms appearing simultaneously

Where several machines develop the same fault within a few days and no application change occurred, the cause is almost always something pushed to them — a graphics driver update, an endpoint protection policy change, or a group policy modification affecting folder redirection.

Ask what changed in the estate before investigating anything in the application. This class of cause is invisible from inside the software and accounts for a disproportionate share of escalated cases.

04 Model Layer

Where one file is slow everywhere. This is design and modelling practice rather than administration, but the administrator is usually the one asked to fix it.

Common structural causes

Excessive external references. In-context relationships across many components force wide rebuild propagation. A change to one part triggers evaluation across the network of dependants.
Deep or circular reference chains. Where parts drive each other, rebuild order becomes expensive and sometimes non-deterministic.
Imported geometry. Translated bodies without feature history are heavy to display and to evaluate, particularly where many are present.
Over-populated configurations. A part with hundreds of configurations carries all of them, and configuration switching in an assembly becomes costly.
Fully resolved large assemblies. Opening everything resolved when lightweight or selective loading would serve is the single most common avoidable cost.
Complex display state. Extensive appearances, textures and transparency multiply graphics load independently of geometric complexity.
Drawing view count and detail. Many views of a large assembly at high display quality, particularly with hidden lines removed, is expensive to regenerate.

Use the built-in evaluation tools before guessing

The application provides rebuild and performance evaluation reporting that identifies which features and components consume the time. This turns a subjective complaint into a ranked list, and the top item is frequently something nobody suspected.

It is also the right evidence to take to a designer. "This assembly is slow" invites defensiveness; "these four features account for most of the rebuild time" invites a conversation about the model.

Techniques that help

Lightweight and large-design-review modes load reduced representations. Selective loading brings in only the subassemblies being worked on. Simplified configurations suppress detail not needed at assembly level. Speedpak-style reduced representations serve components used for context rather than modification. None of these is an administrative control — they are modelling practice — but establishing them as expected practice is properly an administrator's concern, because a team that uses them well operates comfortably one hardware tier below one that does not.

05 Network Layer

The layer most often misdiagnosed, because the intuitive measure is the wrong one.

Assembly operations involve many small round trips rather than a few large transfers. That makes latency, not bandwidth, the governing property. A high-bandwidth link with meaningful latency performs poorly regardless of throughput, which is why an upgrade to a faster connection so often produces no improvement and considerable disappointment.

Never work directly against a remote share. The supported patterns are a local vault cache or a replicated archive server at the remote site.
Distinguish file retrieval from metadata operations. Retrieval is fixed by a local archive replica; browsing and searching are database operations and remain WAN-bound.
Measure round-trip time, not throughput. The relevant number is latency between client and server, and it is the number to quote when discussing the link.
Check for a segmentation or inspection change. Traffic inspection appliances inserted between clients and servers add latency to every round trip and are frequently deployed without engineering being told.
Confirm licence server reachability. A slow or blocked path to the licence host produces startup delays that look like application problems.

Replication does not fix metadata latency

Remote users often expect a replicated archive server to make everything feel local. It fixes file retrieval — usually the dominant cost — and does nothing for browsing, searching or state transitions, which continue to reach the central database over the WAN.

Where the actual complaint is slow browsing rather than slow retrieval, replication is the wrong remedy and will disappoint after significant expenditure. Measure which operations are slow before committing.

06 Server Layer

Where everything is slow for everyone. The two halves of the vault architecture have distinct symptoms and distinct remedies.

Archive-side symptoms

Slow retrieval, check-in and check-out, particularly of large assemblies. Interactive work is normal once files are local.

Archive volumes on slower storage than assumed.
Endpoint protection scanning the archive folders.
Archive storage approaching capacity.
Shared virtualisation storage contending with other workloads.

Database-side symptoms

Slow browsing, searching, state transitions and data card loading. File retrieval itself is normal.

Database engine sharing hardware with other applications.
Insufficient memory allocated to the database.
Database maintenance not running — indexes and statistics stale.
Free database edition approaching its size ceiling.

Three cheap checks before anything else

Endpoint protection scanning the archive folders or the local vault cache. The database engine co-tenanted with another application. Archives on storage that is slower than the specification suggested — commonly because a virtualisation estate placed them on general-purpose shared storage.

These three account for a large share of vault performance complaints, none requires expenditure, and all three can be checked in under an hour.

Database maintenance

Database performance degrades over time without routine maintenance — index rebuilds and statistics updates. The upper capability tier provides native scheduling for this; the lower tier, using the free edition, has none, so it must be scripted deliberately. An environment that has never run maintenance will show gradual degradation over years that is easy to attribute to data growth and is often substantially recoverable.

07 Escalation

Some problems belong with the vendor or reseller. What you gather beforehand determines whether that is a short exchange or a long one.

What to gather

A reproducible case. Specific file, specific operation, specific timing, and whether it reproduces on another machine.
A system diagnostic capture. The application provides a diagnostic tool that collects configuration, hardware, driver and log information into a single package. Generate it from the affected machine.
Version detail. Release and service pack, vault client and server versions, database engine version, graphics card and driver version.
What changed. Recent updates, driver changes, policy pushes, infrastructure work, and when the symptom first appeared.
Scope. How many users and machines, and whether any are unaffected.
What you have already eliminated. The tests run and their results. This prevents being asked to repeat them.

Reproduce before escalating

An intermittent fault that cannot be reproduced on demand is very difficult for anyone to investigate, and an escalation without a reproducible case usually returns a request for more information.

Where a fault genuinely is intermittent, log occurrences — who, when, what they were doing, what else was running. A pattern usually emerges, and the pattern is frequently more informative than the fault itself: a particular time of day points at a scheduled task, a particular user points at their machine or their models.

08 Diagnostic Checklist

Reproducible case established. Specific file, operation and timing, not a general description.
Scope determined. One user or many, one file or all, one machine or the fleet.
Change history established. Whether the symptom is new, and what changed in the estate around that time.
Two-test triangulation run. Affected file on a good machine, good file on the affected machine.
Baseline measured. Operation time recorded before any change is made.
One change at a time. Each remedy applied and measured independently.
Driver version verified. Against the certification listing, on the affected machines.
Exemptions confirmed applied. Endpoint protection exclusions verified present on the machine, not just in policy.
Resolved paths checked. Working folders and vault cache confirmed local, not redirected.
Evaluation tooling used. Rebuild and performance reporting run before attributing a problem to the model.
Server halves separated. Archive-side and database-side symptoms distinguished before remedying either.
Database maintenance confirmed running. Index and statistics maintenance scheduled or scripted.
Escalation package prepared. Diagnostic capture, versions, scope, change history and eliminated causes gathered before raising a case.

09 Frequently Asked Questions

Everything got slower after we upgraded. Is the new release the cause?

Sometimes, but check three other things first. Graphics driver — the certified version for the new release may differ from what is installed. Endpoint protection exemptions — these are often defined by path or version-specific folder and may no longer match after an upgrade. And database maintenance following a vault upgrade, since the schema change can leave statistics stale.

If those are clear and the regression is genuine, gather a reproducible case and a diagnostic capture and raise it. Note also that a new release may enable display or performance settings differently by default — compare system options against your pre-upgrade settings file.

One engineer's machine is always slow. Do we replace it?

Not before checking the four cheap causes, because replacement frequently reproduces the problem on new hardware. Driver version, endpoint protection exemptions actually applied on that machine, whether folder redirection has captured their working folders, and whether accumulated profile state is the cause — a settings reset is quick and occasionally decisive.

Also check whether the engineer works differently: consistently opening assemblies fully resolved where colleagues use lightweight modes will produce exactly this pattern, and that is a practice conversation rather than a hardware purchase.

Should we increase memory or upgrade the processor?

Measure which is binding before spending. If memory consumption approaches capacity while the affected assembly is open, memory is the constraint and adding processor will change nothing. If memory has headroom and the delay is in rebuild rather than in opening, the constraint is single-thread performance.

Memory is usually the better first investment for assembly work, because exceeding it converts slow into unusable, whereas a slower processor is merely slower. But confirm from measurement on the actual machine rather than reasoning from the specification.

The vault is slow for remote users only. What are the options?

First determine which operations are slow, because the remedies diverge completely. Slow file retrieval is addressed by a replicated archive server at the remote site. Slow browsing and searching are database operations and replication will not help them.

Where metadata latency is the actual problem, the realistic options are reducing round-trip time on the link, or hosting virtualised workstations near the central servers so the remote user drives a display rather than moving data. Both are significant changes, which is why measuring before committing matters — a replication project that addresses the wrong half is expensive and disappointing.

Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.

SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.