Scheduled *.EXE script hangs

General Macro Scheduler discussion

Moderators: Dorian (MJT support), JRL

Post Reply
cgaston
Junior Coder
Posts: 24
Joined: Sat Jan 22, 2005 11:52 am
Location: Ottawa, Canada

Scheduled *.EXE script hangs

Post by cgaston » Fri Feb 25, 2005 1:47 pm

I have a compiled script (*.exe) that works perfectly when I lauch it manually.

When I schedule it with WTS, I have indications that it does start, but hangs at some point. As this is running in "blind" mode, that is pretty difficult to troubleshoot.

I am at the point, where I suspect that some MSched commands may not work in that mode. Are there any special restrictions or timing issues to consider when scheduling an *.exe.

I am running Windows 2000. Our LAN is Novell. I scheduled the exe tu run with the W2K account "administrator". Everything it needs are local, and not dependant on the LAN. When I log in as "administrator" and launch it manually, that's fine.

Thanks for your help.

Gaston.

User avatar
support
Automation Wizard
Posts: 1450
Joined: Sat Oct 19, 2002 4:38 pm
Location: London
Contact:

Post by support » Fri Feb 25, 2005 1:51 pm

Is the console logged in when the EXE is run? If not then it may fail to work if you have any window, key or mouse functions in your script. See the following FAQ entry:
http://www.mjtnet.com/index.htm?msfaq17.html

Add the /LOGFILE switch to the command line so that we can see a log file and determine where the hang occurs. e.g.:

mymacro.exe /LOGFILE=c:\mylogfile.log
MJT Net Support
[email protected]

cgaston
Junior Coder
Posts: 24
Joined: Sat Jan 22, 2005 11:52 am
Location: Ottawa, Canada

Post by cgaston » Fri Feb 25, 2005 4:28 pm

Hi,

I read your document a couple of time, and I would like you to confirm my understanding:

My *.exe is making use of windows and key functions. Therefore, it won't run, even as a service, if the workstation is logged out.

When windows or key functions are used, we can use the WTS, but the workstation must remain logged in.

Thank you,

Gaston.

cgaston
Junior Coder
Posts: 24
Joined: Sat Jan 22, 2005 11:52 am
Location: Ottawa, Canada

Post by cgaston » Fri Feb 25, 2005 4:29 pm

Hi,

I read your document a couple of time, and I would like you to confirm my understanding:

My *.exe is making use of windows and key functions. Therefore, it won't run, even as a service, if the workstation is logged out.

When windows or key functions are used, we can use the WTS, but the workstation must remain logged in.

Thank you,

Gaston.

User avatar
support
Automation Wizard
Posts: 1450
Joined: Sat Oct 19, 2002 4:38 pm
Location: London
Contact:

Post by support » Fri Feb 25, 2005 4:41 pm

Correct. Your .EXE will fail unless the console is logged in. This is because the windows that it is trying to interract with don't exist unless the console is present. WTS runs as a service and therefore can *start* your .EXE whether or not the console is present, but if it isn't your macro will fail to complete due to the fact that the windows it expects to find don't exist.
MJT Net Support
[email protected]

cgaston
Junior Coder
Posts: 24
Joined: Sat Jan 22, 2005 11:52 am
Location: Ottawa, Canada

Post by cgaston » Fri Feb 25, 2005 5:57 pm

One last question before I give up.

Does the "console" that you are referring to, exist only when a user (administrator, or any other W2K account) is logged in onto the workstation

Thank you,

Gaston.

cgaston
Junior Coder
Posts: 24
Joined: Sat Jan 22, 2005 11:52 am
Location: Ottawa, Canada

Post by cgaston » Fri Feb 25, 2005 6:17 pm

Let me be even more precise (see previous post):

I am logged to Windows as user "gaston". The script is scheduled to run from the account "administrator". In that scenario, someone is logged in to the workstation, but the script still fails.

I must be logged in as "administrator" in order for the script to run successfully.

Correct?

Gaston.

User avatar
support
Automation Wizard
Posts: 1450
Joined: Sat Oct 19, 2002 4:38 pm
Location: London
Contact:

Post by support » Fri Feb 25, 2005 7:06 pm

Yes, a real user must be fully logged in for the console to exist. This is not the same as telling a service to run under a specific account. Sure, the security context will be right, but no console will exist.

If the machine is logged out or locked there is no console.
MJT Net Support
[email protected]

Post Reply
cron
Sign up to our newsletter for free automation tips, tricks & discounts