I'm trying to run a .vbs script under 64Bit. When I run this script manually it will execute properly, but when launched by something else, it will run under 32bit and won't execute properly.

Here's my script:

Set WshShell = CreateObject("WScript.Shell") 
WshShell.Run Chr(34) & "C:\Users\Chris Nicol\Documents\SlickRun Scripts\Zune\RunZune.bat" & Chr(34), 0
Set WshShell = Nothing

Basically I want to force the use of C:\windows\syswow64\cmd.exe, so that it will run correctly. I can't seem to get the syntax right and can't find help on this.

Here's the batch file and regedit file that I'm trying to execute:



regedit /s FeaturesOverride.reg
"C:\Program Files\Zune\Zune.exe"



Windows Registry Editor Version 5.00

  • 1
    The wscript in syswow64 is going to be the 32-bit version of wscript. The 64-bit version is in windows/system32. I don't see why it would make a difference for this script though. Are you sure the "something else" that's executing it has permission to access the user folder? Are there any error messages when it fails to work? Jul 25, 2011 at 21:44
  • Well it's not really that it fails, and it may be a permissions issue. The .bat that I'm running is running a .reg file to modify the registry before running zune.exe When I run the .vbs by double clicking it, everything works as expected, but launching it through SlickRun will not modify the registry, but will also not cause an error. Jul 25, 2011 at 21:46
  • I've update the question to include all the files I'm trying to execute Jul 25, 2011 at 21:52
  • Perhaps close SlickRun, find the SlickRun.exe file and set it's compatibility to "run as an administrator", then try it again as this should help avoid permissions problems. Jul 25, 2011 at 22:01
  • SlickRun has an option for "Run As Administrator" and I've selected that. I've talked to the developer behind SlickRun and he feels it's probably more of a 64bit issue. His suggestion hasn't worked (run the script through a 64bit version of WScript). However, I'm trying to see if I can run the .bat in 64bit to see if that works Jul 25, 2011 at 22:05

1 Answer 1


The following code will check if the system is 64Bit and in this case close the script and rerun it forcing the 64Bit Host by calling it directly with the script as parameter.

If fso.FileExists("C:\Windows\SysWOW64\wscript.exe") Then
    If InStr(1, WScript.FullName, "SysWOW64", vbTextCompare) <> 0 Then ' = very basic 64bit check replace if you want a more sophisticated one
        newFullName = Replace(WScript.FullName, "SysWOW64", "Sysnative", 1, -1, vbTextCompare) ' System32 will be replaced by Sysnative. calls to sysnative bypass WoW64 emulation, cscript or wscript stays the same as they were
        newArguments = "" ' all arguments are given to the new script call
        For Each arg In WScript.Arguments
            newArguments = newArguments & arg & " "
        wso.Run newFullName & " """ & WScript.ScriptFullName & """ " & newArguments, , False
        WScript.Quit ' Close 32Bit scripting host
    End If
End If

This workaround ensures that the script is run in 64Bit no matter who calls it. If you have a situation where you can control the call (e.g. the script is only ever called via a specific link) you can probably just use the basic principle (which is the sysnative file system redirector) directly in your shortcut.

  • SysWOW64 is 32-bit folder. System32 is the 64-bit version
    – phuclv
    May 10, 2017 at 8:29
  • Yes, and what this does is check if syswow64 wscript.exe exists (very dirty check for 64bit system) and then replaces the name syswow64 with sysnative. While system32 is the 64bit version for a 64bit process this is not true for a 32bit process. a 32bit process would get redirected so that system32 would end up being syswow64 anyway. Sysnative is the way to tell a 32bit process to go to system32
    – Syberdoor
    May 10, 2017 at 9:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .