Run EXEC sp_configure 'show', 1

reconfigure

EXEC sp_configure

Verify Priority Boost is set to 0, verify Max Server Memory (MB) is set below physical memory after leaving multiple GB for the OS and other memory-hungry processes, and verify Set Working Set Size is set to 0. If values are different from my verification values, consider the best practice values for each setting (support.microsoft.com is a good place to start). It may be this system needs settings that are not considered a best practice, but more typically it is someone else that had changed them long ago, saw no harm, left them that way, only to come back and bite you with SQL Server's IOCP_LISTENER going deaf & unyielding (likely due to its un-lockable memory ending up in the paging file).

Use perfmon.exe to monitor every Process' Working Set and Private Bytes counters, and sqlservr.exe's %Privileged Time (and %User time). Sample those counters over the system's problematic work periods (I prefer at most a 5 sec polling interval, because a paging event can last 10 seconds or less). Based upon that monitoring, consider implementing Lock Pages In Memory, but realize that if you give SQL Server all the Memory, then the OS and all other processes will get nothing. If the Lock Pages In Memory Advanced Windows Right has already granted to sqlservr.exe, perhaps similar long term monitoring overlooked the cause you are experiencing now. If LPIM is already set and if Max Server Memory was set too high, less physical memory for the IOCP_LISTENER's thread's stack space can be a result. A paging event does not have to have happened at the time when the IOCP_LISTENER dumped. A paging event could have happened minutes before the dump.