WinSCP process terminated with exit code 3 and output ""

Advertisement

Shyronosov Alex
Guest

WinSCP process terminated with exit code 3 and output ""

Hello Everyone,
Our .NET application uses WinSCP software to work with SFTP servers. It's running on different machines, however 1 week ago 2 of them started to fail with the following exception:

WinSCP.SessionLocalException, WinSCP process terminated with exit code 3 and output "", without responding (response log file D:\local\Temp\wscp1028.00ADA812.tmp was not created). This could indicate lack of write permissions to the log folder or problems starting WinSCP itself.,
at WinSCP.Session.Open(SessionOptions sessionOptions)

This error doesn't occur always, but after some period of time. Once error occurs it fails always until we restart the entire application. After application restart it successfully works 10-20 hours and approx. 15K-30K succeeded requests. Then the error starts again.

We have already upgraded to the last version of WinSCP (5.7.7), however the issue still takes place. What could be the root cause and what steps could be done to fix the issue? Any help is appreciated.

Thanks, Alex

Reply with quote

Advertisement

Yannick
Guest

Same issue

Hi,

we have the same issue on our production servers since 3/7/2016.

Our .Net application using the Winscp .NET wrapper is a windows service that runs under a specific build-in account. When I run the application from the console (with my user account) everything works fine. If a put my user on the windows server (instead of the build-in account) I receive the same error.

We are using Windows Server 2008R2 enterprise and the latest version of WinScp. Since rebooting the production machine is not an option, I hope someone could give us some advice to fix this issue?

Thanks,
Yannick

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
41,440
Location:
Prague, Czechia

Re: WinSCP process terminated with exit code 3 and output ""

Sorry for late answer. It took me while to find a time to test this. Though I was able to open 100K sessions over a span on about 24 hours in a single application run without any problem.

Can you try to use the Process Monitor to debug the failing start of winscp.exe?

Your duplicate question on Stack Overflew: https://stackoverflow.com/q/38170507/850848

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
41,440
Location:
Prague, Czechia

Re: Same issue

Yannick wrote:

Our .Net application using the Winscp .NET wrapper is a windows service that runs under a specific build-in account. When I run the application from the console (with my user account) everything works fine. If a put my user on the windows server (instead of the build-in account) I receive the same error.

We are using Windows Server 2008R2 enterprise and the latest version of WinScp. Since rebooting the production machine is not an option, I hope someone could give us some advice to fix this issue?
What version of WinSCP are you using? How exactly are you using the .NET assembly? This does not look like the same problem actually.

Reply with quote

Guest

Re: Same issue

martin wrote:

Yannick wrote:

Our .Net application using the Winscp .NET wrapper is a windows service that runs under a specific build-in account. When I run the application from the console (with my user account) everything works fine. If a put my user on the windows server (instead of the build-in account) I receive the same error.

We are using Windows Server 2008R2 enterprise and the latest version of WinScp. Since rebooting the production machine is not an option, I hope someone could give us some advice to fix this issue?
What version of WinSCP are you using? How exactly are you using the .NET assembly? This does not look like the same problem actually.

We are using version 5.7.7 and we use the library in a windows service (under the Local System account) on a Windows Server 2008 R2 virtual machine. We have multiple windows services registered and running on the same machine, and they all throw the same error. However, when I run the service from the command line (console) it works fine.

The issue was solved when we rebooted the virtual machine during our maintenance window, but of course we need some kind of solution for this because we can't reboot the machine at any time we want to.

Hope you can help,
Yannick

Reply with quote

Advertisement

Yannick
Guest

Re: Same issue

martin wrote:

Were you always using 5.7.7? Or did you use older version before?

We started with version 5.7.7, we did not use any older version before.

Reply with quote

Yannick
Guest

Re: Same issue

Yannick wrote:

martin wrote:

Were you always using 5.7.7? Or did you use older version before?

We started with version 5.7.7, we did not use any older version before.

