Member Avatar for technoGeek

Hi,
When my users login they run a bat file called login.bat. The batch file then calls three other files using the following commands.

%0\..\wscript.exe %0\..\
%0\..\wscript.exe %0\..\
%0\..\wscript.exe %0\..\i5settingswim.vbs

%0\..\Kix32.exe groups.scr


When this is run from a W2k machine the script runs fine without any problems. However, when the script is run an XP SP2 machine (with the Firewall switched off) I get an error message that reads

"Script error: failed to find/open script!

Does anyone know why this is happening. I'm assuming the above commands are not recognised by XP. The files its calling are are sitting in the netlogon direcoty of an NT server with SP6a.

Many thanks for any assistance.

  • 3 Contributors
  • 3 Replies
  • 218 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by technoGeek

Dani AI

Generated

Short summary: the failure on XP SP2 came from using the batch file's %0-based path for launching other interpreters and scripts; that expansion and using a UNC/netlogon path as the current directory can behave differently on XP than on W2K. Credit to for pointing the OP in the right direction and to for noting %0 is brittle — the practical fixes below are the safer, evergreen approach.

Why it breaks: cmd.exe and batch parameter expansion treat %0 and quoted paths in ways that can change the resolved string at runtime, and cmd.exe will warn or reset the current directory if it’s a UNC path (the “UNC paths are not supported. Defaulting to Windows directory.” behavior). These two facts together commonly make relative calls like the ones in this thread fail on XP. (ss64.com)

Concrete, low-risk fixes

  • At the top of the logon batch, change to the script folder (so later relative references work reliably), for example use pushd "%~dp0" / popd or cd /d "%~dp0". Use the %~dp0 parameter expansion rather than raw %0. (ss64.com)
  • Call interpreters (wscript, kix32, etc.) by their full system path or pass the script’s full UNC path; do not rely on a chain of relative ..\ expansions from %0. Kix/KiXtart in particular will report “failed to find/open script” when the script path cannot be resolved or the current directory was switched to Windows because a UNC was used. (autoitscript.com)

Quick checklist to validate

  • Echo the resolved paths (add echo "%~dp0" and echo "%LOGONSERVER%\NETLOGON\yourScript.ext") and test the exact command interactively on an XP client.
  • Quote all paths that may contain spaces.
  • Confirm NTFS share permissions and that file extensions are present.
  • If a script must run from a UNC, consider mapping a drive or use pushd (which temporarily maps) rather than relying on UNC as current directory. (jeffpar.github.io)

Example pattern (safe) — put this at the top of the logon batch and adapt paths as needed:

pushd "%~dp0"
"%SystemRoot%\System32\wscript.exe" "%LOGONSERVER%\NETLOGON\shortcut.js"
popd

This combination fixes the common XP quirks seen by while keeping the script robust across clients.

Recommended Answers

All 3 Replies

Member Avatar for technoGeek

Thats great. Works fine. Many thanks for your help. :)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.