[Bug]: Windows client stuck in runaway SQLite polling loop (massive etilqs temp file I/O)

[Ashley-Young101]

Summary

Environment

• OS: Windows 11
• DefGuard Client Version: 1.6.7 & 1.6.8

While idling, the DefGuard client began consuming massive amounts of system resources, with Windows Task Manager reporting roughly ~40 MB/s of continuous "Disk" usage from the background process.

Steps to reproduce

Because standard Resource Monitor did not show this traffic, I ran a trace using Sysinternals Process Monitor (ProcMon).

In a time slice of just 9.1 seconds, the client executed 148,056 individual disk operations (primarily ReadFile and WriteFile).

The trace revealed the client was trapped in a runaway polling/query loop against its local SQLite database, resulting in massive data spills to temporary files. The operations heavily targeted:

C:\Users[User]\AppData\Roaming\net.defguard\defguard.db (Over 16,000 hits)

C:\Users[User]\AppData\Local\Temp\etilqs_[random] (Over 130,000 hits across several SQLite temp files)

Expected behavior

Not consuming a large portion of my system resources on I/O.

Actual behavior

Working PC very hard on the IO amount, other process incredibly laggy.

Logfile.CSV

---

I renamed the .db file and restarted the defguard client. After re-enrolling, it now seems to be working fine. I do have the old DB, and I'm willing to investigate further if support reach out.

Defguard version

Windows Client: 1.6.7

Environment details

Core, Gateway etc: Ubuntu. Client: Windows 11

Deployment / install method

One-line script

Relevant logs / output

Relevant configuration (redacted)

[j-chmielewski]

Thank you for reporting this, @Ashley-Young101.

We did release a fix for this issue in v1.5.2. That release introduced more aggressive pruning of the statistics tables, which were the primary cause of the high disk IO. At the time, we also prepared a troubleshooting guide for affected users: https://docs.defguard.net/support-1/troubleshooting-guides/desktop-client/high-disk-usage.

That said, something still appears to be wrong in your case.

It would help a lot if you could provide a bit more information:

• how large is the old database file?
• how many instances are configured in the client?
• how many locations does each instance contain?
• do you usually keep multiple locations connected?
• do you usually keep the VPN connected most of the time?

Could you also install sqlite3 and run the following queries against the old/large database?

• select count(*) from location_stats;
• select count(*) from tunnel_stats;
• select * from location_stats order by id desc limit 10;
• select * from tunnel_stats order by id desc limit 10;

That should help us determine whether the issue is still related to statistics growth or if something else is going on.