cdn_sfl401as.dll was not found while launching Orcad V16.3

 This problem has returned for me now 2 days in a row, though it worked fine every day (6-7 days a week) since my last posting.  Last night when it occured, it started working again when I moved the "C:\Cadence\SPB_16.5" entry in the PATH variable to the beginning of the variable instead of the end.  My theory of why this might help was that I had recently installed additional (non-Cadence) software and it may have added to the beginning of the PATH variable.  If there is a limit in the length of the PATH variable (as there was in some older Unix versions) the end of the variable might not be engaged if it is too long.  This seemed to fix the issue last night.

 However, alas, it has returned today.  This is really getting frustrating.  I'm supposed to be designing...not installing software.

You should inspect your PATH variable and insure that only 1 copy of each Cadence item in the PATH. Note there will be several Cadence entries such as tools\bin, tools\fet\bin, etc. It is best if they come first in the PATH. Also from a mgmt perspective it is best to group them all together.

So if you see one "%CDSROOT%\tools\bin"and another "C:\cds\tools\bin" you are going to have problems.

There is a limit to the PATH variable but it should be 1024 characters.

It is best to maintain the %CDSROOT% variable since it gives you the ability to switch amoung Cadence releases.

Also you have 2 locations that PATH can occur, System and User. The Cadence items should all come from one location.

Since it is hard to see the PATH all of the entities in a long PATH, I would suggest the following:

- start a cmd.exe

- in the console window type: echo %PATH% > a.txt

- inspect the PATH shown in a.txt via your favorite editor. (note these paths are expanded).

 Hi fxffxf-

Thanks for the very thorough information.  The tip on echoing environment variables from the command prompt is especially useful.  Unfortunately, this did not solve the problem.  My path is as follows:

C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\system32\nls;C:\WINDOWS\system32\nls\ENGLISH; <<REMOVED OTHER NON-CADENCE ENTRIES FOR SECURITY>> ;%CDSROOT%\tools\bin;%CDSROOT%\OpenAccess\bin\win32\opt;%CDSROOT%\tools\Capture;%CDSROOT%\tools\PSpice\Library;%CDSROOT%\tools\PSpice;%CDSROOT%\tools\specctra\bin;%CDSROOT%\tools\fet\bin;%CDSROOT%\tools\libutil\bin;%CDSROOT%\tools\pcb\bin

 Notice that the \tools\bin path is no longer repeated (I did have it twice before due to the non-variable path I previously added).  Note also that I'm using %CDSROOT% as you advised and that the dll exists in this locaton:

 

C:\>echo %CDSROOT%
C:\Cadence\SPB_16.5

C:\>dir %CDSROOT%\tools\bin\cdn_sfl*.dll
 Volume in drive C has no label.
 Volume Serial Number is C883-2860

 Directory of C:\Cadence\SPB_16.5\tools\bin

06/13/2008  10:22 AM           667,648 cdn_sfl401as.dll
               1 File(s)        667,648 bytes
               0 Dir(s)   3,306,053,632 bytes free

C:\>

Note also that these errors started occuring BEFORE I manipulated my PATH variable.  This all started after weeks of running after a normal install.

 Note also that these problems are intermittent even now.  I just never know when I start up my PC each time whether it will work this day or not....

 Just now, I got OrCad to start working by causing the path to be reloaded....without changing the path at all!

 Here's what I did:

Right Click My Computer -> Properties -> Advanced -> Environment Variables

(select PATH from User variables section)

Click Edit

Click OK without changing anything -> OK -> OK

Is this problem occuring because the OrCad development team is relying on an environment variable based system and that this system is unstable in Windows?  The use of environment variables is fundamental to Unix and Linux, but doesn't seem to be mainstream for Microsoft.  Software originally written for Unix/Linux and later ported to Windows seems to end up using this Windows feature more. 

If you checked the PATH in the registry editor (regedit), you would probably see the PATH was a variable of type REG_SZ. For variable expansion to work, it needs to be type REG_EXPAND_SZ. Going into the My Computer property sheet may have reset the variable to the correct registry type.

In the registry these are located @:

HKEY_CURRENT_USER\Enviroment -- user env variables

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]  - system variables