Preflight checks
Describe the bug
When using IKEv2, when the app tries to connect to a server, it seems to trigger a reload of the Windows DNS cache, which makes svchost.exe ("Dnscache" service) open the "hosts" file. (Edit: or it may be when reconnecting)
Then, WindscribeService.exe try to open the hosts file too with "ShareMode: None", meaning that it'll fail even if it's open in read mode by another process. I do believe it retries once when failing, but too quickly.
In my case, my hosts file has 3000 entries, so the Windows Dnscache service takes 5 seconds to parse all the rules. And it keeps the file open the whole time rather than just reading it once then parsing the rule (dumb optimization, but I probably can't get Microsoft to fix this :P)
This lead to WinscribeService.exe failing to open the file with ShareMode: None, because it just triggered a reload of the Dnscache, so svchost is keeping it open for 5 seconds, which seems to be shorter than the total retry time.
The connection fails and I get an error about the hosts file being read only (which is not the issue)
I have confirmed this with a Process Monitor trace :
23:18:13,4678582 svchost.exe 3156 CreateFile C:\Windows\System32\drivers\etc\hosts SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened 0.0000262
23:18:13,8905332 WindscribeService.exe 7144 CreateFile C:\Windows\System32\drivers\etc\hosts **SHARING VIOLATION** Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: 0 0.0000728
23:18:16,6791670 WindscribeService.exe 7144 CreateFile C:\Windows\System32\drivers\etc\hosts **SHARING VIOLATION** Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: 0 0.0000705
23:18:18,4697920 svchost.exe 3156 CloseFile C:\Windows\System32\drivers\etc\hosts SUCCESS 0.0000124
23:18:20,5921331 WindscribeService.exe 7144 CreateFile C:\Windows\System32\drivers\etc\hosts **SUCCESS** Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: 0, OpenResult: Opened 0.0000593
23:18:13 : I click to connect the VPN
23:18:16 : I get the "hosts is read only" error (meaning it throws it after only one retry, 3 seconds after the initial failure?)
23:18:20 : I click to try again, and by then svchost.exe is done so it works
This is pretty bad because sometimes, this happens again on it's own (maybe the app try to change server or refresh DNS), so suddenly Windscribe will throw the "hosts file is read only" error silently and disconnect, and I lose internet until I click the tray icon then click the error to have it try again. I keep on losing internet.
Operating system
Windows 11
OS details
Windows 11 25H2 amd64
App version
2.23.12 amd64
Steps to reproduce
- Have a hosts file with 3000+ entries
- Set IKEv2 as preferred protocol
- Try to connect (Edit: reconnect?) to the VPN
Expected behavior
The app shouldn't fail to open the hosts file due to a DNS cache reload it triggered. Maybe don't ask for Share: None, or retry for a longer time.
Actual behavior
The app can't open the hosts file because of the DNS cache reload it triggered, not expecting it to take more than 3 seconds.
Debug log or username
Nothing relevant in the log apart from this I think :
{"tm": "2026-07-26 22:45:16.171", "lvl": "error", "mod": "ikev2", "msg": "Can't modify hosts file"}
But I'll attach the file anyway.
WSlog.txt
Is this a regression?
Not sure
Screenshots
Additional context
No response
Preflight checks
Describe the bug
When using IKEv2, when the app tries to connect to a server, it seems to trigger a reload of the Windows DNS cache, which makes svchost.exe ("Dnscache" service) open the "hosts" file. (Edit: or it may be when reconnecting)
Then, WindscribeService.exe try to open the hosts file too with "ShareMode: None", meaning that it'll fail even if it's open in read mode by another process. I do believe it retries once when failing, but too quickly.
In my case, my hosts file has 3000 entries, so the Windows Dnscache service takes 5 seconds to parse all the rules. And it keeps the file open the whole time rather than just reading it once then parsing the rule (dumb optimization, but I probably can't get Microsoft to fix this :P)
This lead to WinscribeService.exe failing to open the file with ShareMode: None, because it just triggered a reload of the Dnscache, so svchost is keeping it open for 5 seconds, which seems to be shorter than the total retry time.
The connection fails and I get an error about the hosts file being read only (which is not the issue)
I have confirmed this with a Process Monitor trace :
23:18:13 : I click to connect the VPN
23:18:16 : I get the "hosts is read only" error (meaning it throws it after only one retry, 3 seconds after the initial failure?)
23:18:20 : I click to try again, and by then svchost.exe is done so it works
This is pretty bad because sometimes, this happens again on it's own (maybe the app try to change server or refresh DNS), so suddenly Windscribe will throw the "hosts file is read only" error silently and disconnect, and I lose internet until I click the tray icon then click the error to have it try again. I keep on losing internet.
Operating system
Windows 11
OS details
Windows 11 25H2 amd64
App version
2.23.12 amd64
Steps to reproduce
Expected behavior
The app shouldn't fail to open the hosts file due to a DNS cache reload it triggered. Maybe don't ask for Share: None, or retry for a longer time.
Actual behavior
The app can't open the hosts file because of the DNS cache reload it triggered, not expecting it to take more than 3 seconds.
Debug log or username
Nothing relevant in the log apart from this I think :
{"tm": "2026-07-26 22:45:16.171", "lvl": "error", "mod": "ikev2", "msg": "Can't modify hosts file"}
But I'll attach the file anyway.
WSlog.txt
Is this a regression?
Not sure
Screenshots
Additional context
No response