Cannot open file "...\winscp.ini". The process cannot access the file because it is being used

I am getting this error using NET Assembly.
In documentation, its stated that this type of use defaults to /ini=null

https://winscp.net/eng/docs/config

No Configuration
With /ini=nul command-line switch, WinSCP starts with the default configuration and does not save the configuration on exit. That is particularly useful for scripting, to make sure that the script always starts with all defaults. This is also the configuration mode used by WinSCP .NET assembly.

We have 10 thread that copy stuff in parallel and this popups up here and there. I know I can set it to read only but this is not something I should do in this scenario.
This looks like a bug

The ini file contains:

WinSCP .NET assembly does not use any INI file by default.
If yours does, you must have told it explicitly via deprecated Session.IniFilePath property:
https://winscp.net/eng/docs/library_session#inifilepath
Did you? If you did, remove it. If your INI file is (nearly) empty, you do not need it anyway.

No, I don't have that option anywhere, that's why I think this is a bug
There isn't IniFilePath anywhere in code.

In attachment screenshot of Session object and it shows IniFilePath as null

Please set Session.DebugLogPath and Session.SessionLogPath and post both logs.

File are in attachment.

I noticed /ini=nul
Keep in mind that my current setup included pre-creating wincmd.ini and setting it to readonly via this PowerShell line:
I used content of this file as was generated by WinCmd due to this bug.

There's no "Cannot open file..." error in any of the logs.
Post any evidence of the error coming from WinSCP. I do not see any now.
What does "wincmd" (Total Commander) have to do with this?
Why are you even creating the INI file? What are you trying to achieve by that?
Isn't it actually your PowerShell code that produces the error?

Wincmd was a typo, I meant winscp.

The error I got few times was:

Cannot open file "C:\tbass\rest\winscp.ini". The process cannot access the file because it is being used by another process

The solution was to pre-create winscp.ini file during deployment as was reported here on forum several times as solution for this (it works, I didn't get error after that) and I did it with above PowerShell code. I can not give you logs from when error occurs because debug & session log make huge performance difference (x2) so I disabled it after I sent you the data and I don't want to wait for this error weeks in production with such performance issue. You obviously can see in those logs that /ini=nul is there and I shouldn't get this error.

OK, but I cannot debug the problem without the logs. What about only session log for a start? It might not have that huge performance impact.

I think you have enough information. I don't use ini, but it gets created on the first run of my REST app that copies files to SCP host anyway. Both logs show that it is not used.

I reverted my code changes and will wait for it to appear up to 30 days... The session log IS slow in my case, the copying session now lasts 2-3 times longer. As soon as I disable log it goes down with the same workload.

Apart from me setting dummy winsp.ini during deployment procedure there were no other code changes. Our app creates reports in parallel and copy them on Linux host using queue workers with 8 threads. When this happens exactly 1 thread and its single job fails due to this error. For example, if I copy 1500 files, only one failed so far. The error appeared 2 times in a month and didn't single time when I set ini file to reed only.

Until we wait for it to happen, here is the animated gif of how session constantly creates winscp.ini. I delete it constantly and it appears. I show you at the end session.log for this ongoing session.

You can see that this session log is being used as its size is growing, and that winscp.ini creation time changes with each ls.

All this winscp.ini mingling during the execution didn't produce winscp.ini access error though by any thread and this is the reason why is so hard to catch it.

OK, so it seems to be easy to reproduce the creation of the INI file. That's good.
I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

I have added this issue to the tracker:
Issue 2066 – In .NET assembly or scripting with "nul" configuration, when WinSCP registry key does not exist, do not write statistics to INI file