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.
Related
I want Export the installtion by using visual Studio's "Click Once".
While i try to set the path (C:\MyInstallationFolder) I get the following issue:
Publish.InstallUrl: The string must be a fully qualified URL or UNC
path, for example "http://www.contoso.com/myapplication" or
"\server\myapplication".
I know that by default, if i leave this path empty, the instalation will be created somewhere inside of "AppData" but i must create the installation folder in this path (C:\MyInstallationFolder).
Is this possible?
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.
I have more than 40 folders are added into search PATH on my Windows 7 machine. I used to put Python environment in the User PATH. Yesterday the system can't find python.exe suddenly... I tried to move the folder path to System PATH and the problem solved.
But today, I installed Tex live package on my machine. By default, the path of C:\texlive\2015\bin\win32 was added to User PATH. System can't find any file under this folder. Then I tied to move C:\texlive\2015\bin\win32 to the end of System PATH. System still can't find any file in this folder... Finally, I tried to paste C:\texlive\2015\bin\win32 at the beginning of System PATH, than it works (all the files in this folder can be searched).
can some one explain why I put the path to the end it doesn't work but when I put the path at the beginning it works? I prefer to put some path to User PATH, I don't know why now them can't be searched?
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
When I debug my application (in the VB6 IDE), I have to specify the absolute path (e.g. c:\logfile.log) to the log file otherwise nothing is written to the log file. However, when the application is live I do not have to specify the absolute path i.e. I can specify logfile.log. Why is this?
The log file is always in the same directory as the .exe and .dll.
Your file is being written to the current working directory.
When your exe is running this is the folder the exe is sat in, however in Debug mode your exe is actually running from the temporary build location (can't actually remember where this is in VB6).
You can test this simply by doing MsgBox(App.Path) in your program and seeing what location appears.
You'll probably find that there is a logfile.log in the location that appears when you run the above command while debugging.