SolidWorks UI Settings That Don't Persist — PropertyManager, Toolbars, and the Registry Fix

Some SolidWorks settings save reliably between sessions. Others reset silently every time you restart, or behave differently depending on how SolidWorks was installed, what Windows profile type is in use, and whether any admin policy overrides your preferences. This post covers the specific settings that fail most often, where they’re stored, and the fixes that work.

Where SolidWorks Stores Its Settings

SolidWorks stores user settings in two places: the Windows registry and document files. Knowing which is which tells you immediately whether a reset issue is a machine problem or a template problem.

Registry-stored settings (per-user, per-machine):

• System Options (Tools → Options)
• Toolbar layout and visibility
• Keyboard shortcuts
• Mouse gestures
• PropertyManager behavior
• Background and viewport color
• Display quality settings
• Recent files list

Registry path: HKEY_CURRENT_USER\Software\SolidWorks\SOLIDWORKS [year]\

Sub-keys of interest:

Document-stored settings:

• Drawing sheet format and scale
• Configuration visibility
• Material definitions
• Custom property values

The split matters because document settings roam with the file — registry settings stay on the machine. When a model opens differently on two workstations, that’s almost always a registry difference, not a document difference.

Settings That Don’t Persist — and Why

PropertyManager Pane Width

The PropertyManager width — the divider between the left panel and the graphics area — frequently resets to a default. SolidWorks snaps the divider to an “optimal width” it calculates based on the active PropertyManager content. This snap can override a manually dragged position, especially on a new session.

The root cause: SolidWorks stores the PM width in a registry key under HKCU\Software\SolidWorks\SOLIDWORKS [year]\User Interface\. On machines with roaming profiles, Windows may not write this key back before the profile is unloaded on logoff — meaning the value written during the session never survives. Network latency or profile size limits on enterprise systems are common culprits.

Fix for the auto-snap behavior specifically: SolidWorks 2022+ added a preference to disable it. Under Tools → Options → System Options → General, look for “Resize PropertyManager to show full content” — disabling this stops the auto-snap that overrides your manual drag. The manual position may still not persist across sessions on roaming profiles, but at least it won’t snap mid-session.

Auto Show PropertyManager

Tools → Options → System Options → General → “Auto-show PropertyManager” controls whether the PropertyManager opens automatically when you click geometry. This setting sometimes unchecks itself between sessions.

This is a registry-stored preference. The known failure mode: in certain SolidWorks versions (particularly 2019 SP2 through 2020 SP0 on enterprise configurations), the setting reverts to disabled on restart. A clean profile or corrupted registry key causes it to revert.

Permanent fix for recurring reversion: use the Settings Wizard (Tools → Save/Restore Settings) to export a .sldreg backup immediately after configuring the option correctly. When it reverts, restore takes under a minute. This is clunky but reliable.

For enterprise environments: push the registry value via Group Policy Preferences. The key HKCU\Software\SolidWorks\SOLIDWORKS [year]\General\AutoShowPropertyManager (DWORD, 1 = enabled) can be set as a GP Preference to apply on every login, ensuring it’s always active even if the local registry is corrupted or reset.

Toolbar Customizations Not Saving

Toolbar position and visibility are stored in HKCU\Software\SolidWorks\SOLIDWORKS [year]\User Interface\. When customizations don’t save, it’s almost always one of three causes:

1. SolidWorks exited abnormally (crash or task kill). Settings write to the registry on clean exit. If SolidWorks terminates via task manager, a crash dialog, or a power loss, the write doesn’t happen. The previous clean session’s toolbar state is what survives.

2. Admin-installed SolidWorks with per-machine registry keys. Some enterprise installs write the base configuration to HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER. HKLM keys are read-only for standard users. Any customization the user makes goes to HKCU, but HKLM takes precedence on read — so the customization appears to save but is overridden on next launch.

3. Redirected registry (roaming profiles, App-V). Enterprise environments sometimes redirect HKCU writes to a network location. If the redirect fails (VPN drop, slow network, profile size limit hit), the write is silently lost.

Diagnostic: Open regedit, navigate to HKCU\Software\SolidWorks\SOLIDWORKS [year]\User Interface\, and inspect the key’s permissions. If your account doesn’t have Write permission, settings can’t save — the registry access will succeed in-memory but fail on commit.

Sketch Relations Visibility

View → Hide/Show → Sketch Relations resets to the previous session’s default on every new document. This is by design — it’s a view state, not a persistent setting. SolidWorks doesn’t persist view state across new documents.

Fix: set the desired view state in your part and assembly templates, then save those templates. New documents created from those templates will inherit the sketch relations visibility. Under Tools → Options → System Options → File Locations, verify your template paths are pointing to the correct customized templates.

