Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

cpanne

Re: Weird "Waiting for log" problem in C# .NET WebDAV

[quote="martin"]Ok, then it might be due to OpenSSL 3 and its more strict security. Try this:
[code]@csharp@
sessionOptions.AddRawSettings("MinTlsVersion", "10");
[/code]
(Decreasing min TLS version has a side effect of decreasing security level even for newer protocol versions)[/quote]

Hi Martin this didn't helped I also tyed the Max TLS Setting to see if it works with TLS 11 and lower but then it just stops.

I'm not shure but my idea is that somehow Windows handles Tasks different when they are executed in the Backgound as a Service maybe the tasks are getting throtteled down or something like that but if that is true why is it workung in 6.1.2 !? and why is it working on a different System with the same OS version and configured to use the same Proxy as the other Server?

I Added the Logs of my Tests in a zip
Guest

Re: Weird "Waiting for log" problem in C# .NET WebDAV

cpanne wrote:

Hello Together,

We have a C# project where we use the NuGet package of WinSCP and try to manage patches for a different software and download them from a Nextcloud via WebDAV.
Now switched from the version 6.1.2.0 to 6.5.3.0 (16364). The project is running in the background as a Windows Service as user System.

Now the problem:
with the new version we have problems to connect to the Nextcloud.
In the logs we see a lot of the following messages until the Proxy Server that we use for that closes the connection after 1 Minute.
[2025-08-20 02:03:03.647] [0003]     Waiting for log update and dispatching events for 800

[2025-08-20 02:03:03.725] [0007]   2nd generation collection count: 5
[2025-08-20 02:03:03.725] [0007]   Total memory allocated: 15521656
[2025-08-20 02:03:03.725] [0007]   Waiting for request event
[2025-08-20 02:03:03.834] [0007]   2nd generation collection count: 5
[2025-08-20 02:03:03.834] [0007]   Total memory allocated: 15529848
[2025-08-20 02:03:03.834] [0007]   Waiting for request event

Now that where it is getting weird.
When we execute the same code on the same machine as a User and not as System the connection can be build up (like we want to). We still see the messages for a few times but it generally works.
When we execute the same code on a different machine with the same proxy and in the same network and with the same operating system Windows Server 2019 (Build 17763) the code works in background as System and in foreground as a User.
Maybe I overlook something but I can't explain why that happens. In the old version we never had that issue.

I hope you can help me identify the issue if you need more information please tell me what you need.




cpanne wrote:


Hello Together,
(--- yahan unka pura message hai ---)


Hi @cpanne,

thanks for the detailed explanation. A couple of thoughts that might help narrow this down:

1. **Local System vs. User account**
- The `SYSTEM` account usually has very restricted network/proxy configuration compared to a normal user account. For example, proxy settings (WinHTTP vs. WinINET) are per-user and `SYSTEM` often has none configured. That could explain why it works interactively, but not as a service.
- You can check the WinHTTP proxy settings for `SYSTEM` with:
```
netsh winhttp show proxy
```
and, if needed, copy your user’s proxy config:
```
netsh winhttp import proxy source=ie
```

2. **Differences between versions (6.1.2.0 vs. 6.5.3.0)**
- In newer builds, WinSCP’s WebDAV implementation may rely more heavily on proper proxy settings. That could expose the missing proxy config for `SYSTEM`.
- Double-check release notes for WebDAV changes around 6.5.x.

3. **Diagnostics**
- Try running the same code with `Logging enabled` at a higher verbosity (`Session.DebugLogPath`). That may show whether the service is stuck at proxy negotiation.
- Also test the service under a dedicated service account (instead of `SYSTEM`) that has the correct proxy configuration.

4. **Workarounds to try**
- Configure proxy for `SYSTEM` as shown above.
- Run the service under a domain/user account instead of `SYSTEM`.
- If your environment allows, bypass the proxy for Nextcloud’s host to confirm the proxy is the bottleneck.

