Software Sleuthing : 64bit

Running 32bit dependent scripts in a 64bit world

joshpoley — Thu, 18 Sep 2008 20:44:00 GMT

As seen earlier, it can be problematic to run scripts which rely on 32bit COM objects on a 64bit platform. To make things easier, I wrote basic some script code to detect that the wrong scripting host was run and fork out to the correct one. This just uses a variation of the "detect cscript vs. wscript" pattern, but instead we look at the current processor and do a check to see if we are running the wrong flavor of the script host.

// this script code relies on 32bit COM objects, if we are running on

// a 64bit system we will want to run under WOW64 (the x86 emulator).

var shell = WScript.CreateObject("WScript.Shell");

var cpu = shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%").toLowerCase();

var host = WScript.FullName.toLowerCase();

// check to see if we are on an AMD64 processor and running the

// wrong version of the scripting host.

if(host.indexOf("system32") != -1 && cpu == "amd64")

{

var syswow64Host = host.replace(/system32/g, "syswow64");

var newCmd = syswow64Host + " \"" +

WScript.ScriptFullName + "\" //Nologo";

// ATTEMPT to pass all the same command

// line args to the new process

var args = WScript.Arguments;

for(i=0; i<args.length; i++)

newCmd += " " + args(i);

WScript.Echo("Running the syswow64 bit version instead...\n " +

newCmd + "\n");

// launch the new script and echo all the output

var exec = shell.Exec(newCmd);

while(exec.Status == 0)

{

if(!exec.StdOut.AtEndOfStream)

WScript.Echo(exec.StdOut.ReadAll());

WScript.Sleep(100);

}

if(!exec.StdOut.AtEndOfStream)

WScript.Echo(exec.StdOut.ReadAll());

WScript.Quit(exec.ExitCode);

}

// the real script code goes here ...

WScript.Echo("done");

In this sample we are just checking for AMD64, so you may want to add logic for Itanium or other platforms as well.

Be sure to notice the "ATTEMPT" comment when transposing the command line options from the current process into the new one. The way that the command shell handles double quotes makes it hard to reproduce the exact command line from the support we have in script. For example, if you pass /abc="hello world" as an argument, the quotes will get stripped out and you will actually see /abc=hello world from your script code. If we pass this raw argument (as shown above) into the new process then the one argument will be interpreted as two because of the missing quotes. It is left as a reader exercise to detect spaces and reconstruct the exact arguments if needed.

CreateObject fails with 0x80040154

joshpoley — Wed, 17 Sep 2008 18:15:00 GMT

I've got a handful of stand-alone script files (mostly JavaScript) which I run from cscript.exe or wscript.exe to perform various tasks. Unfortunately, when I was setting up one of these scripts on a Server 2008 box it started to fail when attempting to instantiate one of my COM objects.

If you go lookup the failure code (0x80040154) you will see that it is the value for the "class not registered" error. Ok, no problem, just re-register the DLL again (via regsvr32.exe), and re-run the script. But, alas, this gave me the same error. So now I go digging through the registry to manually ensure the chain of keys and all their nodes look valid. I then try oleview.exe, and it is able to see the COM object and instantiate a version of it, so now things are really starting to get interesting (and a simple task which should have taken me a couple of minutes is now dragging out).

After a bit of further fruitless digging around, it occurs to me that the COM object is in a 32 bit DLL, and I'm running on a 64 bit version of Server 2008. Hmm, I wonder if that is the issue. I then go searching through my windows directory for all the copies of cscript.exe, and come across two: one in "system32" and one in "syswow64". So I then go and run the syswow64 version on my script file, lo and behold, it executes flawlessly.

So if your computer tells you that your COM object isn't installed, but you are pretty darn sure it is, check to ensure you are also running a compatible script host...

Custom "View Source" Application on IE

joshpoley — Mon, 07 Jul 2008 17:32:00 GMT

In the process of setting up a 64bit Server 2008 box, I ran into a little issue trying to convince IE which tool to use when I want to view the source of a web page or document. All of the "documentation" out on the web states that you need to modify the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\View Source Editor\Editor Name

But for some bizarre reason, it wasn't working for me. After beating my head around a bit and some fruitless searches, I finally brought out Process Monitor so I could watch and see exactly what registry key IE was looking at (gee, I should have done that to begin with). As it turns out, they decided to walk to the Wow6432 node instead, in support of that whole multiple version thing: This way you can have both a 32bit and a 64bit version installed and their settings don't tromp on each other.

So, if you are setting your own application, I suggest modifying both of the following nodes if you are running a 64-bit OS:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\View Source Editor\Editor Name]

@="C:\\myViewer.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\View Source Editor\Editor Name]

@="C:\\myViewer.exe"