QA - problems running WScript.Shell on 64bit Windows

Question:

Hi,

I'm having trouble running a bat file from an ASP page. It works fine on Windows 2003 Std x32 server but fails now we have upgraded to the x64 edition

In the ASP we are trying to run the following

Set oWSH= Server.CreateObject("WScript.Shell")

errmsg = oWSH.Run("d:\\scripts\\copyiissettings.bat 10.0.0.156",0,True)

set oWSH = nothing

The errmsg is returning 1 (not very helpful)

In the BAT file we are running the following command: cscript.exe c:\windows\System32\iiscnfg.vbs /copy /ts %1 /tu machineusername /tp machinepassword

I am sure the permissions are setup correctly in IIS as both the Application Pool and Authenticated Anonymous User are set as the Administrator. We are also running IIS with he following flag enabled Enable32BitAppOnWin64=True

I can only think maybe there is a problem being related to the fact we are running x64 and perhaps there is a registry setting or group policy setting i need to change?

Thanks,

i figured it out.

problem is that when you call the bat from the ASP it runs as a 32 bit process and runs the cscript.exe from the SYSWOW64 directory and this fails. i copied the cscript.exe from the System32 into the SYSWOW64 directory and this fixed the problem. hopefully this wont cause another problem somewhere else?!

Answer:

Yes, your resulution is one way to address your specific issue, but in general I prefer to modify/manipulate system files only after understanding what is going on and the full ramifications of the change.

Because you configured Enable32bitAppOnWin64=1, WOW64 interactions came into play and complicated matters. Here is what is going on:

1. When you configure Enable32bitAppOnWin64=1 in IIS6, it makes IIS launch 32bit worker process (w3wp.exe) to handle requests. You see it as w3wp.exe*32 with 64bit Task Manager
   
2. The 32bit worker process reads configuration and determines that .ASP is handled by C:\windows\System32\ASP.DLL and attempts to load that DLL
   
3. WOW64 subsystem on 64bit Windows triggers when a 32bit process attempt to reach C:\windows\System32 and transparently redirects it to C:\windows\SYSWOW64. So, C:\windows\SYSWOW64\ASP.DLL (32bit DLL installed by IIS6 on 64bit Windows) is loaded by the worker process
   
4. 32bit ASP DLL parses the ASP page and looks up ProgId for WScript.Shell in the registry. The Registry also transparently redirects access to Registry by 32bit process to the appropriate Wow6432Node inside the Registry. End result is that the 32bit OCX implementing WScript.Shell eventually gets located and loaded
   
5. oWSH.Run( "d:\\scripts\\copyiissettings.bat 10.0.0.156" ) eventually translates into a CreateProcess() Win32 API call made by the 32bit worker process. The .BAT extension is looked up to be processed by C:\windows\System32\CMD.EXE , but will get redirected by WOW64 to C:\windows\SYSWOW64\CMD.EXE (32bit) in the same way as ASP.DLL earlier
   
6. 32bit CMD.EXE eventually encounters the CSCRIPT.EXE statement, and after a path lookup and WOW64 redirection, it will run C:\windows\SYSWOW64\CSCRIPT.EXE (32bit) to process c:\windows\System32\iiscnfg.vbs
   
7. When 32bit CSCRIPT.EXE tries to load c:\windows\System32\iiscnfg.vbs , WOW64 will redirect it to c:\windows\SYSWOW64\iiscnfg.vbs - which does not exist - and the execution fails with a file-not-found
   

Based on the above, the following are possible resolutions:

• Set Enable32BitAppOnWin64=0. This turns off WOW64 everywhere at the source. This may not be possible because you may have legacy web applications which require 32bit. However, if this is the case, I question why you run 64bit Windows at all - running IIS6 in 32bit compatibility mode on 64bit Windows drags in all the WOW64 compatibility cruft without giving much 64bit advantages (the 32bit w3wp.exe still has a 32bit Address Space)
  
• Copy 64bit CMD.EXE to %systemroot%\SYSWOW64 . This may not be desirable because legacy applications may depend on 32bit CMD shell behavior
  
• Copy 64bit CSCRIPT.EXE to %systemroot%\SYSWOW64 . This may not be desirable because legacy applications may depend on 32bit Windows Scripting behavior
  
• Duplicate the IIS Admin .vbs Scripts and IISSCHLP.WSC from %systemroot%\System32 to %systemroot%\SYSWOW64 and use %systemroot%\SYSWOW64\REGSVR32.EXE to register IISCHLP.WSC into the 32bit Registry on 64bit Windows. This creates duplicate .vbs cruft but accomplishes your task without impacting any other part of the system
  

Good luck

//David