sldProcMon.exe: What SolidWorks' Resource Monitor Actually Does (And Why It Eats CPU)

Open Task Manager during almost any SolidWorks session and you’ll find sldProcMon.exe sitting quietly next to SLDWORKS.exe. Most of the time it’s invisible — a few megabytes of RAM, no window, no icon you’d notice. Then, on some machines, it pins a full CPU core at idle, spawns a fresh copy every time you relaunch SolidWorks without cleaning up the old one, or — in scripted and remote-desktop automation — climbs to 90%+ CPU and refuses to let go.

Dassault’s own help page calls it the “SOLIDWORKS Resource Monitor” and describes it as something that occasionally pops up a tray notification about low system resources or an uncertified graphics driver. That’s true, but it’s a small fraction of what the binary actually does. We pulled the executable apart — version metadata, import table, and every readable string — and compared the design against how an open-source CAD kernel handles the same problem. What we found is a per-session watchdog process with its own hang detector, its own reimplementation of Windows’ “(Not Responding)” overlay, and its own crash dumper for the main SolidWorks process.

The official story

The public description is thin. SolidWorks’ help topic on the Resource Monitor says it watches system and SolidWorks resource consumption and raises two tray notifications when something’s off: a general “check your system” warning, and a graphics-driver-not-certified warning that’s documented to appear “only every 10th launch” (users on the SolidWorks Forums report it firing far more often than that).

It’s easy to confuse this with SOLIDWORKS Rx, the separate, user-invoked diagnostic tool that captures system specs, event logs, and crash dumps for a support ticket. They’re not the same thing — but they’re related: when SolidWorks crashes, Rx’s reliability log frequently lists sldProcMon.exe as the faulting module (GoEngineer’s Rx overview), which is the first hint that this “resource monitor” is doing more than watching a resource meter.

Neither the SolidWorks API help files nor SolidWorks.Interop.sldworks.dll mention it anywhere. We checked — zero page-name hits for ProcMon, ResourceMonitor, or Diagnostic across the CHM docs, and zero matches across all 1,719 types in the interop assembly. This process has no public API surface at all. It’s pure internal plumbing.

What’s actually in the binary

sldProcMon.exe ships at C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS\sldProcMon.exe. Its own version resource is the first surprise:

FileDescription : SOLIDWORKS Resource Monitor
ProductName      : SOLIDWORKS Resource Monitor
CompanyName      : Dassault Systèmes SolidWorks Corporation

So “ProcMon” is just Dassault’s internal filename shorthand — it has nothing to do with Sysinternals’ Process Monitor despite the name collision. It’s a native, MFC-based C++ executable (no .NET metadata at all — loading it as an assembly throws BadImageFormatException), linked against mfc140u.dll and built with the MSVC 14.16 toolset.

One watchdog per session, wired to the parent by PID

SLDWORKS.exe launches its own sldProcMon.exe and passes it a /SWPID=<pid> argument. From there, the two processes are bound together:

• A named pipe, \\.\pipe\SolidWorksProcessMonitor_%u, carries IPC back to the main process
• A PID-scoped mutex (MutexToProtectSolidWorksProcessMonitor-<guid>_%u) enforces exactly one monitor per session

This is a companion process, not a shared background service — every open SolidWorks instance gets its own watchdog.

It’s a hang detector, not just a resource meter

The import table and extracted strings both point to the same core loop: sldProcMon periodically pings the main SolidWorks window with SendMessageTimeoutW. A timeout gets written to an internal HangLog (the string table also has “No hang in session” for the clean case).

When a hang is detected, it doesn’t just log it — it builds its own ghost window. The binary imports the full set of DWM live-thumbnail APIs (DwmRegisterThumbnail, DwmSetIconicThumbnail, DwmQueryThumbnailSourceSize, DwmUpdateThumbnailProperties) and contains a class literally named sldGhostWnd (window class swPM_GhostWindow). In other words: Windows already has a built-in “(Not Responding)” ghost overlay for frozen apps, and SolidWorks chose to reimplement it itself — almost certainly so it can attach its own tray notification and a wait/force-close choice instead of the generic OS dialog.

It also owns crash-dump capture for the main process

Alongside hang detection, the strings reveal a whole crash-service naming scheme: g_sld_crash_svc, crash_svc_class, minidump_id, and a dump filename pattern (SWDump_%d%d%dPid%d.dmp) written via MiniDumpWriteDump. If SolidWorks itself hard-crashes, it’s this companion process — not SolidWorks — that’s positioned to catch it and write the .dmp file, which is exactly why Rx’s reliability logs so often name sldProcMon.exe as the module present at crash time even when it isn’t the actual cause.

The resource-monitor part is real, just narrower than the name implies

