Disclaimer: AI was used for the write-up, but I am a developer and have generally validated this and the issue has been resolved.
Insync uses one full CPU core at idle after a filtering driver stops (Windows)
Insync’s core event loop can enter a permanent busy loop on Windows, using one full CPU core
until Insync is restarted. It happens with nothing syncing. I can trigger it by turning off
protection in AdGuard for Windows, which interrupts connections on the machine. Insync does not
recover without a restart.
### Environment
- Insync 3.8.11.50514 (Google Drive account)
- Windows 11 Pro, build 26300, 16 threads
- AdGuard for Windows 8.0.5587, using its network driver
### Steps to reproduce
1. Run AdGuard for Windows with protection on and `Insync.exe` not excluded from filtering.
2. Start Insync and wait for it to go idle.
3. Turn AdGuard protection off.
4. Check Insync’s CPU use in Task Manager.
### Expected and actual results
- **Expected:** Insync stays idle or recovers on its own.
- **Actual:** `Insync.exe` stays at about 6% CPU (one core of 16 threads) until it is restarted.
Turning AdGuard protection back on does not clear it.
### Test results
| Time | Event | Insync CPU |
|—|—|—|
| 18:15:20 | Insync idle for 41 minutes, AdGuard protection on | 0.00 core |
| 18:15:22 | AdGuard filtering stops | |
| 18:15:35 | Sample | 0.82 core |
| 18:15:50 | Sample | 0.96 core |
The same loop also started on its own when AdGuard restarted its filtering or service during
normal use, including an AdGuard service restart at about 16:05 on the same day.
After I excluded `Insync.exe` from AdGuard’s filtered applications and restarted Insync, the same
test did not start the loop. Insync stayed at 0.00 core through a stop and restart of filtering.
I have run this test once.
### What the process is doing
I inspected a looping process with Frida and with Python stack dumps through `python37.dll`.
- Only one thread is busy: `CoreLoopThread`.
- That thread makes only `NtDeviceIoControlFile` calls on one socket, alternating an AFD poll
(`0x12024`, `select`) and an AFD receive (`0x12017`, `recv`), about 71,000 times per second each.
- There is no file transfer. Windows counts about 200,000 “other” I/O operations per second for
the process.
- The Python stack cycles through:
ideskasync/coreloop.py run_loop
-> asyncio \_WindowsSelectorEventLoop.\_run_once
-> select
-> \_read_from_self
### Likely cause
The event loop’s self-pipe is a TCP loopback socket pair. In the process I inspected, it was
`127.0.0.1:53501` and `127.0.0.1:53502`.
- Python still treats the pair as connected, but the Windows TCP table has no such connection.
Port `53502` is listed only as `Bound`.
- `select` therefore always reports the socket as readable, `recv` returns no data, and the loop
immediately runs again.
- Nothing rebuilds the self-pipe. Restarting Insync creates a new one, which clears the problem.
Insync’s loopback pairs show as `Established` in a healthy process after the AdGuard test with the
exclusion. In a looping process, they show only as `Bound`.
### Request
Please make the core loop detect a self-pipe that has failed, for example when the socket is
readable but `recv` returns no data, and rebuild it or restart the loop.
AdGuard is how I trigger this, but other software or events that break loopback connections may
cause the same failure.
### Workarounds
- Restart Insync. This clears the loop until the next trigger.
- Exclude `Insync.exe` from AdGuard’s filtered applications, then restart Insync.