none
WshShell.Run does not launch lnk shortcuts

    Question

  • I have a big batch program (used by different customers on various Windows machines) that at some point starts another batch file in a different window by calling a lnk shortcut (it really needs to call a lnk as only this way it can get the necessary colors, size, and other properties for the window). The script launches the lnk file by calling this JScript file:

    var WshShell=WScript.CreateObject("WScript.Shell");
    WshShell.Run("\"c:\\some directory\\MyProg.lnk\"" , 1, false);

    That script is started from the main batch program through a START command (it could also be started using CScript.exe executable). I have tested it on different Windows machines available to me - from windows 2000 to Windows 7, but mostly on windows XP - and everything worked fine.

    Recently, I found that on some machines (Windows XP, Windows 7), the script does not work. It just silently runs and does not launch the shortcut; no error is displayed. I then tried to start another lnk file using this script - a standard shortcut from the Start Menu to launch Notepad - and that too does not work! This is the Notepad script:

    var WshShell = WScript.CreateObject("WScript.Shell");
    WshShell.Run("\"C:\\Documents and Settings\\bosh823\\Start Menu\\Programs\\Accessories\\notepad.lnk\"", 1, false);

    Starting the shortcut directly - by clicking on it in Explorer or running it from command line - works fine (a new Notepad window opens), but nothing happens when I run this script.

    I have a Windows XP machine now where the thing works, and another Windows XP where it does not. I have tried different things to make it work where it does not, but nothing helps.

    I know I am calling the right script and it executes.

    Misspelling the shortcut name in the script causes error messages when the script is run - obviously, the name iscorrect, and the script looks and finds the right file, just does not launch it.

    Doing the same using a similar VB script does not help - same issue.

    Running the script in debugger does not help - it just passes over the "WshShell.Run" line.

    I have compared everything that comes to my mind on the two machines - OS version, CScript.exe version, file permissions, relevant registry settings - everything is the same. Initially, on the machine where the script worked, Windows updates had not been applied for some time, and on the machine where it does not work, all recommended updates were applied. I thought that could be the reason for this difference, so I applied all recommended updates to the first machine and that
    did not help - the script still works there.

    I have searched the internet for similar cases and found just one or two similar complaints with no resolution.

    Any ideas why this is happening and how it can be fixed?

    Help will be greatly appreciated.
    Friday, October 28, 2011 9:34 PM

Answers

  • Sorry then,

    The problem would seem to lie elsewhere somehow with your configuration(s). You could try a short WSH script written in VBScript that does the same thing and see if that works. Other than that I don't have any other suggestions as I have never seen this problem; sorry.

    Bill

    Monday, October 31, 2011 4:47 PM
    Moderator

