Scheduled Task in Windows hangs WinSCP

I have a simple script file for WinSCP 3.7.1 I'm trying to run via winscp3.com. I have a .cmd file called by Windows Scheduler that does some other tasks, then calls the WinSCP program with the script:

e:\winscp3\winscp3.com admin@host.domain.net /script=updateusa.txt

the script looks like this:

option batch on
option transfer automatic
option synchdelete on
lcd d:\snapshots\usa\foo
cd /data/domino/stgdoma/domino/html/foo
synchronize remote
close
exit

If I run the .cmd file manually, it runs great - all tasks run to completion, and everything exits all nice and clean. If I run this from the scheduler (either automatically, or if I right-click on the task and choose Run), it hangs at the winscp routine. I've enabled logging in winscp, and this works fine if I run the .cmd file manually, but it doesn't generate any log file at all if I run it from the scheduler.

When I check Task Manager, WinSCP3.com and WinSCP3.exe are still running, and I have to shut them down manually (End Process).

Any ideas?

I've done several tests just now and everything works as expected (I admit that I've never tried it before).

Maybe there are some specific circumstances in your case. What version of Windows are you using? Does console window for the .cmd script shows up? It someone logged to the machine when script is running? Does it run under the same user as the one logged in?

martin wrote:

I've done several tests just now and everything works as expected (I admit that I've never tried it before).

Maybe there are some specific circumstances in your case. What version of Windows are you using? Does console window for the .cmd script shows up? It someone logged to the machine when script is running? Does it run under the same user as the one logged in?

I was using one login to log in to the Windows session, but the task was running under the permissions of a different login (e.g., not mine, one whose password doesn't expire every 60 days). My login had access to the stored session information I was calling, but the other login did not. As soon as I ran WinSCP under the other login and created a stored session with the same name, everything ran fine.


Thanks for the pointer.

OK, that would explain this. If your stored session has a default name "user@host" and it actually does not exist (for the other login), WinSCP parses the name into user and host and actually connect to the right host. But it does not know a password, so it asks for it. That's probably why the WinSCP looked like "hanged".