Why this script does not work at startup unless i execute it with double click ?

[tonycst]

I have this script that (when ran at least once) adds its self to registry so it would run at start up.

When it runs after computer restarts, it does not complete its task.

It completes the task only when i run it manually (double clicking the executable)

 

Task is very simple: Delete previous network drive and assign a new one.
This script was made because windows 7 does not connect to network drive at start up no matter what i try so i needed a script to take care of the problem.

It works like a charm only when i manually lunch it, but fails on second command when it runs by its self after restart.

Here is the code:

Thanks !

expandcollapse popup

#RequireAdmin
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Icon=Devcom-Network-Wifi-modem-Vista.ico
#AutoIt3Wrapper_Outfile=Network Drive Startup.exe
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
#include <GUIConstantsEx.au3>
$Address = FileReadLine ("Address.txt",1)
If $Address = "" Then
    FileDelete ("Address.txt")
    FileWrite ("Address.txt","192.168.1.1" & @CRLF & "Avobe address is used to connect to network drive")
    MsgBox (16,"Error","No valid address was found." & @CRLF & "New Address.txt file was written. Please edit it for correct address and restart this application.")
    Exit
EndIf
$Gui = GUICreate ("Network Drive Startup",200,100)
$TimeoutInput = GUICtrlCreateInput ("3000",10,20,190,20)
$AddressInput = GUICtrlCreateInput ($Address,10,40,190,20)
GUISetState (@SW_SHOW)
Sleep (GUICtrlRead ($TimeoutInput))
$Start = TimerInit()
While 1
    $msg = GUIGetMsg()
    If $msg = $GUI_EVENT_CLOSE Then Exit
    $Timeout = GUICtrlRead ($TimeoutInput)
    $AddresstoPing = "192.168.1.1"
    $Difference = TimerDiff($Start)
    If $Difference > $Timeout then Exit
    $Ping = Ping ($AddresstoPing)
    If $Ping > 0 Then
        _Connect()
    EndIf
WEnd
Func _Connect()
    RunWait('"' & @ComSpec & '" /C NET USE N: /DELETE', '', @SW_SHOW)
    ;RunWait('"' & @ComSpec & '" /C NET USE N: \\192.168.1.1\N-Network /user:owner password', '', @SW_SHOW)
    RunWait('"' & @ComSpec & '" /K NET USE N: ' & $Address, '', @SW_SHOW)
    RegWrite ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run","Network Drive StartUp","REG_SZ",@ScriptFullPath)
    Exit
EndFunc

 

[mLipok]

You should wait for all other services and intefaces should be successfuly started.

 

[tonycst]

Increasing delay does not help. I went as much as 10 seconds.

How ever, i traced the problem with execution level or what you call it.

Its not the first script i make that does not work the same when it starts by its self.

Autoit has a problem with permissions or execution or something like that. Otherwise why it works with double click and does not work when its added to start up ? I cant find another explanation.

#requireadmin does not help.

Changing execution level does not help. Something is wrong with autoit at the execution and it needs to be fixed.
I confirm that its autoit issue by placing the shortcut to complied executable into startup folder instead of registry.
Script executed and everything worked well.

 

I am getting very tired of execution issues with autoit.

[mLipok]

Try task sheduler, run after User login.

[JohnOne]

  On 3/14/2016 at 6:37 AM, tonycst said:

I confirm that its autoit issue by placing the shortcut to complied executable into startup folder instead of registry.
Script executed and everything worked well.

Expand  

How exactly does that confirm an AutoIt issue?

[tonycst]

Very eazy.

Script executes a CMD.exe

When autoit executed via double click passes arguments to CMD, CMD executes the command as it should.

When autoit executed at start up via registry key (Run. Regardless if Local Machine or Current User or administrator account or not) it passes arguments to CMD and CMD fails to execute it.

When autoit executed at start up via shortcut located in StartUp folder (instead of registry) arguments passed down to CMD executed and everything works.

 

