I frequently write .BAT and .CMD files onto which I can drop other files
from within Windows Explorer. For example, if I drop a file onto a batch
file that has the line
echo DLL is '%~s1'
then it echoes the full path to the file to the command-line window that
opens up.

When I do this with AntiSpyware Real Time Protection turned on, it asks me
if I want to allow the script to run. I say yes, but the parameters are not
passed to the script, i.e., it gets a null value for the path to the dropped
file (%~s1 is hosed). If I try again, the script is executed without asking
permission, but again, the parameters are lost.

If I turn off Real-Time Protection, the scripts run the way that I expect.
That is my workaround, but IMHO a script that is permitted to run with
Real-Time Protection turned on should receive all of the parameters that it
would receive with Real-Time Protection turned off.

There are several bugs relating to scripts. Another (and perhaps related to
what you are seeing) is that a script runs in the context of
Windows\System32, rather than the usual context (the location of the script
file, as I recall??)

There was a very nice Scripting Guys article on Microsoft's website about
this for a period of time, but it went away, and I didn't keep a copy of it.

My advice is to turn off the checkpoint that handles scripts if you do much
of this on a given machine--or just shut down Microsoft Antispyware, and
restart it afterwards.

--

"Arthur Eschenlauer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I frequently write .BAT and .CMD files onto which I can drop other files
>from within Windows Explorer. For example, if I drop a file onto a batch
>file that has the line
> echo DLL is '%~s1'
> then it echoes the full path to the file to the command-line window that
> opens up.
>
> When I do this with AntiSpyware Real Time Protection turned on, it asks me
> if I want to allow the script to run. I say yes, but the parameters are
> not passed to the script, i.e., it gets a null value for the path to the
> dropped file (%~s1 is hosed). If I try again, the script is executed
> without asking permission, but again, the parameters are lost.
>
> If I turn off Real-Time Protection, the scripts run the way that I expect.
> That is my workaround, but IMHO a script that is permitted to run with
> Real-Time Protection turned on should receive all of the parameters that
> it would receive with Real-Time Protection turned off.
>

I realized that I was pretty accepting of the fact that these bugs exist in
the product. The fact is, they've been there since January. I'm not sure
whether they've done any work to alleviate some of the issues--I suspect
not. The focus is on getting it all right in beta2.

So--I can say for sure that these issues won't be there in beta2--but I can
also say that it is unlikely that there will be any change in beta1
behaviors before then.

--

"Arthur Eschenlauer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I frequently write .BAT and .CMD files onto which I can drop other files
>from within Windows Explorer. For example, if I drop a file onto a batch
>file that has the line
> echo DLL is '%~s1'
> then it echoes the full path to the file to the command-line window that
> opens up.
>
> When I do this with AntiSpyware Real Time Protection turned on, it asks me
> if I want to allow the script to run. I say yes, but the parameters are
> not passed to the script, i.e., it gets a null value for the path to the
> dropped file (%~s1 is hosed). If I try again, the script is executed
> without asking permission, but again, the parameters are lost.
>
> If I turn off Real-Time Protection, the scripts run the way that I expect.
> That is my workaround, but IMHO a script that is permitted to run with
> Real-Time Protection turned on should receive all of the parameters that
> it would receive with Real-Time Protection turned off.
>