1

On Windows servers (I've tested 2008 R2 and 2012 R2) we noticed different behavior in execution of Perl scripts that are called from batch.

Consider a primitive batch file as follows:

:beginlbl
call path\script.pl
goto :beginlbl

Sooner or later (sometimes after just a few script executions on other occasions after hundreds of executions) there will be an error message: "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."

If the second line of the code is modified to look as follows:

call perl path\script.pl

(Note the executable name before the script.) The script will run forever without issues.

What is Windows executing differently in the two cases outlined above?

hdk
  • 13
  • 4
  • 3
    When you call a .pl file the perl interpreter that is registered with ftype is used to run the file. When you use `perl x.pl` the perl interpreter in the system path is used. They could be diferent. Run `assoc .pl` and `ftype perl` (replace perl with the result of the assoc cmd). This might give you a clue as to what is happending – uSlackr Dec 09 '16 at 20:37
  • Why are you using `call` at all for a perl script? Call is for running other batch files, or jumping to a subroutine in the current file? – Zoredache Dec 09 '16 at 20:39
  • By using call cmd.exe maintains a return stack; if script.pl returns immediately this endless loop could crash the stack. Don't use call if not to call another batch. – LotPings Dec 09 '16 at 21:20
  • "call" is used to stop badly behaving applications from folding cmd.exe that called them. While it may be not optimal it worked for many years. It doesn't explain the reason why perl calls erratically are denied by the OS. @uSlackr - I tried your suggestion - it is all in order. The infinite loop is just testing. The real script is far more "sensitive" and with finite loops. – hdk Dec 10 '16 at 04:01

2 Answers2

1

Using the file association goes through a shell process to evaluate the file type (extension) and launch the appropriate process. You're likely overwhelming this. This is similar to how you get your registered editor when invoking a .txt. See also ShellExecute.

Directly invoking the executable cuts out the middleman, and would always be preferred.

Uslackr's comment on your original question is correct as well, and he notes that the perl executable on the system path is invoked. You're best off to directly specify the executable you wish to run by a full path to avoid another executable from being accidentally invoked. This is good for both reliability and security. Portability is sacrificed, but you can choose your priorities.

Matthew Wetmore
  • 1,633
  • 12
  • 21
0

I marked Matthew's answer as correct as I share his sentiment how one should implement it. In reality we inherit systems we support and best case solution is not the one we have. Changing/improving it is another story.

Today we know that our issue was caused by bad Crowdstrike sensor. Basically this spyware is wreaking havoc on Windows. What's sad is that a) there is no trace in Windows Event Log b) there is no trace of the interference in Crowdstrike's own console.

Sadly vendor wants us to troubleshoot their own software issues and my bosses don't pay me to do it.

hdk
  • 13
  • 4