OrCAD Capture loading long delay or hang in Windows 10, CPU 100%

[DeviceNode]

I recently migrated from Windows 7 to Windows 10. Initially in Windows 10, Capture took a long time to load but then worked OK.

Now it always hangs on load and crashes after about 3 minutes.

CPU starts at 5-20% and quickly pegs to 100%
- Antivirus Software high CPU usage
- Service Host: Local System (Network Restricted) high CPU usage

I have version 16.0, but I've heard of similar things happening with 16.2, 16.3, 16.5.

I've noticed the following (please read before you respond):

1. CPU pegging to 100% still happens if I remove all antivirus software (and turn off Windows Defender).
2. Full system scans with two antivirus packages show no viruses.
3. If I rename cdsMsgServer.exe and cdsNameServer.exe to ".old" extensions (found in a forum post) the CPU pegging doesn't happen but Capture still hangs and crashes.
4. Seems to happen post-license-checkout -- license checking happens at the very beginning of the load and I get to the point where it fully draws the window.
5. I have a dongle type license, lmutil say the licenses check out OK and Layout works.
6. I've put in antivirus excludes for capture.exe, cdslmd.exe, lmgrd.exe, lmutil.exe, lmtools.exe.
7. Layout Plus loads and operates just fine.
8. I've tried setting compatibility mode to WinXP-SP3, Win7-SP1.
9. Checked security and application event logs, haven't seen anything around the time of the hang/crash.

Anything else you can think of that I can check/try? Thanks.

Regards,

John

 

[BradtheRad]

I once tried removing one of two ram chips in my computer. Operation bogged down severely. I believe it was doing a lot of memory bank swapping, to compensate for the smaller ram size.

Try a utility called SysInternals Process Explorer. It shows more data than Task Manager.

Both of the above tell you what processes are running, how much ram they consume, what percentage of cpu time they consume, etc.

 

[DeviceNode]

Thanks, Brad. I'll check out SysInternals Process Explorer. I need to see in finer grain what's going on.

This is not a functional use of too much memory or any other resources. It's something pathological. OrCad Capture ran just fine on XP with 1/4 the memory and 1/10 the processor power. And it ran just fine on this same computer under Windows 7. Something is going crazy during startup, like some new security procedures or application sandboxing in this OS.

I'll see what I can find with SIPE.

 

[DeviceNode]

Score, Brad!

Turns out something involved with the OrCAD Capture startup process is spawning a never-ending stream of cdsNameServer and cdsMsgServer processes. I guess this tweaks the antivirus and other processes that manage services, and ends up pegging the CPU time. I can only guess that the endless stream of cdsMsgServers interfere with the message-passing system on which OrCAD operates.

Now I've got to figure out what's killing the processes or spawning too many.

 

[BradtheRad]

Glad I could help. Other things to look at:

* Event log, System log, Application log, etc. Look for notifications and errors created by your application and its processes.

* Settings for Services. Which services are set for auto start, which are disabled. Certain services start up only when called. These may interact with your application and its processes.

 

[MicroKris]

I'm also having this issue as well, however I have noticed an interesting phenomenon, Renaming both the CDSmsg/nameserver.exe to CDSmsg/nameserver.exe.old stops the CPU usage problem, however Capture takes a long time to load and PCB editor takes forever to load or close. The interesting part is if you rename the CDS server files WHILE they are running, they will continue to run with the .old, and are no longer constantly killed/spawned. While they are running Capture loads in under 30 seconds and PCB editor loads within a minute. However this is a terribly clumsy set-up and is not a real solution.

Please let me know if you have found a solution yet, I've been unable to find any help on this subject that has been very useful. I'm running 16.3 on a Windows 10 machine.

 

[DeviceNode]

That's very interesting, Kris. I wasn't able to reproduce that behavior. When I rename the two files to ".old", they stop spawing and CPU usage goes back down but Capture still won't run, and it crashes even sooner.

If you look quickly with Task Manager, or of you try Process Explorer that Brad recommended, you can see a half dozen or more instances of each file's process constantly spawning and destroying.

I wish I could figure out who was spawning them and destroying them. That might give some clue as to why this is happening in Windows 10.

One piece of info: When I renamed them back to ".old", I got a Windows Firewall message that it was blocking some of their features and I said to allow them, but it didn't seem to help.

 

[DeviceNode]

Here's another clue. When I rename cdsName/MsgServer.exe to .old, and I try to start up Capture again, I don't see cdsName/MsgServer.exe in the task list any more. But what I do see is the Antivirus software pegging the CPU, still. I saw this with Norton, BitDefender, and AVG.

