1

I read a while back that there are certain commands eg copy that under Win7 64 bit are actually 32 bit applications, not 64. Can anyone elaborate? If Im right, this means that they will need WOW64 to run correctly. The reason Im asking is that we have a few scripts that, when run manually, run fine but when run through Scheduler, sometime run fine and sometimes cause cmd.exe to crash. I was told that WOW64 is unstable and this is what causes the issue.

Improve this question
5
  • Explain "cause cmd.exe to crash" in more detail. Do you mean that you're seeing application failure reports in the Event Log coming from "cmd.exe"? I have no idea what somebody would mean by "WOW64 is unstable"-- I think somebody is feeding you mythology. A lot of sysadmins (developers, end users, apparently everyone in the world) don't understand how WOW64 works and certain myths and superstitions have grown up around it (because, apparently, people can't be bothered to read documentation and just think things are magic). (Gee, aren't I crabby today?)
    – Evan Anderson
    Jan 15, 2014 at 23:34
  • The scripts use basic copy/move/delete commands etc. When they run, a cmd.exe window will open and commands get executed. At random, the command being executed just stops responding and an error message is displayed, as in "This application has stopped responding and has been terminated", or something along those lines...
    – Brendan
    Jan 16, 2014 at 9:48
  • Yikes! That sounds like bad RAM, a bad I/O controller, etc. Having said that, running CMD.EXE on an x64 Windows install, unless you specifically take pains to do otherwise, will run a 64-bit CMD.EXE process. Commands like copy, move, and del are integral to CMD.EXE, so you're still getting 64-bit "versions" of those commands. Even if you were explicitly invoking a 32-bit CMD.EXE my experience has been that things work just fine. WOW64 is pretty mature-- it has been around since Windows Server 2003 x64 Edition-- and I am not aware of any reputation for "flakiness".
    – Evan Anderson
    Jan 16, 2014 at 11:02
  • Thanks for the input! Now can you add that as an answer so I can vote it up?
    – Brendan
    Jan 17, 2014 at 6:40
  • Fair enough... I mean, I need the rep. >giggle<
    – Evan Anderson
    Jan 17, 2014 at 18:06

2 Answers 2

Reset to default
3

What you describe in your comment gives me the willies! That sounds like bad RAM, a bad I/O controller, etc. That's definitely not normal Windows behavior.

Running CMD.EXE on an x64 Windows install, unless you specifically take pains to do otherwise, will run a 64-bit CMD.EXE process. Commands like copy, move, and del are integral to CMD.EXE, so you're still getting 64-bit "versions" of those commands. Even if you were explicitly invoking a 32-bit CMD.EXE my experience has been that things work just fine.

The Windows on Windows 64-bit environment (WOW64) is pretty mature. It has been around since Windows Server 2003 x64 Edition and I am not aware of any reputation for "flakiness". I think 64-bit Windows gets a bad rap mainly from devices that have only 32-bit kernel mode drivers available, and from its inability to execute 16-bit applications. Neither of those things, though, are anything like what you're describing.

Improve this answer
2
  • Antivirus could be a culprit. If decides the cmd process is doing something bad, it might just shoot it on the spot and ask questions later.
    – poke
    Jan 17, 2014 at 18:18
  • Id vote this up if I could. Thanks for the input, but Im still not 100% convinced. Thing is, Ive tried this on multiple machines. On ALL Win7 64bit machines, the scripts fail erratically over a few days. However, in Win7 32bit, I havent had a single issue. ALL the machines have the exact same software installed (except OS of course). I am considering resorting to using a Linux machine, on the same LAN, to move files between hotfolders. Learning powershell as suggested below isnt an option. I prefer sticking to one thing at a time and right now its Python...
    – Brendan
    Jan 23, 2014 at 6:48
0

I think you might want to consider starting the migrate to PowerShell, for this and a whole bunch of other good reasons. There's a very good set of lessons here.

(I would comment above, but don't have the points for it yet. But I will say this, I just checked and think I first used cmd over 30 years ago. It's had a good run.)

Improve this answer

You must log in to answer this question.

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