I recommend reading What is the reason for "X is not recognized as an internal or external command, operable program or batch file"? It should help to understand how the environment variable PATH is managed by Windows. It is unfortunately not really good managed by Windows which cause lots of problems because of no command is available to safely add/remove a folder path to system or user PATH. The results of missing such a command or executable written by Microsoft to safely update PATH with applying all necessary error checks are lots of not good coded scripts which quite often corrupt system and user PATH stored in Windows registry on trying to update them.
My recommendation is opening Windows Control Panel - System and Security (on View by: Category selected) - System - Advanced System Settings - Environment Variables as administrator and cleaning up both Path environment variables, the user Path (upper pane) and the system Path (lower pane). The window Environment Variables can be opened also by clicking on Windows Start button, typing on keyboard environment and Windows suggests in the menu Edit environment variables for your account and Edit the system environment variables in the language of Windows. Click on one of the two suggested items and if necessary depending on Windows version next on button Environment Variables.
- The system
Path should start always with following default Windows folder paths:
- %SystemRoot%\System32
- %SystemRoot%
- %SystemRoot%\System32\Wbem
- %SystemRoot%\System32\WindowsPowerShell\v1.0\
- %SystemRoot%\System32\OpenSSH\
The system Path was badly updated once in the past if it does not start anymore with these folder paths exactly as written here. (The last folder path is available only on Windows 10 since version 1809 and of course Windows 11.) C:\WINDOWS stored in Windows registry and displayed on editing the system Path instead of %SystemRoot% is an indication that an installer executable or script has not good updated system Path because of replacing original folder paths with referencing environment variable SystemRoot by the expanded version. This does not really matter for these folder paths, but could have been harmful for other folder paths.
- No folder path should exist more than once in one of the two
Path environment variables.
Remove all duplicates in user Path as well as in system Path.
Your two Path environment variables contain three times:
- C:\Program Files (x86)\Common Files\Oracle\Java\javapath
- C:\Program Files (x86)\Shoreline Communications\ShoreWare Client\
- C:\WINDOWS
- C:\WINDOWS\system32
- C:\WINDOWS\System32\OpenSSH\
- C:\WINDOWS\System32\Wbem
- C:\WINDOWS\System32\WindowsPowerShell\v1.0\
A folder path existing already in system Path should not exist a second time in user Path and of course also not once more in system Path.
- A folder path can be listed without or with a backlash in
Path. I prefer folder paths without backslash at end in Path as this causes less troubles on updating Path in future on using command reg by a batch script.
- Environment variable
Path should contain only folder paths and not fully qualified file names.
So C:\Users\Kyle.Dixon\Documents\R\R-3.5.2\bin\R.exe is completely nonsense in Path.
After cleanup of both Path environment variables the folder paths in system Path should be something like:
- %SystemRoot%\system32
- %SystemRoot%
- %SystemRoot%\System32\Wbem
- %SystemRoot%\System32\WindowsPowerShell\v1.0\
- %SystemRoot%\System32\OpenSSH\
- %CommonProgramFiles(x86)%\Oracle\Java\javapath
- %ProgramFiles(x86)%\Microsoft SQL Server\150\DTS\Binn
- %ProgramFiles(x86)%\Shoreline Communications\ShoreWare Client
- C:\Program Files\dotnet
For the last path it is better to keep C:\Program Files and do not use %ProgramFiles%, except there is C:\Program Files\dotnet and C:\Program Files (x86)\dotnet which I don't know as I don't have such a directory on my Windows computer. For the reason see the Microsoft documentation page WOW64 Implementation Details.
The user Path should be finally something like:
- %LocalAppData%\atom\bin
- %LocalAppData%\Microsoft\WindowsApps
- %LocalAppData%\Programs\Git\cmd
- %AppData%\MarketView\MarketView ExcelTools
- %UserProfile%\Documents\R\R-3.5.2\bin
There is not much written about environment in which the two batch files are executed. So most written below is pure speculative.
I suppose that drive K: is not a drive on a local hard disk, but a network drive. So it is possible that the network resource mapped to drive K: is currently not available either because of network resource not mapped to drive letter K: or there is network connection issue or a network resource permission issue.
Windows remaps a network resource to a drive letter as once done by the user only on logon of the user because of network drive mappings are user account related stored by Windows in Windows registry. So if the batch file is executed as scheduled task with using a different account or also on user not logged in, the drive K: does indeed not exist. The scheduled task executing the batch file must be configured to use the account which has the necessary permissions to access all network resources and local directories/files which are accessed by the batch file. And it is additionally necessary to access files and folders on a network resource with their UNC paths instead of using drive letter K: of network drive not existing on execution of the batch file in this environment.
See also: What must be taken into account on executing a batch file as scheduled task?
But possible is also that the error message
The system cannot find the path specified.
is not output by cmd.exe on processing the batch file containing the command line
call "K:\Market Risk\activate.bat"
but on a command line executed on processing the batch file K:\Market Risk\activate.bat.
Therefore I suggest to remove from both batch files @echo off at top or change it to @echo on and run the main batch file from within a command prompt window, see debugging a batch file. Then it should be 100% clear which command line in which batch file is responsible for this error message.
