The System cannot execute the specified program

[Tim]

Our logon script runs a few .COM files as well as .EXE
files. Unfortunately, in the last couple of months,
something has changed in our environment that prevents
the .COM files from running. We receive the "The System
cannot execute the specified program" error during the
logon script execution. However, if we manually run
the .COM file it works perfectly.

The logon script and the .COM file have not changed in
two years. We do not have any software restriction
policies in place. We have all the current security
patches on both the server and the client. We are
running Win2k servers with Win XP clients. The XP
clients also have Admin privileges. Searches on TechNet
have been fruitless. Can anyone help?
..

 

[Pegasus \(MVP\)]

Our logon script runs a few .COM files as well as .EXE
files. Unfortunately, in the last couple of months,
something has changed in our environment that prevents
the .COM files from running. We receive the "The System
cannot execute the specified program" error during the
logon script execution. However, if we manually run
the .COM file it works perfectly.

The logon script and the .COM file have not changed in
two years. We do not have any software restriction
policies in place. We have all the current security
patches on both the server and the client. We are
running Win2k servers with Win XP clients. The XP
clients also have Admin privileges. Searches on TechNet
have been fruitless. Can anyone help?
.

What .com programs do you run in your logon script?

 

[Guest]

-----Original Message-----



What .com programs do you run in your logon script?


.

We have a few small Assembly programs that we have used
for years. The most important one compares date and time
stamps on files. With out this .COM file working, our
dialin users have a much slower logon. Network users do
not notice a performance hit.

 

[Pegasus \(MVP\)]

We have a few small Assembly programs that we have used
for years. The most important one compares date and time
stamps on files. With out this .COM file working, our
dialin users have a much slower logon. Network users do
not notice a performance hit.

Rename your .com files to .exe files - they will run just as
well - and see what you get.

To compare file dates, you can easily use xcopy.exe with
the /d switch.

 

[Guest]

-----Original Message-----



Rename your .com files to .exe files - they will run just as
well - and see what you get.

To compare file dates, you can easily use xcopy.exe with
the /d switch.


.
Good call, however we had already tried renaming them

to .exe's and have had no luck. They still will not
execute.
We have been using the /D switch for XCOPY for several
years as well. But we run several processes other than
XCOPY which are based on file dates. If we don't need to
run them, it saves a lot of time for our dialup users.

We could recreate the assembly program in a different
language and compile it to an .EXE. However, the core
issue is that all .COM files should still be able to run
from the LOGON script as they have for the past several
years.

 

[Matt Hickman]

Our logon script runs a few .COM files as well as .EXE
files. Unfortunately, in the last couple of months,
something has changed in our environment that prevents
the .COM files from running. We receive the "The System
cannot execute the specified program" error during the
logon script execution. However, if we manually run
the .COM file it works perfectly.

Are you using the full pathnames of the .com
files in your scripts? Including the extensions?


--
Matt Hickman
Jim regarded Allan Quartermain as the greatest man who had ever
lived; Joe held out for John Henry.
Robert A. Heinlein (1907 - 1988)
"Universe" c 1941 (ASF)

 

[Pegasus \(MVP\)]

to .exe's and have had no luck. They still will not
execute.
We have been using the /D switch for XCOPY for several
years as well. But we run several processes other than
XCOPY which are based on file dates. If we don't need to
run them, it saves a lot of time for our dialup users.

We could recreate the assembly program in a different
language and compile it to an .EXE. However, the core
issue is that all .COM files should still be able to run
from the LOGON script as they have for the past several
years.

It seems you have a problem with the NTVDM process. I would now do this:

- Run regedit.exe and check HKEY_CLASSES_ROOT\.com\PersistentHandler.
It's supposed to have a value of {098f2470-bae0-11cd-b579-08002b30bfeb}
(Reg_SZ).
- Same in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.com\PersistentHandler
- Scan your PC with an external virus scanner,
e.g. on www.antivirus.com ("free online scan").
- Run sfc.exe (System File Checker).
- Re-apply the latest service pack.

 

[Guest]

-----Original Message-----



It seems you have a problem with the NTVDM process. I would now do this:

- Run regedit.exe and check HKEY_CLASSES_ROOT\.com\PersistentHandler.
It's supposed to have a value of {098f2470-bae0-11cd- b579-08002b30bfeb}
(Reg_SZ).
- Same in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.com\PersistentHandler
- Scan your PC with an external virus scanner,
e.g. on www.antivirus.com ("free online scan").
- Run sfc.exe (System File Checker).
- Re-apply the latest service pack.


.
Well, the registry checked out OK, and we have no

viruses. Everything else seems OK. We think the last
patch that modified the VDM might be the ticket. We
might open a ticket with Microsoft at this point.