Script doesn't quit on Windows 7
in [VbScript]
|
Prev: vb script to retrieve DNS records, identify hostname and ip duplic
Next: Return top level folder list and respective sizes from current fol
From: Saucer Man on 6 Jul 2010 10:33 I have a .vbs script that maps drives and network printers. The script lives on the network. I script is not quitting on Windows 7. It works fine on XP and Vista. I can tell this because it writes a log file to the root of C:/. After it has run, I try to modify the log file and save it but I get an access denied error. The last lines of the script are... writelog "################ End Login Script ###################" Set objNetwork = Nothing Set objDrives = Nothing Set objComputer = Nothing Set objShell = Nothing Set objFileSystem = Nothing Set objLogFile = Nothing 'Msgbox "Logon Script Complete",,"Mapper" WScript.Quit -- Thanks!
From: Pegasus [MVP] on 6 Jul 2010 10:45 "Saucer Man" <saucerman(a)nospam.com> wrote in message news:4c333e54$0$2394$cc2e38e6(a)news.uslec.net... > I have a .vbs script that maps drives and network printers. The script > lives on the network. I script is not quitting on Windows 7. It works > fine on XP and Vista. I can tell this because it writes a log file to the > root of C:/. After it has run, I try to modify the log file and save it > but I get an access denied error. > > The last lines of the script are... > > writelog "################ End Login Script ###################" > > Set objNetwork = Nothing > Set objDrives = Nothing > Set objComputer = Nothing > Set objShell = Nothing > Set objFileSystem = Nothing > Set objLogFile = Nothing > 'Msgbox "Logon Script Complete",,"Mapper" > WScript.Quit > > -- > Thanks! The lines you quote after "writelog" are fine but none of them will alter the behaviour of your script in any way. You could omit the whole lot. After the interpreter has executed the WriteLog subroutine it will disassociate the various variables from their objects and terminate the script, even without the "nothing" and "quit" keywords. The problem therefire lies in your WriteLog subroutine. What does it look like?
From: Tom Lavedas on 6 Jul 2010 11:01 On Jul 6, 10:45 am, "Pegasus [MVP]" <n...(a)microsoft.com> wrote: > "Saucer Man" <saucer...(a)nospam.com> wrote in message > > news:4c333e54$0$2394$cc2e38e6(a)news.uslec.net... > > > > > I have a .vbs script that maps drives and network printers. The script > > lives on the network. I script is not quitting on Windows 7. It works > > fine on XP and Vista. I can tell this because it writes a log file to the > > root of C:/. After it has run, I try to modify the log file and save it > > but I get an access denied error. > > > The last lines of the script are... > > > writelog "################ End Login Script ###################" > > > Set objNetwork = Nothing > > Set objDrives = Nothing > > Set objComputer = Nothing > > Set objShell = Nothing > > Set objFileSystem = Nothing > > Set objLogFile = Nothing > > 'Msgbox "Logon Script Complete",,"Mapper" > > WScript.Quit > > > -- > > Thanks! > > The lines you quote after "writelog" are fine but none of them will alter > the behaviour of your script in any way. You could omit the whole lot. After > the interpreter has executed the WriteLog subroutine it will disassociate > the various variables from their objects and terminate the script, even > without the "nothing" and "quit" keywords. The problem therefire lies in > your WriteLog subroutine. What does it look like? In addition to what you have rightly said, I have one small observation. That is that setting the objLogFile to Nothing is NOT the same as closing the file. Having said that, I have never noticed a file remaining locked after a script operation, whether any specific CLOSE operation was executed or not in the OS versions I have used. I don't have access to a Win 7 equipped machine so I can't check, but it's certainly easy enough to add a objLogfile.close line right before it is set to Nothing. It may be that this is needed in the Win 7 version of WSH. _____________________ Tom Lavedas
From: Saucer Man on 6 Jul 2010 11:21 > The lines you quote after "writelog" are fine but none of them will alter > the behaviour of your script in any way. You could omit the whole lot. > After the interpreter has executed the WriteLog subroutine it will > disassociate the various variables from their objects and terminate the > script, even without the "nothing" and "quit" keywords. The problem > therefire lies in your WriteLog subroutine. What does it look like? Thank you both for your input. The script I am using is this one... http://www.anonymoos.com/scripting/logonscript.txt
From: Pegasus [MVP] on 6 Jul 2010 16:20
"Saucer Man" <saucerman(a)nospam.com> wrote in message news:4c33499e$0$2407$cc2e38e6(a)news.uslec.net... >> The lines you quote after "writelog" are fine but none of them will alter >> the behaviour of your script in any way. You could omit the whole lot. >> After the interpreter has executed the WriteLog subroutine it will >> disassociate the various variables from their objects and terminate the >> script, even without the "nothing" and "quit" keywords. The problem >> therefire lies in your WriteLog subroutine. What does it look like? > > Thank you both for your input. The script I am using is this one... > > http://www.anonymoos.com/scripting/logonscript.txt I don't really have the time to work my way through your 350 lines of code. Suffice it to say that the WriteLog subroutine looks suspicious: sub WriteLog(sEntry) if bolWriteLog then objLogFile.WriteLine(Now() & ": Log: " & sEntry) End Sub I would modify it like so: sub WriteLog(sEntry) wscript.echo "Label 1", sEntry if bolWriteLog then objLogFile.WriteLine(Now() & ": Log: " & sEntry) objLogFile.close wscript.echo "Label 2" End Sub I also have serious concerns about the widespread use of "On error resume next" statements. This is a highly effective means of covering up errors in the script and it can make debugging a real chore. I wouldn't be surprised if the error occurs in one of the blocks of code that is covered by an "On error" statement. Use them very, very sparingly and only for those lines of code where they are relevant, never for whole functions. |