Working on a batch file that calls another batch file.
K:\Market Risk>call "K:\Market Risk\activate.bat"
The system cannot find the path specified.
So I set the path at the beginning of my batch file and made sure it was there:
SET PATH=%PATH%;K:\Market Risk\
K:\Market Risk>echo %PATH%
C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;
C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\Shoreline Communications\
ShoreWare Client\;C:\Program Files\dotnet\;C:\Program Files (x86)\Microsoft SQL Server
\150\DTS\Binn\;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\
WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\
Shoreline Communications\ShoreWare Client\;C:\Program Files (x86)\Common Files\Oracle\
Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;
C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;
C:\Program Files (x86)\Shoreline Communications\ShoreWare Client\;
C:\Users\Kyle.Dixon\AppData\Local\Microsoft\WindowsApps;C:\Users\Kyle.Dixon\AppData\Local\
Programs\Git\cmd;C:\Users\Kyle.Dixon\AppData\Local\atom\bin;C:\Users\Kyle.Dixon\Documents\
R\R-3.5.2\bin\R.exe;C:\Users\Kyle.Dixon\Documents\R\R-3.5.2\bin;C:\Users\Kyle.Dixon\
AppData\Roaming\MarketView\MarketView ExcelTools\;K:\Market Risk\
However, I'm still getting the same error:
K:\Market Risk>call "K:\Market Risk\activate.bat"
The system cannot find the path specified.
Has anyone had this issue before?
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.
Related
This question already has answers here:
Where is "START" searching for executables?
(2 answers)
Closed 2 years ago.
I can start notepad++ with the start notepad++ successfully. But using notepad++ directly does not work.
the file Notepad++.exe in directry C:\Program Files\Notepad++
the shortcut of Notepad++.exe in directory C:\ProgramData\Microsoft\Windows\Start Menu\Programs
the %Path% shown below not contains C:\ProgramData\Microsoft\Windows\Start Menu\Programs and C:\Program Files\Notepad++
Where does start fetch the executable from?
C:\Program Files\Huawei\jdk1.8.0_222\bin;C:\Program Files\Huawei\jdk1.8.0_222\jre\bin;C:\Program Files (x86)\NetSarang\Xshell 6\;C:\windows;C:\windows\system32;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0;C:\Windows;C:\Windows\system32;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Git\cmd;C:\Program Files\apache-maven-3.3.9\bin;C:\Program Files\Git\bin;C:\Users\w30004809\Program Files\mysql-8.0.20-winx64\bin;C:\Program Files\QuickStart;C:\Users\w30004809\AppData\Local\Microsoft\WindowsApps;
Without start, CMD will only run files that it finds with a PATH search. In this case, it first tries to run the file via CreateProcessW and falls back on ShellExecuteExW. On the other hand, the internal start command always tries ShellExecuteExW even if it can't find a file. This allows using the shell API to find the executable via one of the system or user "App Paths" keys (e.g. start notepad++ when "notepad++.exe" is not found in PATH). It also allows opening a directory in a file explorer (e.g. start D:\); accessing the shell namespace (e.g. start shell:appdata); and using other registered protocol handlers such as HTTP (e.g. start http://www.stackoverflow.com).
There are different things here: when you type the name of an application, Windows checks the %PATH% environment variable, in order to start it. Please edit your question and add the value of that variable.
Next, why do you type start <application>? This means that you want to open a next command Window and launch that application in there, which makes no sense if the application is a Windows executable. Just type "Notepad++".
In top of that, please also check the location of the Notepad++.exe file, we might check if it's located in the %PATH% environment variable or not.
In the Microsoft documention the dll loading order is defined under the following link
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
If SafeDllSearchMode is disabled, the search order is as follows:
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
I don't understand the difference between
directory from which the application loaded
current directory
Let's say the application is installed in %programfiles% and I have a shortcut on the desktop to start it.
In that scenario what is "The directory from which the application loaded."?
The current directory must be the dektop, right?
Any clarification is greatly appreciated.
Scenario
I would like to install an x86 CommandLine application on a folder outside C:\Windows\System32 or C:\Windows\Syswow64 and still be able to access my app under CMD without adding my application's path inside the PATH environment variable.
Question
Is this possible to do? Maybe touching a needed registry keys?
Note: I know how to add my application into PATH variable/regvalue or how to access my application from CMD putting the required .exe in the System32/SysWow64 folder. This question is only to learn alternatives, it's not to solve issues with PATH or System dirs.
Code
I've tried this suggested approach from a comment of #Sertac Akyuz in this answer, I have stored MyApp.exe on C:\ root directory, but I can't detect the application just putting MyApp.exe under the CMD.
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe]
#="C:\\MyApp.exe"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe]
#="C:\\MyApp.exe"
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe]
#="C:\\MyApp.exe"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe]
#="C:\\MyApp.exe"
App Paths registry settings - used by Windows Explorer, to locate programs when you type program name in "Run..." box, and so on. These settings are not affecting cmd.exe behavior.
The only way to set up cmd.exe paths for searching applications is changing PATH environment variable. You can start cmd.exe from your own .bat/.cmd where you set up all required variables for current session, without changing it globally.
I have an (PowerBuilder) application (let's call it MyApp.exe) in a folder with a sub-directory that has all the required dlls. I am able to run this application, by adding the application path and associated path variable to Windows App Paths registry key.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\MyApp.EXE]
"Path"="C:\\Prog32\\MyAPP;C:\\Prog32\\MyAPP\\DLL\\;"
#="C:\\Prog32\\MyApp\\MyApp.EXE"
The above runs file. I didn't even have to register DLLs.
If possible, I would like to run it using a batch file though, as users may install multiple versions of the same application in separate folders. When I tried to do the same thing in a batch file, it cannot find the DLLs.
#SETLOCAL
SET CURDIR=%~dp0
CD %CURDIR%
PUSHD %CURDIR%
SET PATH=%CURDIR%;%CURDIR%\dll;%PATH%
start "" %CURDIR%\myApp.exe
POPD
ENDLOCAL
I created this batch in the same directory as the executable, MyApp.exe. I was expecting it would find the DLLs, same way App Paths PATH setting did. The Batch file errors out not being able to find the DLLs. Do we need to register DLLs in this case? Why is it treated differently?
Notes:
If I copied all the required DLLs to the same directory as the executable (without a DLL sub-directory), it runs fine without needing to worry about PATH or registering dlls.
We used to use installShield to install before, but admins have automated scripts to copy files, they shied away from InstallShield programs after the first install. I am trying to refine the process, so what they copy will be simplified.
Thanks in advance for all your valuable comments and suggestions.-Sam
Why is it treated differently?
Because Windows is a mess when searching for libraries. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx#search_order_for_desktop_applications
There are many elements to how the search order is determined, but in general it is like this
Check for the library...
already loaded in memory
on the KnownDLL list
in the application's directory
in the System directory
in the 16-bit System directory
in the Windows directory
in the current working directory
in the directories listed in the PATH environment variable
Overall I would agree with what MSDN states on their DLL Redirection page
It is good practice to install application DLLs in the same directory that contains the application
However, if using sub-folders is how you want to organize your application,
you might take a look into using Application Manifests. Something else to try would be to set the library directory as the working directory
#ECHO off
SETLOCAL
SET "CURDIR=%~dp0"
PUSHD "%CURDIR%\dll"
start "" /D "%CURDIR%\dll" "%CURDIR%\myApp.exe"
POPD
ENDLOCAL
In Windows, where is the most appropriate place to store an executable that will be ran as a scheduled task on a server?
A file share?
"C:"?
"C:\Windows"?
Others?
Stay out of C: and C:\Windows. Never put it on a file share (what if it isn't available)?
I'd just use a subdirectory of C:\Program Files (to be more precise, of %ProgramFiles% - the user's system may not be installed on C:, for instance).