The threshold logic that gives the process its public name is there too — string constants Warning_Threshold and Danger_Threshold, an IPC/log tag <RESOURCE_WARNING>, and imports for K32GetPerformanceInfo, GetProcessTimes, and QueryPerformanceCounter. We checked the registry key the binary references for tunable thresholds (Software\DevTools\SldProcMon\Internal) and it doesn’t exist on a normal install — these limits are almost certainly hardcoded constants, not something you can configure. The GPU-driver check uses a genuine OpenGL context (wglCreateContext, glGetString) purely to read the driver/vendor string for the certification check — there are no drawing calls imported, so it isn’t rendering anything.

Why it spikes CPU

Once you see the actual mechanism, the community-reported symptoms line up cleanly with specific parts of the binary:

The eng-tips case is the cleanest confirmation of all of this: it’s describing exactly the failure mode the binary’s design predicts. A dialog box with no interactive session to paint into is functionally identical to a genuinely hung window from the watchdog’s point of view — SendMessageTimeoutW never gets a timely response either way, so the retry loop never lets up.

The FreeCAD contrast: why a separate process at all

It’s worth asking why Dassault built this as an entirely separate executable instead of just handling crashes in-process, the way most desktop applications do. FreeCAD’s crash handling in src/Main/MainGui.cpp is a good comparison point precisely because it’s the simpler, more common approach: it calls SetUnhandledExceptionFilter in the main process itself, and when an unhandled SEH exception fires, that same filter calls MiniDumpWriteDump directly — no companion process, no IPC, no polling.

That design is fine for crashes, but it’s structurally incapable of catching a hang. An in-process exception filter only runs when the process throws an exception; a frozen-but-alive process that’s simply stopped pumping messages never throws anything for the filter to catch. That’s the actual reason SolidWorks needs a second process: only an external observer can notice that the main window has stopped responding at all. The tradeoff is exactly what you see on the affected machines — hang detection and a custom “not responding” UX, paid for with a permanently-running polling companion process for every open session. FreeCAD’s simpler model has effectively zero background overhead, but it also has no equivalent hang-detection UX if the main GUI thread wedges — a workflow difference worth knowing about if you’re comparing FreeCAD against SolidWorks and Inventor’s internals more broadly, or looking at how FreeCAD’s rendering pipeline differs from SolidWorks’ drawing internals.

What this means if you’re automating SolidWorks

If you drive SolidWorks programmatically — batch export jobs, scheduled tasks, anything running under a service account or over Remote Desktop without an interactive session — the headless-automation failure mode above is the one to plan around. Any code path that can pop a modal dialog (missing references, a licensing prompt, a “keep/discard changes” prompt) is a candidate for wedging sldProcMon.exe into an indefinite polling loop with no one able to click it away, which is a different and less obvious failure than SolidWorks itself simply erroring out. It’s the same class of problem covered in SolidWorks API gotchas that fail silently — no exception, no crash, just a process quietly burning CPU — and it’s one more reason the tradeoffs discussed in in-process vs. standalone SolidWorks automation matter: an in-process add-in runs inside the same interactive session as the user and rarely hits this, while a standalone/headless automation process is the one that needs dialog-suppression handled carefully at every step.

If sldProcMon.exe itself is the problem on a given machine — pinned CPU at idle, or instances that pile up across sessions — the practical options are the same shape as the fix we documented for SolidWorks 2025’s other background-process freeze, sldShellExtServer: confirm it with Task Manager/Process Explorer before changing anything, and know that disabling or killing the process trades away the hang-detection and crash-dump behavior it exists to provide, not just a notification you don’t care about.

Takeaways

• sldProcMon.exe’s own version resource calls it “SOLIDWORKS Resource Monitor” — the public description undersells it. It’s a per-session watchdog, not just a resource meter.
• It’s launched by SLDWORKS.exe with the parent’s PID, and stays connected via a named pipe and a PID-scoped mutex.
• Its core loop is a SendMessageTimeoutW health check against the main window, logged to an internal HangLog; on a detected hang it raises its own DWM-thumbnail-based “ghost window” (sldGhostWnd) instead of relying on Windows’ default.
• It also owns crash-dump capture (MiniDumpWriteDump, SWDump_*Pid*.dmp) for the main SolidWorks process, and does a GPU-driver certification check via a throwaway OpenGL context.
• The community-reported CPU spikes match the mechanism directly: idle polling, uncleaned-up instances across sessions, and — worst case — an indefinite polling loop when a modal dialog can’t be dismissed in headless/remote-desktop automation.
• FreeCAD’s simpler in-process crash handler is the reason the comparison is useful: it shows why a hang, unlike a crash, needs a separate watchdog process to detect at all.
• Has no public API surface — undocumented in the SolidWorks API help and absent from SolidWorks.Interop.sldworks.dll entirely.