v0.8.0

What's new

A slow drive is now explained all the way down. When a disk (especially a hard drive) makes the PC hang, 0.8.0 answers what exactly Windows was waiting for:

What the stuck request was, and who was stuck behind it

• What it was: a program's own code or memory being read back from disk, the file cache fetching or writing a file, the file system's own bookkeeping ($Mft: something was listing or creating lots of files), or a file's contents.
• Who was waiting for it: the programs whose threads went to sleep on that drive and woke the moment the request finished, with how long they waited in total.
• Lock chains: when a program waited on a lock held by another program that was itself waiting on the drive, the report says so in one line.
• Head thrashing (hard drives): when several programs made the drive's head jump between far-apart places at once, so each got a fraction of the drive, the report names them.

Inside the drive, or waiting in Windows?

A small extra trace of Windows' storage driver times every request below the driver stack. Each slow request is split into time inside the drive and time waiting in Windows before it reached the drive, and drive retries, failed reads/writes and resets during the run are reported. A busy drive working through its queue is described as exactly that, not as a faulty drive. Drives that are not on Windows' StorPort driver (older USB "BOT" enclosures) are reported as not measured. --no-storage-trace turns it off.

Which drivers were in the path

The trace now carries module-level call stacks for disk requests and slow page faults: driver names in call order, never function names. A slow request says which drivers it went through, and the disk finding lists the file-system filters (antivirus, backup, cloud sync, encryption) in the path of the slow requests. Being in the path is never called the cause, since every file access on Windows passes through several filters, and Microsoft Defender is never something to turn off.

--deep also records where every waiting program was blocked ("was blocked in FLTMGR.SYS -> Ntfs.sys"). It costs more (on a busy 32-thread PC, about 120,000 extra events a second and roughly twice the tool's own processor use), so it is opt-in and off in light mode.

Fixes

• Privacy: paths in the Recycle Bin printed the Windows account's security ID and the names of files inside deleted folders, and a file whose name started with $ made its folder path public. Both are closed.
• A hard drive kept busy seeking between programs was blamed on "the drive itself, its cable or its firmware"; it is now reported as busy, with the programs named.
• Ordinary file reads through the file cache were described as "paging", which reads like a memory problem; they are now described as the file cache fetching the file.

Cost

Measured on a 32-thread PC under heavy disk load: the storage trace adds about 750-1,750 events a second and the default call stacks about 1,000, against roughly 250,000-370,000 a second the tool already records; neither changed the tool's own processor use measurably, and no events were lost. The report's "THIS TOOL'S OWN COST" block shows the numbers for your PC.

Known limits

Lock chains, drive retries and resets, and a filter's own code showing up in a slow request's path have been tested only on recorded and synthetic data: they did not occur on the test PC. If a report looks wrong, please open an issue and attach it.

Verifying this download

gh attestation verify WTFIsStalling.exe --repo Tyberious/WTFIsStalling proves the file was built by this repository's release workflow from the tagged commit; sha256sum -c SHA256SUMS.txt checks the files. The executables are not code-signed yet, so SmartScreen may warn: More info -> Run anyway. If an antivirus blocks the download, please open an issue with the detection name.

Download

WTFIsStalling.exe is the app. wtfis-cli.exe is the same engine for the console.