OSError: [WinError 64] The specified network name is no longer available

[sentry-for-tribler]

Sentry Issue: TRIBLER-1FZ

OSError: [WinError 64] Указанное сетевое имя более недоступно
  File "asyncio\windows_events.py", line 562, in accept_coro
  File "asyncio\windows_events.py", line 808, in _poll
  File "asyncio\windows_events.py", line 551, in finish_accept

We have received many reports of this issue (the first one was received in 7.13.1-RC2.

EVENTS 71
USERS 29

[kozlovsky]

The error happens exclusively on Win32

[kozlovsky]

The Specified Name Is No Longer Available error may appear in one of several different ways when:

• Trying to access a network shared location on a Windows 10 PC from an older Windows computer.
• Attempting to access any network share using SMB (Server Message Blog) file-sharing protocol.
• Accessing any network device that supports SMB protocol.

If the system hosting the file uses a newer version of SMB unsupported by the client, it can lead to errors.

It can also happen when accessing the network share is blocked or interrupted by antivirus software or a firewall.

(source)

[kozlovsky]

I suspect the error can somehow be caused by a false alarm from the Microsoft Defender antivirus

[kozlovsky]

User comments on the issue:

• while viewing the files tab, system always crashes, the tab where you can choose what gets downloaded (source)

• when looking at the file tabe for the torrent it crashes (source)

• Nothing !!! (source)

• Edge Browser (source)

• Opened Edge browser (source)

• Tribler was just running on the background to acquire a few files (source)

• notebook battery power became very low (source)

[qstokkink]

Duplicate of #7759 and #6429. Closing in favor of older issues.

I can match the erroring socket's port to the http port, so it seems like the exact same root cause: the aiohttp library owns the socket but does not catch this error.

[drew2a]

@qstokkink
Well, it's not obvious to me that the newest issue should be closed while the oldest remains open. Anyway, this issue is more representative than the old one as it contains 71 events compared to 2 in the old one. At the very least, you should reassign the Sentry event to the old issue, not just close the newest one.

[synctext]

I can match the erroring socket's port to the http port, so it seems like the exact same root cause: the aiohttp library owns the socket but does not catch this error.

That would be awesome! So after 2 years we can finally re-produce this misery error! Solid material to add to application tester. I propose to use the oldest issue and re-open if the aiohttp library fix / error catching fails to address this issue. 27 affected users is a lot.