wshshell.run a shortcut and waiting for it to finish. How ?

[R.Wieser]

Hello all,

I'm trying to run a program or script thru a shortcut and wait for it to
finish (this last bit is crucial). However, I get an "WshShell.Run: Unable
to wait for process." error.

My question therefore is : How do I run a shortcut and wait for its target
to finish ? Is there a better-suited command available perhaps ?

Targetted OS: XPsp3.

... just thought of something: extracting the target (and possibly
arguments) from the shortcut myself. Do I really have to do that ?

Regards,
Rudy Wieser

P.s.
Remarkable how few results you get googeling or DDG-ing for the above error
message including the doublequotes followed by the word "shortcut". Or how
few results, let alone relevant ones, you get when searching for just the
error message ...

[JJ]

On Sun, 15 Nov 2020 09:14:47 +0100, R.Wieser wrote:
> Hello all,
>
> I'm trying to run a program or script thru a shortcut and wait for it to
> finish (this last bit is crucial). However, I get an "WshShell.Run: Unable
> to wait for process." error.
>
> My question therefore is : How do I run a shortcut and wait for its target
> to finish ? Is there a better-suited command available perhaps ?
>
> Targetted OS: XPsp3.
>

> .... just thought of something: extracting the target (and possibly

> arguments) from the shortcut myself. Do I really have to do that ?
>
> Regards,
> Rudy Wieser
>
> P.s.
> Remarkable how few results you get googeling or DDG-ing for the above error
> message including the doublequotes followed by the word "shortcut". Or how
> few results, let alone relevant ones, you get when searching for just the
> error message ...

IME, that problem can occur when `WshShell.Run()` ends up delegating the new
process creation to an already existing process. It depends on whatever
program is associated with the file being linked/referenced (i.e. the final
resolve of the file association). It may be the desktop process, or a local
COM server process.

This kind of problem shouldn't occur for simple file associations such as
TXT, BAT, EXE, VBS, etc.

[R.Wieser]

JJ,

> IME, that problem can occur when `WshShell.Run()` ends up
> delegating the new process creation to an already existing process.

hmmm... I assumed that it could be a case of a process being started which
than starts another one. The first one is monitored but returns directly,
which is detected and causes the error to be displayed.

As for being delegated to an already existing process ? 1) I only get the
error when starting those scripts thru a shortcut, 2) I have started a
script (a simple "hello" box) thru a shortcut trice, and can see three
"wscript.exe" processes running in the task manager.

> This kind of problem shouldn't occur for simple file associations
> such as TXT, BAT, EXE, VBS, etc.

Indeed they do. But as I'm using shortcuts as intended I expected them to
work too.

Regards,
Rudy Wieser

[JJ]

On Mon, 16 Nov 2020 17:10:38 +0100, R.Wieser wrote:
>
> Indeed they do. But as I'm using shortcuts as intended I expected them to
> work too.
>
> Regards,
> Rudy Wieser

Perhaps a ShellExecuteHook shell extension is interfering.

[R.Wieser]

JJ,

> Perhaps a ShellExecuteHook shell extension is interfering.

I do not remember having installed anything like it.

Is there any way I can check if, and if so which hooks are present ?

Also, should they than not becausing problems outside of VBScript too ?

Regards,
Rudy Wieser

[Mayayana]

"R.Wieser" <add...@not.available> wrote

Why don't you just go direct? If I had to guess I'd say the LNK
probably calls Explorer to do the job, in which case
Explorer would return immediately. By running the EXE,
wscript would be cutting out that middleman. I'm not
certain about that, but I don't see any sense going
indirect in the first place.

[R.Wieser]

Mayayana,

> Why don't you just go direct?

I did. I now check for a .lnk extension and if its there extract the
target from the shortcut and than run that. It works.

> If I had to guess I'd say the LNK probably calls Explorer to
> do the job, in which case Explorer would return immediately.

I don't know what gets called to handle the shortcut (User32.dll has got
several "ShellExecute" functions available), but I assumed something like
the last part, yes.

> I'm not certain about that, but I don't see any sense going
> indirect in the first place.

Somethimes a shortcut is needed to be able to provide arguments to a program
that you want to have run (on startup or winddown).

Regards,
Rudy Wieser

[JJ]

On Wed, 18 Nov 2020 14:37:12 +0100, R.Wieser wrote:
> Also, should they than not becausing problems outside of VBScript too ?

You're right. That leaves out ShellExecuteHook from being the culprit.

Could you provide the exact detail on how the file is executed and what
files are involved? i.e. the shortcut file, and the file/program being
referenced by it. I want to reproduce the problem in my system.

[R.Wieser]

JJ,

> Could you provide the exact detail on how the file is executed
> and what files are involved?

At some point I created a test script containing the below :

- - - -
set oSH = CreateObject("wscript.shell")
call oSH.Run(""""& "hello.vbs.lnk" &"""",1,true)
- - - -

the "hello.vbs.lnk" is ofcourse a shortcut file which target is a simple
"hello.vbs" script (duh :-) ) which contains nothing more than

- - - -
msgbox "hello world!"
- - - -

Later I changed the target of that shortcut to a simple GUI executable, but
that didn't stop the error from occuring

> I want to reproduce the problem in my system.

In the other thread in

microsoft.public.windowsxp.general
Re: How to add a "Shutdown" folder (the opposite of the "startup" folder) ?

I just mentioned that I tested the ShellExecuteEx function with the
SEE_MASK_NOCLOSEPROCESS flag, and it does give the same results : When a
shortcut is provided (regardless of its target) the process field does not
get filled in. No error occurs though (even though GetLastError does seem
to hold a usable error value ...)

Regards,
Rudy Wieser

[JJ]

My conclusion is that it's due to a bug in Windows.

It is based on below WSH test results in VMs and my main Win7 system, and
based on your information that it fails even when without using WSH.

VMs:
Windows XP [NT5.1] SP3 (WSH 5.7) = fail
Windows 2003 [NT5.2] SP2 (WSH 5.6) = fail
Windows Vista [NT6.0] Gold/no-SP (WSH 5.7) = success

Host system:
Windows 7 [NT6.1] (WSH 5.8) = success

[R.Wieser]

JJ,

> My conclusion is that it's due to a bug in Windows.

Bug, oversight, a "fringe case" that was not tested, almost the same thing,
right ? :-)

Thanks for testing and reporting back though. Nice to know that I didn't
overlook something.

Regards,
Rudy Wieser