Perfect email sent and logs attached to it.

Please send both the trace and session logs. Consider using an email, rather than posting the logs online.

Hey Martin,

I've made the requested changes and am now finding that my script fails consistently with the "waiting for WinSCP to respond" error message. Attached is the trace log for one of the events and my debug level 1 logs all end relatively the same way:

The bold is the exception as this did not appear in all of my debug logs only the one I have attached the trace for.

Hey Martin,

I downloaded it and notice it's a raw folder with executable that doesn't require install. I tried to duplicate the error manually be no avail it downloaded fine. When trying to use the WinSCPnet.dll it fails saying it or a secondary item can't be loaded. I sent an email with more information. I also notice that it create 1gb log files for either every packet it downloads or is just limiting it to that size (totaled about 22gb in trace logs)

I cannot reproduce this.
I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

I tried doing debug level 2 in the past but the text file ended up over 32gb. I am retrying it now and will post debug level 2 if it doesn't explode. Here is the debug level 1 log that I previously set as default, it's size is around 127mb uncompressed.

Update; I set debug level 2, ran it successfully and it created a 52gb log file, so can't really use that.

It's a different problem this time. The Debug 2 log would indeed be useful. Make sure you set $session.DebugLogLevel = 2

Thank you for your patience. I have configured it on my server and it finally failed after a few days (doing it twice a day). Attached is the log created by the variable $Session.SessionLogPath. I thought I set it to log level 2 in WinSCP but it seems the log shows as "normal".

Thank you for the info. To help facilitate this i'm going to rebuild it on my server and get the logs from there.

This is not WinSCP log. It's does not even looks to be a log from some PowerShell script that might use WinSCP. The code uses Get-SFTPFile cmdlet, what seems to be Posh-SSH code.

Thank you for the help. The client provided this log but it appears to be a PS log and not the WinSCP log created from the UI, the client confirms this is the log created from WinSCP however.

cmims911 wrote:

If we click "reconnect" in the GUI it works fine.

Can you post the log file?

Do you believe this is something on the server side disconnecting it or client side?

I believe it's server-side problem.

If we click "reconnect" in the GUI it works fine. Do you believe this is something on the server side disconnecting it or client side?

If this happens in the GUI and you reconnect, does it resume the transfer? Can you post a log file for that?
In the script, it does not reconnect, because actually the connection is not lost. It's just that WinSCP receives an invalid response from the server, so it terminated the transfer on its own.

Sorry for the delay the client went quiet after claiming to make a few adjustments. It doesn't auto-restart it seems (at least for this client, no one else has contacted me). Attached is the log file from 2 consecutive days of the error.

cmims911 wrote:

I was wondering if there's a way to script this into PowerShell to automatically reconnect or suppress the prompt and continue attempting to download anyway.

And doesn't it? It should do that by default. If it does not, please post a session log file.

I have a custom script that downloads files from a FTP server every 24 hours for several clients and it works fine. For only one client it is failing with "waiting for WinSCP to respond" when trying to manually download the file immediately follow the error WinSCP eventually shows a prompt saying "connect (15s)" or "cancel" (maybe "disconnect" it's been a while). I was wondering if there's a way to script this into PowerShell to automatically reconnect or suppress the prompt and continue attempting to download anyway. The client claims it's not on their end causing the disconnect but no one else experiences it.