My script is simple:
RunWait('"' & @ComSpec & '" /C NET USE N: /DELETE', '', @SW_SHOW)
RunWait('"' & @ComSpec & '" /C NET USE N: ' & $Address, '', @SW_SHOW)

Thats it.
There is nothing to fail except one thing. Autoit does not pass arguments to CMD as it should. Or rather it passes them down WRONG or in a screwed up level of permissions or execution lever etc (not sure which one to blame)

 

All i know is that this is common issue on many of my scripts that run at start up. They simply dont work.

Some of my scripts fail to export registry keys unless i run then with double click instead of start up via registry link, some fail to read etc.
Some of my scripts that run at startup via registry do not work right, but they work fine when i execute them with double click.
This tells me that executing application with double click is not the same as executing it (lets say) via command line or tell Windows to execute it when it logs in.

Something clearly is wrong with autot because i dont see any other explanation.

 

EDIT:

To add more details on this issue, i think that when arguments passed down to regedit or CMD (or what ever it may be) at start up, autoit does not know where it is.
I can trace it by looking at the error that either regedit or CMD shows. It mostly complains about "not found" or "unknown" etc all related to the regedit or CMD unable to locate the file which needs to be executed as per arguments inside autoit script.

For example:

$RegFile = '"' & @ScriptDir & '\ALOptions.reg"'
$RegKey = '"HKEY_CURRENT_USER\Software\Advanced Launcher"' ;Quoted already
Autoit says: RunWait(@WindowsDir & "\regedit.exe /S " & $RegFile)

Pretty simple right ? WRONG. This will not work properly if this script ran at start up defined in registry.
Regedit will not know where the file is and give you errors.
I tried addind #requireadmin etc but it would work on Windows 7 but not on windows 10 and the other way around.

So i think that its a path related issue in some cases, but in my case above its much worse because my network related arguments have no path in them (with the exception to specify what path to assign, is exactly where it fails)

 

Edited March 14, 2016 by tonycst

[tonycst]

  On 3/14/2016 at 7:24 AM, mLipok said:

Try task sheduler, run after User login.

Expand  

Dont want to try anything but a basic registry trick.

The problem with autoit execution. Some of my scripts dont read or export registry keys when they are started at logon via registry. This problem is very old and it drives me nuts.

[Juvigy]

Instead of RunWait - have you tried Shellexecute ?

[JohnOne]

  On 3/14/2016 at 8:52 AM, tonycst said:

related to the regedit or CMD unable to locate the file which needs to be executed as per arguments inside autoit script.

Expand  

That would indicate a windows component problem to me, one which you would need to code around.

[ViciousXUSMC]

You could just use a .bat file for this, adding Autoit to the mix is sort of a moot point if all you're doing is CMD stuff. 

If you think this is permissions related try adding #RequireAdmin to your script, also have you tried PERSISTENT: YES that is the flag to make a drive stay between reboots and such.

[tonycst]

  On 3/14/2016 at 9:48 AM, JohnOne said:

That would indicate a windows component problem to me, one which you would need to code around.

Expand  

It worked like a charm couple of years ago. Its recent autoit changes that prevent it from working.

I have not updated windows 7 SP1 in long time and codes like this worked but not anymore (since who knows when, i dont keep track)

  On 3/14/2016 at 11:14 AM, ViciousXUSMC said:

You could just use a .bat file for this, adding Autoit to the mix is sort of a moot point if all you're doing is CMD stuff. 

If you think this is permissions related try adding #RequireAdmin to your script, also have you tried PERSISTENT: YES that is the flag to make a drive stay between reboots and such.

Expand  

I said #RequireAdmin does not help.
In fact, adding #RequireAdmin screws everything up if user is not hidden administrator but a standard user with admin rights, or the other way around (not sure)

I try to keep script as simple as i can. Dont want to generate files and run them.
Plus why do you think it will work any different ? Passing over execution permissiosn from Windows to autoit script is already a problem in my case, and on top of that it will screw up passing them even down to a .bat which passes it down to the actual executable such as regedit or CMD.

Thats too many hoops to jump VS go directly to the executable and pass just the arguments.

[spudw2k]