I must correct my answer, we do use an old COM WinScp interface (file WinSCP.com of 18/07/203). We call this COM from a .NET executable with the help of the Process class. The .NET application itself runs in a Windows Task with a dedicated build-in user account.

I just discovered that this process was also failing like the other once, but I could not find any information of which process (Window Task or Windows Service(s)) did trigger the failure.

Is this is known issue on older versions? Maybe we need to upgrade the old WinScp.com file...

Kind Regards,
Yannick

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
41,440
Location:
Prague, Czechia

Re: Same issue

Yes, it's a know issue with WinSCP .NET assembly 5.2.4 and older:
https://winscp.net/tracker/996

And as commented in the tracker:
While the fixed versions no longer gradually exhaust system resources, they cannot recover resources exhausted by previous buggy versions.

So the old version breaks even the application that uses the new version.

Reply with quote

Advertisement

Yannick
Guest

Thank you for the information. We'll upgrade the old clients to the new version and hope it won't break again :wink:

Kind Regards,
Yannick

Reply with quote

Guest

Seeing this bug again in 5.9.4.0

Is there some number of times running winscp where this bug kicks back in even in the newer versions?

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
41,440
Location:
Prague, Czechia

Re: Seeing this bug again in 5.9.4.0

Anonymous wrote:

Is there some number of times running winscp where this bug kicks back in even in the newer versions?
How are you "seeing this bug"?

Does the error happen randomly only, for some runs?

Or are you really getting the same symptoms: When the error happens, it consistently happens for all runs. And only system restart helps?

Reply with quote

Guest

Re: Seeing this bug again in 5.9.4.0

martin wrote:

Anonymous wrote:

Is there some number of times running winscp where this bug kicks back in even in the newer versions?
How are you "seeing this bug"?

Does the error happen randomly only, for some runs?

Or are you really getting the same symptoms: When the error happens, it consistently happens for all runs. And only system restart helps?

Haven't seen this issue for about 6 months since upgrading from a very old release to 5.9.4 and now the same issue has resurfaced. It isn't random but happens on all runs and only a restart will fix it. The only thing that has changed is that there would now be even more runs than before so I was wondering if there was some magic number where it would just stop working and we need a new session.

Reply with quote

Advertisement

Guest

Re: Seeing this bug again in 5.9.4.0

Anonymous wrote:

martin wrote:

Anonymous wrote:

Is there some number of times running winscp where this bug kicks back in even in the newer versions?
How are you "seeing this bug"?

Does the error happen randomly only, for some runs?

Or are you really getting the same symptoms: When the error happens, it consistently happens for all runs. And only system restart helps?

Haven't seen this issue for about 6 months since upgrading from a very old release to 5.9.4 and now the same issue has resurfaced. It isn't random but happens on all runs and only a restart will fix it. The only thing that has changed is that there would now be even more runs than before so I was wondering if there was some magic number where it would just stop working and we need a new session.

Hi, you can disregard this. It looks like someone installed a new application that has the old version still in it. Sorry for the trouble.

Reply with quote

mert
Joined:
Posts:
2

Hi

I am having the same issue, the process exits with code 1 or 3.

This is what I currently have
WinSCP Version 5.13.1 (Build 8265) (OS 6.1.7601 Service Pack 1 - Windows Server 2008 R2 Datacenter)

I am getting directly connection failed with no extra information about why it is failing.

Things I have tried
-Restarted the application
-run from command line with the same parameters(THIS WORKS)

How can I see more details/logs? What am I doing wrong?

Thanks