So in short: the difference is most likely due to `SYSTEM` having no proxy config, and the newer WinSCP/WebDAV version depending on it.

Hope this helps — let us know if updating the `SYSTEM` proxy settings resolves the issue.
martin

Re: Weird "Waiting for log" problem in C# .NET WebDAV

Ok, then it might be due to OpenSSL 3 and its more strict security. Try this:
sessionOptions.AddRawSettings("MinTlsVersion", "10");

(Decreasing min TLS version has a side effect of decreasing security level even for newer protocol versions)
cpanne

Re: Weird "Waiting for log" problem in C# .NET WebDAV

Hi Martin,
It is very Important to know that I can't test it with using the UI because then the Problem isn't there. The problem is only there when The Process is getting Executet as a Service with the User SYSTEM. When i start the UI or execute our Program as a user over the Powershell the problem isn't there!

I testet the other Versions. I found out that all of the versions after 6.1.2 have this Issue. I Added the logs.

Thank you for your help
martin

Re: Weird "Waiting for log" problem in C# .NET WebDAV

Thanks. So can you please verify that the 6.2.3 works and 6.2.4 does not?
(it might be easier to just try to login with the GUI)
cpanne

Re: Weird "Waiting for log" problem in C# .NET WebDAV

Hi Martin,

I Tested all released versions from 6.1.2 to 6.5.3 and added the logs. The issue occured from 6.3.0 in every release.

I don't want to guide you in a wrong direction but maybe it has something to do with the "WebDAV/HTTP core upgraded to neon 0.33.0" Upgrade in 6.2.4 RC

Thanks in advance
martin

Re: Weird "Waiting for log" problem in C# .NET WebDAV

Thanks. Though I was not able to identify anything useful.
Can you try to find out in what version of WinSCP was the problem introduced (if it is at all related to WinSCP version)?
You can find old versions of WinSCP at:
https://sourceforge.net/projects/winscp/files/WinSCP/
cpanne

Re: Weird "Waiting for log" problem in C# .NET WebDAV

Hi Martin,

I added the Logs in a .zip. I hope you can access them (private file).
Just for your information I replaced some things because of security reasons.

Thank you for looking at that problem :)
martin

Re: Weird "Waiting for log" problem in C# .NET WebDAV

Please post a session log file both from the old and the new version from the same enviornment.
cpanne

Weird "Waiting for log" problem in C# .NET WebDAV

Hello Together,

We have a C# project where we use the NuGet package of WinSCP and try to manage patches for a different software and download them from a Nextcloud via WebDAV.
Now switched from the version 6.1.2.0 to 6.5.3.0 (16364). The project is running in the background as a Windows Service as user System.

Now the problem:
with the new version we have problems to connect to the Nextcloud.
In the logs we see a lot of the following messages until the Proxy Server that we use for that closes the connection after 1 Minute.
[2025-08-20 02:03:03.647] [0003]     Waiting for log update and dispatching events for 800

[2025-08-20 02:03:03.725] [0007]   2nd generation collection count: 5
[2025-08-20 02:03:03.725] [0007]   Total memory allocated: 15521656
[2025-08-20 02:03:03.725] [0007]   Waiting for request event
[2025-08-20 02:03:03.834] [0007]   2nd generation collection count: 5
[2025-08-20 02:03:03.834] [0007]   Total memory allocated: 15529848
[2025-08-20 02:03:03.834] [0007]   Waiting for request event

Now that where it is getting weird.
When we execute the same code on the same machine as a User and not as System the connection can be build up (like we want to). We still see the messages for a few times but it generally works.
When we execute the same code on a different machine with the same proxy and in the same network and with the same operating system Windows Server 2019 (Build 17763) the code works in background as System and in foreground as a User.
Maybe I overlook something but I can't explain why that happens. In the old version we never had that issue.

I hope you can help me identify the issue if you need more information please tell me what you need.