Does the GUi launch for the user at least, but the NET USE command(s) fail...or just the GUI never show?

Edited March 14, 2016 by spudw2k

[Juvigy]

Have you tried Shellexecute or not ?

[rudi]

You are not really answering the questions people asked you, to be able to help you.

 

Well, I can confirm, that it's *NOT* an autoit issue. For a customer I used an Autoit Script placed in startupcommondir for exatly the same purpose with no issues at all.

 

expandcollapse popup

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Outfile=\\10.27.1.51\nw06data1\bat\mapdrives-ip.exe
#AutoIt3Wrapper_Compression=3
#AutoIt3Wrapper_Res_Fileversion=2.0.1.1
#AutoIt3Wrapper_Res_Fileversion_AutoIncrement=y
#AutoIt3Wrapper_Res_SaveSource=y
#AutoIt3Wrapper_Res_Language=1031
#AutoIt3Wrapper_Res_requestedExecutionLevel=asInvoker
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

If $cmdline[0] = 1 And StringInStr($cmdline[1], "debug") Then
    $debug = True
Else
    $debug = False
EndIf


$ResTxt = "Ergebnis der Aktionen: " & @CRLF & "---------------------" & @CRLF

Dim $aMap[4][2] = [[3], _
        ["h:", "\\10.27.1.51\nw06data1"], _
        ["u:", "\\10.27.1.51\userhomevol\userhome"], _
        ["z:", "\\10.27.1.51\nw06data1\bat"]]

For $i = 1 To $aMap[0][0]
    $ResTxt &= @CRLF
    $type = DriveGetType($aMap[$i][0])
    $ResTxt &= "Vorgesehene Zuordnung: " & $aMap[$i][0] & "=" & $aMap[$i][1] & @CRLF
    $ResTxt &= @TAB & $aMap[$i][0] & ", DriveType = '" & $type & "'" & @CRLF
    if $debug then tooltip($ResTxt, 20, 20, "Map Drives")
    If $type = "network" Then
        $MyCmd = "net use " & $aMap[$i][0] & " /del /y" ; /y erzwingt die Trennung auch bei aktiv genutzem Mapping
        $ResTxt &= @TAB & $MyCmd & @CRLF
        if $debug then tooltip($ResTxt,20, 20, "Map Drives")
    $result = RunWait($MyCmd, @TempDir, @SW_HIDE)
        $ResTxt &= @TAB & "ExitCode Trennen Netzlaufwerk = " & $result & " (" & $MyCmd & ")" & @CRLF
        if $debug then tooltip($ResTxt,20, 20, "Map Drives")
    EndIf
    $type = DriveGetType($aMap[$i][0])
    If $type = "" Then
        $MyCmd = "net use " & $aMap[$i][0] & " " & $aMap[$i][1]
        $result = RunWait($MyCmd, @TempDir, @SW_HIDE)
        If $result Then
            MsgBox(48, "Fehler", "Konnte Mapping nicht abschließen:" & @CRLF & _
                    $MyCmd & @CRLF & _
                    "Fehlercode = " & $result)
            $ResTxt &= "Error " & $result & ", Befehl: " & $MyCmd & @CRLF
            if $debug then tooltip($ResTxt,20, 20, "Map Drives")
        Else
            $ResTxt &= "Mapping OK (" & $MyCmd & ")" & @CRLF
            if $debug then tooltip($ResTxt,20, 20, "Map Drives")
        EndIf
    Else
        MsgBox(48, "Fehler", "Der Laufwerksbuchstabe ist nicht frei für " & $aMap[$i][0] & @CRLF & _
                "DriveType=" & $type)
        $ResTxt &= "Type = " & $type & " für Laufwerk " & $aMap[$i][0] & ", Laufwerksbuchstabe ist also *NICHT* verfügbar!" & @CRLF
        if $debug then tooltip($ResTxt,20, 20, "Map Drives")
    EndIf
Next

If $debug Then
    Tooltip("")
    MsgBox(0, "MapDrives.exe Ergebnis", $ResTxt)
    ClipPut($ResTxt)
