notepad.exe ran only at current dir = C:\ brings up 16-bit MS-DOS error

[VanguardLH]

When I run cmd.exe from Start->Run, it defaults to my %userprofile%
path. If I start cmd.exe using a shortcut, I get the C:\Windows path
(%windir%) as the current drive and path (unless I change the "Start
in" property in the shortcut). What path I get is not important
UNLESS it is C:\ and only if that path. Below are examples of when
notepad.exe runs and when it generates an error popup (the current
path is shown before the ">" delimiter):

Errors for:
C:\ > notepad.exe
No error for:
C:\ > \windows\system32\notepad.exe
C:\Temp > notepad.exe
C:\Program Files > notepad.exe
D:\ > notepad.exe

If and only if the current path is C:\ and I only specify the filename
(i.e., no path) for notepad.exe, I get the following error:

16 bit MS-DOS Subsystem
Command Prompt - notepad.exe mytasks.txt
The NTVDM CPU has encountered an illegal instruction.
CS:0de0 IP:03f4 OP:63 6f 6d 4c 61 Choose 'Close' to terminate the
application.

The CPU registry values are of no value. What is peculiar is that
this command (with no path) works if I set the current path to
*anything* other than C:\. The C:\Windows\System32 path is included
in the PATH environment variable so notepad.exe can be found
regardless of which directory I am in, and the error still shows that
notepad.exe is being found.

Weird. I've tested with some other .exe GUI'ed programs that are
under C:\Windows\System32 (and which is in the PATH environment
variable) with the current path at C:\, like winmine.exe, write.exe,
and mmc.exe, and they don't have a problem. Just notepad.exe, so far,
doesn't want to load if the current path is C:\ and only if it is that
path.

I don't have this problem inside a virtual machine in VMWare Server
running a clean install of Windows XP Pro SP-2 (fully updated) as the
guest OS. So the problem appears related to setup of my host OS (also
Windows XP Pro SP-2).

 

[Pegasus \(MVP\)]

When I run cmd.exe from Start->Run, it defaults to my %userprofile% path.
If I start cmd.exe using a shortcut, I get the C:\Windows path (%windir%)
as the current drive and path (unless I change the "Start in" property in
the shortcut). What path I get is not important UNLESS it is C:\ and only
if that path. Below are examples of when notepad.exe runs and when it
generates an error popup (the current path is shown before the ">"
delimiter):

Errors for:
C:\ > notepad.exe
No error for:
C:\ > \windows\system32\notepad.exe
C:\Temp > notepad.exe
C:\Program Files > notepad.exe
D:\ > notepad.exe

If and only if the current path is C:\ and I only specify the filename
(i.e., no path) for notepad.exe, I get the following error:

16 bit MS-DOS Subsystem
Command Prompt - notepad.exe mytasks.txt
The NTVDM CPU has encountered an illegal instruction.
CS:0de0 IP:03f4 OP:63 6f 6d 4c 61 Choose 'Close' to terminate the
application.

The CPU registry values are of no value. What is peculiar is that this
command (with no path) works if I set the current path to *anything* other
than C:\. The C:\Windows\System32 path is included in the PATH
environment variable so notepad.exe can be found regardless of which
directory I am in, and the error still shows that notepad.exe is being
found.

Weird. I've tested with some other .exe GUI'ed programs that are under
C:\Windows\System32 (and which is in the PATH environment variable) with
the current path at C:\, like winmine.exe, write.exe, and mmc.exe, and
they don't have a problem. Just notepad.exe, so far, doesn't want to load
if the current path is C:\ and only if it is that path.

I don't have this problem inside a virtual machine in VMWare Server
running a clean install of Windows XP Pro SP-2 (fully updated) as the
guest OS. So the problem appears related to setup of my host OS (also
Windows XP Pro SP-2).

It seems you have a rogue copy of notepad.exe on your
machine, or perhaps of notepad.com. Get rid of the
versions other than %SystemRoot%\System32\notepad.exe.

 

[VanguardLH]

in message

...

It seems you have a rogue copy of notepad.exe on your
machine, or perhaps of notepad.com. Get rid of the
versions other than %SystemRoot%\System32\notepad.exe.

Yep, that was it. After you mentioned that there might be a copy in
C:\ (the current path), I decided to go look in the C:\ path. There
was a copy of notepad.exe there. Unfortunately I deleted it before
doing a binary file compare against the one under C:\Windows\System32
(and deletes in a DOS shell don't get saved into the Recycle Bin). If
I copy the one from C:\Windows\System32 to C:\ then Notepad works okay
from there. So that notepad.exe that was there before was the
culprit.

I had it in mind that the notepad.exe used would be the one found
using the PATH environment variable. I forgot that DOS and Windows
will first look in the current directory *before* using the PATH
variable. Under UNIX, the current directory isn't included in the
file search unless you include it in the PATH.

I'm going to grab a copy of C:\notepad.exe from my backups to
investigate just what was this program that got into the root of my C:
drive.

 

[Pegasus \(MVP\)]

in message



Yep, that was it. After you mentioned that there might be a copy in C:\
(the current path), I decided to go look in the C:\ path. There was a
copy of notepad.exe there. Unfortunately I deleted it before doing a
binary file compare against the one under C:\Windows\System32 (and deletes
in a DOS shell don't get saved into the Recycle Bin). If I copy the one
from C:\Windows\System32 to C:\ then Notepad works okay from there. So
that notepad.exe that was there before was the culprit.

I had it in mind that the notepad.exe used would be the one found using
the PATH environment variable. I forgot that DOS and Windows will first
look in the current directory *before* using the PATH variable. Under
UNIX, the current directory isn't included in the file search unless you
include it in the PATH.

I'm going to grab a copy of C:\notepad.exe from my backups to investigate
just what was this program that got into the root of my C: drive.

.. . . and so you should. Having rogue programs on the disk is
cause for concern.

 

[VanguardLH]

in message

...

. . . and so you should. Having rogue programs on the disk is
cause for concern.

Nope, not in my backups performed at 3AM today. notepad.exe got
created today. I might know why. While the current path was at C:\,
I was trying to run the following command:

tasklist /svc > mytasks.txt && notepad.exe mytasks.txt

This should work and does work when I tried it again - except that
after retrying it multiple times then I found another rogue copy of
notepad.exe under C:\. The redirection of tasklist into a file must
somehow also be doing the same into notepad.exe. I've only been able
to reproduce once the creation of notepad.exe when I retried this
command so I'm not sure what caused it yet. Maybe redirection doesn't
cooperate reliably with multiple commands (the "&" or "&&" delimiter)
on the command line.

 

[Pegasus \(MVP\)]

in message


Nope, not in my backups performed at 3AM today. notepad.exe got created
today. I might know why. While the current path was at C:\, I was trying
to run the following command:

tasklist /svc > mytasks.txt && notepad.exe mytasks.txt

This should work and does work when I tried it again - except that after
retrying it multiple times then I found another rogue copy of notepad.exe
under C:\. The redirection of tasklist into a file must somehow also be
doing the same into notepad.exe. I've only been able to reproduce once
the creation of notepad.exe when I retried this command so I'm not sure
what caused it yet. Maybe redirection doesn't cooperate reliably with
multiple commands (the "&" or "&&" delimiter) on the command line.

I've been using redirection and command concatenation for years
and found both totally reliable. Perhaps you mistyped your command
line like so:
tasklist /svc > notepad.exe && notepad.exe mytasks.txt
It would certainly generate the result you reported. What did that
other rogue copy of notepad.exe contain?

 

[Pegasus \(MVP\)]

in message


Nope, not in my backups performed at 3AM today. notepad.exe got created
today. I might know why. While the current path was at C:\, I was trying
to run the following command:

tasklist /svc > mytasks.txt && notepad.exe mytasks.txt

This should work and does work when I tried it again - except that after
retrying it multiple times then I found another rogue copy of notepad.exe
under C:\. The redirection of tasklist into a file must somehow also be
doing the same into notepad.exe. I've only been able to reproduce once
the creation of notepad.exe when I retried this command so I'm not sure
what caused it yet. Maybe redirection doesn't cooperate reliably with
multiple commands (the "&" or "&&" delimiter) on the command line.

At second thoughts I realise that your command

tasklist /svc > mytasks.txt && notepad.exe mytasks.txt

makes no sense anyway. Why would you execute notepad.exe
conditionally? It should, of course, be

tasklist /svc > mytasks.txt & notepad.exe mytasks.txt

 

[VanguardLH]

At second thoughts I realise that your command

tasklist /svc > mytasks.txt && notepad.exe mytasks.txt

makes no sense anyway. Why would you execute notepad.exe
conditionally? It should, of course, be

tasklist /svc > mytasks.txt & notepad.exe mytasks.txt

If tasklist doesn't run or errors, why would I want notepad to open a
file that doesn't exist or is empty? I'd rather not have notepad open
and block my view of the DOS prompt to see the error that resulted
from the prior command.

 

[VanguardLH]

in message

I've been using redirection and command concatenation for years
and found both totally reliable. Perhaps you mistyped your command
line like so:
tasklist /svc > notepad.exe && notepad.exe mytasks.txt
It would certainly generate the result you reported. What did that
other rogue copy of notepad.exe contain?

Nope, got busy and didn't have time to analyze this small problem so
the new notepad.exe got deleted and I went on to other tasks.

 

[Pegasus \(MVP\)]

in message



Nope, got busy and didn't have time to analyze this small problem so the
new notepad.exe got deleted and I went on to other tasks.

In your third post you wrote "Maybe redirection doesn't cooperate
reliably with multiple commands (the "&" or "&&" delimiter) on the
command line." If you're serious about troubleshooting such a basic
malfunction then you need to examine the evidence, not destroy it.
And if you consider it a "small problem" (your words), why did you
spend so much time on it initially?

 

[VanguardLH]

In your third post you wrote "Maybe redirection doesn't cooperate
reliably with multiple commands (the "&" or "&&" delimiter) on the
command line." If you're serious about troubleshooting such a basic
malfunction then you need to examine the evidence, not destroy it.
And if you consider it a "small problem" (your words), why did you
spend so much time on it initially?

Since it appeared to be a failure in how I entered the command (so it
wasn't malware) or something in the parsing for a command syntax that
I rarely use, it fell off the radar due to its severely reduced
priority.