All replies

  • Hi,

    You should be saying

    new ActiveXObject("WScript.Shell");

    not

    WScript.CreateObject("WScript.Shell");

    I can't reproduce the problem.

    Bill

    Friday, October 28, 2011 9:48 PM
    Moderator
  • Hi,

    You should be saying

    new ActiveXObject("WScript.Shell");

    not

    WScript.CreateObject("WScript.Shell");

    I can't reproduce the problem.

    Bill

    Actually Microsoft documentation claims that both methods will work.

    The link issue is one where the link file is either damaged or it is in a location that cannot be executed.

    This can  happen due to some viruses and due to script blocking in AV software.

    Try creating a new link in a simple location like the root of C and try it.

     


    jv
    Friday, October 28, 2011 9:57 PM
  • Actually Microsoft documentation claims that both methods will work.

    Hi,

    They're subtly different as documented here: http://blogs.msdn.com/b/ericlippert/archive/2004/06/01/145686.aspx

    But in any case, the OPs comments would rule out problems like damaged lnk files or AV blocking.

    Bill

    Friday, October 28, 2011 10:21 PM
    Moderator
  • Actually Microsoft documentation claims that both methods will work.

    Hi,

    They're subtly different as documented here: http://blogs.msdn.com/b/ericlippert/archive/2004/06/01/145686.aspx

    But in any case, the OPs comments would rule out problems like damaged lnk files or AV blocking.

    Bill


    Not really.

    The first two new and basic create allow remotely conencting to a computer.  The WScript version allows an optional setting of the callabck moniker.   Other than that teh basic calls are all equal.  Look at the C API from which rthese are built and you will see they are just varaitions ain a wrapper for a CoComInitialize call.

    I agree that the problem is other but not that it is not AV.  I have seen both AV blocking do this with links that are cclicked and I have seen virusess that hook the code that launches a link cause links to fail.  I have not seen this exact failure mode.

    I am curious as to what is causing this most strange behavior.

     


    jv
    Friday, October 28, 2011 11:17 PM
  • The first two new and basic create allow remotely conencting to a computer.  The WScript version allows an optional setting of the callabck moniker.   Other than that teh basic calls are all equal.  Look at the C API from which rthese are built and you will see they are just varaitions ain a wrapper for a CoComInitialize call.

    Of course, that would assume there's no other "plumbing" going on when wrapping the API. I would recommend to the OP to try new ActiveXObject rather than WScript.CreateObject just to see if that makes a difference. If it still fails in exactly the same way, then I have no other suggestions.

    Bill

    Friday, October 28, 2011 11:26 PM
    Moderator
  • The first two new and basic create allow remotely conencting to a computer.  The WScript version allows an optional setting of the callabck moniker.   Other than that teh basic calls are all equal.  Look at the C API from which rthese are built and you will see they are just varaitions ain a wrapper for a CoComInitialize call.

    Of course, that would assume there's no other "plumbing" going on when wrapping the API. I would recommend to the OP to try new ActiveXObject rather than WScript.CreateObject just to see if that makes a difference. If it still fails in exactly the same way, then I have no other suggestions.

    Bill


    It's worth a try but I have a veruy large amount of experince with all of thisoe calls and ther should be no issue like this.  Still - it's worth a try.

     


    jv
    Friday, October 28, 2011 11:28 PM
  • I found the problem.   It is even better.  Look for a link to notepad in the start menu folder?


    jv

    • Edited by jrv Friday, October 28, 2011 11:34 PM
    Friday, October 28, 2011 11:31 PM
  • Any normal link file works. Some system smay have a link to notepad in teh star tmenu. Most don't. Look at the start menu and you will see notepad displayed very prominantly and clicking on it will start notepad.  Calling it as a link file will not work.

    Why? 

     


    jv
    Friday, October 28, 2011 11:45 PM
  • I had tested both new ActiveXObject("WScript.Shell") and WScript.CreateObject("WScript.Shell") even before submitting the original post - should've mentioned this - and they both work (or do not work) identically.

    As for Antivirus software, one XP machine where shortcuts won't start runs Symantec Endpoint Protection, the other - McAfee; some machines where shortcuts would start also run Symantec.

    Sorry, I do not understand the last two messages from jrv - do you imply that the problem is with the Notepad link? I have tried moving the link to other locations, other links - no change. Remember, I started playing with Notepad and other links only after I got desperate with my own link (for a batch file) suddenly not working on some machines.

    Monday, October 31, 2011 4:35 PM
  • Sorry then,

    The problem would seem to lie elsewhere somehow with your configuration(s). You could try a short WSH script written in VBScript that does the same thing and see if that works. Other than that I don't have any other suggestions as I have never seen this problem; sorry.

    Bill

    Monday, October 31, 2011 4:47 PM
    Moderator
  • I've found that UNC paths, if you are using any, tend to go wrong on batch files. So I tend to map a spare drive letter (A, Z, etc) to the folder I need to get to, run it that way, then disconnect (all automatically, of course). I also tend NOT to use lnk files. Since they are shortcut files I tend to use the EXE and commands that are required instead of poing to LNK files. About quotes: always got dicey with me. I usually set a variable to the ASCII quotes character and use that to enclose variables. Makes for some easier code to read and ensures that the command line interprets the quote characters properly. Example: Set Q = CHR(34) WScript.Run(Q & "a:\somefolder\somefile.exe -option1 " & strVariable & " -option2" & Q) OUTPUT: "a:\somefolder\somefile.exe -option1 somevariable -option2"
    Tuesday, November 01, 2011 6:51 PM
  • I've found that UNC paths, if you are using any, tend to go wrong on batch files.

    UNC paths work perfectly well in batch files when used properly, with some well-documented exceptions, e.g. this one:

    C:\>cd "\\PC2\drived\my documents
    '\\PC2\drived\my documents'
    CMD does not support UNC paths as current directories.

    People often think that UNC paths fail in scheduled jobs where the problem is usually insufficient access. However, if you have a batch file to demonstrates how a UNC path fails then I'd love to see it.

    Tuesday, November 01, 2011 7:03 PM