EndIf

Please use google translate yourself to get the German strings translated. ;-)

 

Regards, Rudi.

[pixelit]

I can't help too much, but once I had the same problem and I solve it throught the "easy way". Creating a vbs script which launch the program:

 

Set UAC = CreateObject("Shell.Application")  
UAC.ShellExecute "c:\path\to\you\script.exe", "", "", "runas", 1

To be honest I have no idea of what caused the problem or what does exactly this vbscript, it seems that it runs the .exe as admin.

[AdamUL]

Have a look at this thread.  It should help you out.  

 

@pixelit the code that you have, can be done with AutoIt native functions.  This will cause the script to re-execute itself to request the Admin Token, if it does not have it.  

If Not IsAdmin() Then ShellExecute(@ScriptFullPath, "", "", "runas")

 

Adam

 

[tonycst]

  On 3/14/2016 at 8:09 PM, spudw2k said:

Does the GUi launch for the user at least, but the NET USE command(s) fail...or just the GUI never show?

Expand  

GUI has little to nothing to do with the script. It shows and servers as a visual reference for the delay and address.
Command is executed both time correctly, it just does not work when its executed by adding it to the registry. It only works when its executed by a shortcut placed into start menu under startup folder.

  On 3/15/2016 at 1:02 PM, rudi said:

Well, I can confirm, that it's *NOT* an autoit issue. For a customer I used an Autoit Script placed in startupcommondir.........................

 

Expand  

startupcommondir ? BINGO !!!!!!!!!!!!!!!!!!!!!

Now try to make your script run from HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run at startup instead.

  On 3/15/2016 at 8:07 AM, Juvigy said:

Have you tried Shellexecute or not ?

Expand  

I dont want to try shellexecute, i have not tried in in years and it worked just fine.
Like i said, windows is not updated in years, only autoit was updated.
I restore windows to original state often and i have this script on more then one computer and both have same issue.

[Juvigy]

You updated autoit - some things have changed. So either you go back to the prev. version of Autoit you were using, or you change the code a little bit. Choose wisely.

[spudw2k]

  On 3/16/2016 at 6:35 AM, tonycst said:

GUI has little to nothing to do with the script. It shows and servers as a visual reference for the delay and address.

Expand  

Yea..I got that part.

  On 3/16/2016 at 6:35 AM, tonycst said:

Command is executed both time correctly, it just does not work when its executed by adding it to the registry.

Expand  

What do you mean by "both time correctly"?  Sounds like the GUI does in fact show and the NET USE command runs but fails?  What is the error message is displayed on the CMD /k window?

[tonycst]

  On 3/16/2016 at 4:30 PM, spudw2k said:

Yea..I got that part.

What do you mean by "both time correctly"?  Sounds like the GUI does in fact show and the NET USE command runs but fails?  What is the error message is displayed on the CMD /k window?

Expand  

I mean that NET.exe gets executed as it should. But when script is defined in registry to run at start up, net command returns error 67 (i looked it up) which means absolutely nothing wrong with the arguments, its the level at which the arguments are being passed down is the problem.

 

Here is another example that i HOPE will clear things out.

Run script at start up by placing shortcut in Start menu/All Programs/Startup folder.

Computer starts. Batman logs in. Script starts. Autoit speaks to the CMD.exe and says "I am the Batman" and here are my arguments.
CMD says "OK, i know who you are" and tells NET.exe  "Batman says... do this and that". Net.exe says "Oh, ok. DONE !"

Run script at start up be defining a registry key under "run"

Computer starts. Batman logs in. Script starts. Autoit speaks to the CMD.exe and says "I am the User with rights" and here are my arguments.
CMD says "OK, i dont know who you are but i see you have rights so i will pass your word down" and tells NET.exe  "Some jerk with rights says... do this and that". Net.exe says "I will execute the command but it will fail because windows components i modify dont care if you have rights or not, they want you to be a known user"

 

So in the end, in both cases command is executed as intended, but only in one case executed command actually work.

 

Perhaps i should try to talk to net.exe directly and not thru CMD ?