Reference Triad and Coordinate System Visibility

Same class as sketch relations — view state, stored per-document in the template. Fix it in the template, not in System Options.

The Settings Wizard — What It Actually Exports

Tools → Save/Restore Settings (called “Copy Settings Wizard” in versions before 2020, “Settings Wizard” in 2020+) exports a .sldreg file containing:

• System Options (the full System\ registry sub-key)
• Toolbar layout
• Keyboard shortcuts
• Mouse gestures
• Menu customization
• Saved views

It does not export:

• Recent file list (machine-specific paths are meaningless on another machine)
• License information
• Hardware-specific display adapter settings

The .sldreg format is a Windows INF-style registry export — open one in a text editor and the structure is human-readable. The Settings Wizard’s “Restore” function runs reg import against it. You can also import it directly from the command line: reg import your_settings.sldreg.

Usage pattern for reset-prone machines: configure SolidWorks exactly as you want it, export to .sldreg, store the backup on a network share. When settings reset after a crash, Windows update, or profile rebuild, restore in under 30 seconds. For a team where everyone should share the same toolbar layout and options, distribute a single .sldreg file and have each user import it once.

Per-Document vs Per-System Settings

Understanding this split prevents spending time chasing registry issues that are actually template problems.

The Read-Only Registry Problem

The most common root cause of settings not saving in enterprise environments: SolidWorks has no write access to its own registry keys.

This happens when:

• SolidWorks was installed by an administrator and HKCU keys were not properly seeded for standard users
• Group Policy enforces software restriction policies that block HKCU writes for the SolidWorks paths
• App-V virtualization captures HKCU writes into an isolated container that doesn’t persist between launches
• Profile management software (Citrix UPM, FSLogix) excludes the HKCU\Software\SolidWorks path from the roaming profile

Diagnostic method: Install Process Monitor (Sysinternals) and capture during SolidWorks launch and close. Filter by Path contains SolidWorks and event type RegSetValue. Look for ACCESS DENIED results or writes that succeed but are immediately overwritten by another process.

For software-level diagnostics, the ISldWorks.GetUserPreferenceIntegerValue() and SetUserPreferenceIntegerValue() API methods read and write the same preference values programmatically. If you set a preference via API and it persists in-process but not across sessions, the registry write path is failing at the OS level. If it doesn’t even persist in-process, the enum value is wrong or the setting is document-scoped. The SolidWorks API gotchas post covers silent failure patterns in the preference API.

Version-Specific Regressions

Not all settings reset issues are environment problems. Some are bugs in specific SolidWorks service packs:

• SW 2019 SP2–SP4: Auto Show PropertyManager unchecks on restart. Fixed in SP5.
• SW 2020 SP0: User toolbar settings revert after Windows Update on some configurations. Workaround: Settings Wizard restore after any Windows Update.
• SW 2022: “Resize PropertyManager to show full content” option added — resolves the most common PM width complaint for users who aren’t on enterprise roaming profiles.
• SW 2023+: Settings Wizard renamed to Save/Restore Settings; .sldreg format unchanged; restore process identical.

If your settings reset started after a specific SolidWorks update, check the What’s New documentation or SOLIDWORKS SPR database for that service pack. Service pack release notes list known regressions in the UI/settings area.

API Workaround: Apply Settings Programmatically on Document Open

If a setting genuinely won’t survive sessions and you can’t fix the underlying registry issue, apply it programmatically using a document-opened event in a SolidWorks add-in.

A minimal add-in can listen to ISldWorks.ActiveDocChangeNotify and apply preference values on every document open:

// In your add-in's Connect() method:
swApp.ActiveDocChangeNotify += OnActiveDocChange;

private int OnActiveDocChange()
{
    // Ensure Auto Show PropertyManager is always on
    swApp.SetUserPreferenceIntegerValue(
        (int)swUserPreferenceIntegerValue_e.swPropertyManagerAutoShow, 1);

    // Ensure sketch relations are always visible
    swApp.SetUserPreferenceIntegerValue(
        (int)swUserPreferenceIntegerValue_e.swViewDisplayShowSketchRelations, 1);

    return 0;
}

This doesn’t fix the root cause but ensures the settings are active regardless of what the registry says at session start. The same pattern works for DXF export settings that reset between sessions — see why SolidWorks DXF export entity selections don’t persist for the specific swExportDataSheetsToExport and swExportDXFDWGLayerMapping preference enums.

For teams distributing a SolidWorks add-in to enforce consistent UI behavior, a settings enforcer event handler is a practical solution — it guarantees consistent PropertyManager and toolbar behavior across a team without requiring each engineer to manually restore their .sldreg after every crash or Windows update.

Quick Reference: What’s Failing and Where to Look