A batch script using pushd to set the working directory before running the program resolves the error.
PROGRAM FAILS FROM BATCH FILE DUE TO WRONG WORKING DIRECTORY
*A Windows batch file launched a program that immediately errored, while double‑clicking the same executable in Explorer ran it flawlessly. The discrepancy traces back to how the operating system sets the process's current directory. The fix is a single line change in the batch script.*
A developer asked why a Windows program threw an error when launched from a batch file but ran cleanly when double‑clicked in Explorer. The symptom pointed to a hidden state: the process's current directory. In Windows, Explorer deliberately sets the current directory to the folder that contains the launched item, a legacy convenience for programs that resolve files relative to their own location. The batch file, by contrast, executed the program with a full path while leaving the current directory unchanged, sending the program into the wrong folder. Raymond Chen of The Old New Thing dissected the case, confirming that the program was looking for ancillary files in the wrong place. The solution was a single directory change in the script, restoring the expected environment.
Why does the program fail when run from a batch file?
Raymond Chen explains that Explorer sets the current directory of a launched program to the folder that contains the executable. The batch file, however, invoked the program using its full path without altering the current directory. If the program searches for ancillary files—such as ABC.LTC or ABC.LDC—in the current directory, it will look in the batch file's working folder instead of its own. The mismatch causes the program to miss required resources and display an error. The customer confirmed that the program behaved exactly as described, confirming the current‑directory hypothesis.
How does Explorer determine the working directory?
When a user double‑clicks a file in Explorer, the shell changes the process's current directory to the directory that holds the clicked item. This behavior exists to accommodate legacy programs that resolve related files relative to the current directory. The same rule applies when the user double‑clicks the .exe itself: the current directory becomes the executable's folder. This automatic adjustment is invisible to the user but critical for programs that do not compute absolute paths.
What fix restored the program’s functionality?
The customer added two commands to the batch script: pushd to change the working directory to the program’s folder, then the program call, followed by popd to restore the original directory. This explicit directory change mirrors Explorer’s behavior, allowing the program to locate its ancillary files. After the change, the program ran without error, confirming that the missing current directory was the sole obstacle.
Could an App Paths entry also explain the failure?
Chen notes a secondary possibility: the program might have a custom entry under the Windows App Paths registry key. Such an entry can inject additional directories into the PATH environment variable when the program starts. If the batch file bypassed this mechanism, the program could lose access to required DLLs or data files. While the customer did not test this angle, Chen suggests it as a plausible alternative to the working‑directory issue.
Frequently asked questions
Why does a program work when double‑clicked but not from a batch file?
Explorer sets the program's current directory to its own folder, while the batch file runs the program with a full path but leaves the current directory unchanged, causing the program to miss ancillary files.
How can the batch file be corrected to run the program successfully?
Add a pushd command to change to the program's directory before launching it, then use popd to restore the original directory, replicating Explorer's behavior.
What alternative cause did Raymond Chen suggest besides the working directory?
He mentioned checking for a custom App Paths registry entry that could modify the PATH environment variable when the program runs.
The episode underscores a timeless Windows pitfall: assuming the current directory is irrelevant. Modern scripts that invoke executables must either mimic Explorer's directory handling or compute absolute paths themselves. Ignoring this detail can cripple legacy tools and expose hidden dependencies. As developers automate more workflows, a single pushd/popd may be the difference between silent success and baffling failure.
Sources: [The Old New Thing blog post by Raymond Chen, https://devblogs.microsoft.com/oldnewthing/20261026-00/?p=112797/]