And when I turn off the Antivirus, I see another task pegging the CPU:
Service Host: Local System (Network Restricted)

Apparently whatever was launching cdsNameServer and cdsMsgServer is still sending requests to the svchost task to launch them?

Ring a bell, anyone? Any ideas for how to track down the requestor?

John

 

[MicroKris]

Alright, so I did some further testing and found that OrCad's 16.6 Lite Demo they have on their website works in windows 10, I installed it in a different directory and copied to following files from ...\tools\bin in 16.6, to the same directory in 16.3:

cdsCommon.dll
libsman.dll
libem.dll
mpsc.dll
cdsMsgServer.exe
cdxNameServer.exe

This resolved all my issues and OrCad PCB editor and Capture Schematic both work without any slow start-up or high CPU usage.

 

[DeviceNode]

Kris, how did you arrive at that set of files? It didn't work for me running on 16.0. I don't get the CPU pegging, now, and I see cdsMsgServer/NameServer running with a single instance, finally, but Capture still doesn't execute; just hangs for about a minute and then gets killed off as "unresponsive".

I tried just copying over cdsMsgServer/NameServer.exe but I get the same thing. No missing DLL messages or anything like that. Then I introduced cdsCommon.dll, then the minor dll's. Same thing, just unresponsive Capture and no CPU pegging.

So how did you arrive at that file set? Maybe the technique could help me.

- - - Updated - - -

Actually, cdsMsgServer/NameServer don't appear in the task list unless I include all those files, but Capture still doesn't run.

 

[MicroKris]

Alright a little insight into what I did, I figured out is that Orcad uses the Enviroment variable CDSROOT to find all your bin files and libraries, so this ends up getting a little confusing when running multiple installations of Orcad, as there can only be One CDSROOT variable or things get messy.

I isolated the CdsNameServer and CdsMsgServer into an Empty file structure (same as a normal Orcad Installation, but with only the C:\Test\tools\bin) and set the test folder to be the CDSROOT. When I ran the CDS exe's they error-ed and reported all the files that were missing (cdsCommon.dll, libsman.dll, libem.dll, mpsc.dll)

So then I took these files from the 16.6 Lite installation, and put them in my 16.3 installation, and changed the CDSROOT to point to the Root folder of my 16.3 installation (C:\Cadence\SPB_16.3, for example) and my program began running properly.

If this does not resolve your issue, then you may have multiple problems. Here is one of the more common fixes from the Cadence community forums:

Make sure that you have any Capture related processes closed, a reboot should get you there. Find the active Capture.ini file, usually in the installation in tools\Capture and rename it. Start Regedit.exe, find the HKEY_CURRENT_USER\Software\OrCAD\CaptureWorkspace key and delete it and the subkeys that belong to it, then close regedit and see if that fixes things. Get the latest hotfix.

 

[duk]

Alright a little insight into what I did, I figured out is that Orcad uses the Enviroment variable CDSROOT to find all your bin files and libraries, so this ends up getting a little confusing when running multiple installations of Orcad, as there can only be One CDSROOT variable or things get messy.

I isolated the CdsNameServer and CdsMsgServer into an Empty file structure (same as a normal Orcad Installation, but with only the C:\Test\tools\bin) and set the test folder to be the CDSROOT. When I ran the CDS exe's they error-ed and reported all the files that were missing (cdsCommon.dll, libsman.dll, libem.dll, mpsc.dll)

So then I took these files from the 16.6 Lite installation, and put them in my 16.3 installation, and changed the CDSROOT to point to the Root folder of my 16.3 installation (C:\Cadence\SPB_16.3, for example) and my program began running properly.

If this does not resolve your issue, then you may have multiple problems. Here is one of the more common fixes from the Cadence community forums:

I can confirm that MicroKris's solution worked for my installation of 16.2 on Win10 x64. I had the same symptoms described in this thread and they are gone after installing 16.6 lite, then setting CDSROOT back to the 16.2 installation and copying MicroKris's suggested dlls from the 16.6 lite bin directory to the 16.2 bin directory. THANKS.

 

[StratMan]

Hi! New kid on the block here. Would someone be kind enough to explain how to "change the CDSROOT to point to the Root folder of my 16.3 installation". I'd be most appreciative.

Thanks,
Lou

 

[duk]

On the Startup bar type "Environment" and select "Edit the System Environmental Variables." In the "System Properties" dialog that opens, click the "Environmental Variables" button at the lower left. In the list of system variables, you should see CDSROOT listed. Select it and click Edit...
If it isn't listed, at the variable and set it to the correct path.