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.