Debugging transfer task running in Windows Scheduler, SSIS, or another automation service

First step in debugging, is to make sure the task works when executed independently. Execute the exact command that you have configured in Windows Scheduler/SSIS in Windows Command prompt.

For example, if in Windows Scheduler you have "C:\Program Files (x86)\WinSCP\WinSCP.exe" in Program/script and /script="c:\script\example.txt" in Add arguments, try to execute following full command in Command prompt:

"C:\Program Files (x86)\WinSCP\WinSCP.exe" /script="c:\script\example.txt"

Execute the command from an independent working directory (neither WinSCP installation folder C:\Program Files (x86)\WinSCP, nor script folder, nor transfer source nor destination folder). Common cause of problems is that your command or script rely on a specific working directory, and your scheduled tasks runs from elsewhere.

If the command works correctly from Command prompt, see My script works fine when executed manually, but fails or hangs when run by Windows Scheduler, SSIS or other automation service. What am I doing wrong?

If the task fails even when run from Command prompt, inspect a console output of the task for any error. If you see an error, check list of common error messages or search this website for the error. To check for an error in console output, it is recommended to use winscp.com.

If the problem is not obvious from the output, enable logging to a file as described below.

Next step is to enable logging to file (you should have logging enabled anyway) and inspect the log. Use /log command-line parameter.

For example in Windows Scheduler the Add arguments may look like:

/script="c:\script\example.txt" /log="c:\script\example.log"

Full command to be executed from Command prompt is:

"C:\Program Files (x86)\WinSCP\WinSCP.exe" /script="c:\script\example.txt" /log="c:\script\example.log"

If you know that the task failed with exit code 1, see Why is WinSCP returning non zero exit code? to learn what to look for in the log.

If a session log file is not even created, when executed from Windows Scheduler/SSIS, although the same WinSCP command and logging is working, when executed manually on command-line, there can be some problem in the Windows Scheduler/SSIS environment that prevents WinSCP from starting or writing to the log.

To debug such problems, wrap WinSCP command to a batch file and redirect WinSCP console output to a file. Make sure you use a console interface tool winscp.com, instead of winscp.exe. It is also useful to log something to the output file before running WinSCP, to verify that output logging is working.

The batch file can look like:

@echo off
(
  echo Starting WinSCP
  "C:\Program Files (x86)\WinSCP\WinSCP.com" /script="c:\script\example.txt" /log="c:\script\example.log"
  echo WinSCP done
) > C:\script\example.out 2>&1

Make sure you use a path for the example.out, where Windows Scheduler/SSIS have a write access to. Check an output logged to example.out for any problems. If the example.out is not even created, the problem is not with WinSCP.

If it turns out that WinSCP cannot read or write local files, it is usually because the local account that runs the Windows Scheduler/SSIS does not have permissions to access those files or their containing folders. Try reading or writing those files in a wrapper batch file (see the previous section), to verify that you get the same problem even without WinSCP.

@echo off
(
  echo Testing reading of a file
  copy C:\source\file.txt %TEMP%
 
  echo Testing writing of a file
  echo Dummy contents > C:\destination\file.txt
 
  echo Starting WinSCP
  "C:\Program Files (x86)\WinSCP\WinSCP.com" /script="c:\script\example.txt" /log="c:\script\example.log"
  echo WinSCP done
) > C:\script\example.out 2>&1

While the previously mentioned techniques are mostly focused on WinSCP scripting and batch files, some can be used even when debugging a PowerShell script (that uses WinSCP .NET assembly).

Particularly, when debugging problems starting the PowerShell script itself, it is useful to wrap the powershell.exe/pwsh.exe command to a batch file. That will allow you to redirect a PowerShell output to a file, the same way as shown above for winscp.com.

If you know that your PowerShell is starting, but fails somewhere before WinSCP session log (Session.SessionLogPath) is created, and you do not want to create the batch file wrapper, use Start-Transcript cmdlet in the PowerShell script itself. Using it, you can capture all the PowerShell output that you would otherwise see on the PowerShell console. Put the following line to the beginning of your script (but after the param statement, if you have one):

Start-Transcript C:\script\example.transcript

• Why WinSCP does not work in a new environment (operating system, machine, user account, network), when it works for me in a different environment already?
• How do I know that script completed successfully?
• Why I cannot connect/transfer using script, when I can using GUI (or vice versa)?