. 2018-09-07 12:29:10.190 WinSCP Version 5.13.1 (Build 8265) (OS 6.1.7601 Service Pack 1 - Windows Server 2008 R2 Datacenter)
. 2018-09-07 12:29:10.190 Configuration: HKCU\Software\Martin Prikryl\WinSCP 2\
. 2018-09-07 12:29:10.190 Log level: Normal
. 2018-09-07 12:29:10.190 Local account: xxxx\xxxx$
. 2018-09-07 12:29:10.190 Working directory: C:\Windows\SysWOW64\inetsrv
. 2018-09-07 12:29:10.190 Process ID: 25092
. 2018-09-07 12:29:10.192 Command-line: "C:\Program Files (x86)\WinSCP\WinSCP.exe"  /script="C:\inetpub\xxxxx\xxxx\xxxxx\xxxxxx_ftp.txt" /log="C:\xxxx\xxxxxx\xxxx\xxxxx\xxxxxxxx_ftp.log"
. 2018-09-07 12:29:10.192 Time zone: Current: GMT-4, Standard: GMT-5 (Eastern Standard Time), DST: GMT-4 (Eastern Daylight Time), DST Start: 3/11/2018, DST End: 11/4/2018
. 2018-09-07 12:29:10.192 Login time: Friday, September 07, 2018 12:29:10 PM
. 2018-09-07 12:29:10.192 --------------------------------------------------------------------------
. 2018-09-07 12:29:10.192 Script: Retrospectively logging previous script records:
> 2018-09-07 12:29:10.192 Script: option batch abort
< 2018-09-07 12:29:10.192 Script: batch           abort     
> 2018-09-07 12:29:10.192 Script: option confirm off
< 2018-09-07 12:29:10.192 Script: confirm         off       
> 2018-09-07 12:29:10.192 Script: option transfer ascii
< 2018-09-07 12:29:10.192 Script: transfer        ascii     
> 2018-09-07 12:29:10.192 Script: open ftp://xxxxx:***@vftp.xxxxx.com
. 2018-09-07 12:29:10.192 --------------------------------------------------------------------------
. 2018-09-07 12:29:10.192 Session name: xxxxx@vftp.xxxxx.com (Ad-Hoc site)
. 2018-09-07 12:29:10.192 Host name: vftp.xxxx.com (Port: 21)
. 2018-09-07 12:29:10.193 User name: xxxxx (Password: Yes, Key file: No, Passphrase: No)
. 2018-09-07 12:29:10.193 Transfer Protocol: FTP
. 2018-09-07 12:29:10.193 Ping type: Dummy, Ping interval: 30 sec; Timeout: 15 sec
. 2018-09-07 12:29:10.193 Disable Nagle: No
. 2018-09-07 12:29:10.193 Proxy: None
. 2018-09-07 12:29:10.193 Send buffer: 262144
. 2018-09-07 12:29:10.193 UTF: Auto
. 2018-09-07 12:29:10.193 FTPS: None [Client certificate: No]
. 2018-09-07 12:29:10.193 FTP: Passive: Yes [Force IP: Auto]; MLSD: Auto [List all: Auto]; HOST: Auto
. 2018-09-07 12:29:10.193 Local directory: default, Remote directory: home, Update: Yes, Cache: Yes
. 2018-09-07 12:29:10.193 Cache directory changes: Yes, Permanent: Yes
. 2018-09-07 12:29:10.193 Recycle bin: Delete to: No, Overwritten to: No, Bin path: 
. 2018-09-07 12:29:10.193 Timezone offset: 0h 0m
. 2018-09-07 12:29:10.193 --------------------------------------------------------------------------
. 2018-09-07 12:29:10.195 Connecting to vftp.xxxxxxx.com ...
. 2018-09-07 12:29:10.233 Connection failed.

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
41,440
Location:
Prague, Czechia

mert wrote:

I am having the same issue, the process exits with code 1 or 3.

This is what I currently have
WinSCP Version 5.13.1 (Build 8265) (OS 6.1.7601 Service Pack 1 - Windows Server 2008 R2 Datacenter)

I am getting directly connection failed with no extra information about why it is failing.

Things I have tried
-Restarted the application
-run from command line with the same parameters(THIS WORKS)
I assume that when you run the script "from command line", you are using a different local account. Make sure that the account "xxxx\xxxx$" (from the log) has network connectivity allowed.

Reply with quote

Advertisement

You can post new topics in this forum