Windows XP acts strangely when hard drive is being heavily used

"Note: I'm assuming you have a spinning disk drive here. Performance metrics in these areas differ greatly for solid-state storage.

While a modern drive can sustain many tens of Mbytes per second when performing bulk reads and writes, both the operations you describe involve at least two locations on the disk so there is a lot of head movements involved. The latency of head movements has a massive effect on throughput because every time the drive needs to move the heads there is a delay in actually kicking them to the right place, a delay waiting for them to settle, and then a delay waiting for the right part of the disc to spin past. These delays are small on the own (not even 10ns per movement in total on average for most modern drives) but if the drive can push 100Mbyte/sec in full flow 10ms each movement wastes the time of 1Mbyte of data transfer. With a lot happening the drive can easily spend more time moving the heads around than it spends actually reading and writing data (read for a couple of 10s of ms, move head, read from there for a bit, move head, write for a few ms, move head...).

As you are defragmenting the drive the utility spends most of its time reading from one place on the disk and writing to another, a small number of blocks at a time. Extracting content from a par protected file set is even worse as there are at least two files being read (a source file and one or more parity files) as well as the output file being written to. Even just a simple copy operation on a large file has the effect. All this is excluding the head movements needed to keep directory structures and free-space maps up-to-date as blocks are moved and/or files extended. Running a VM can be similarly demanding depending on what the VM is doing at the time (and the VM will reduce the RAM available on the host machine to use as cache/buffers which may worsen the situation, and any write operation in the VM can be much more demanding than the same operation on the host directly especially if you use ""growable"" virtual drives).

With all this going on, if a GUI application needs to ask for even a little I/O it may get queued behind all the other stuff that is going on. Unless the application is fully multi-threaded this is likely to cause it to ""block"" waiting for the I/O operation to complete meaning it is not in a position to response to any messages (like ""the user clicked you here"") in the Windows event queue until it gets its turn. The more going on at once, the worse it will get, and you will not notice it in the ""CPU busy"" readings because the CPU isn't busy - it is sat waiting for IO operations to complete most of the time in these circumstances.

If you have two or more drives you can greatly reduce the effect this has on you by spreading the load over the drives. If you VM is on a separate drive from your primary OS they won't compete for I/O servicing when the VM is busy while the host is defragmenting the system partition. Also, extracting an archive from one drive and writing the output to another will be noticeably faster than extracting it to the same drive because the read operation is not directly competing with the write operation for head positioning on the one drive."

It honestly sounds like you're doing too much all at once. What you're seeing is a bottleneck - the harddrive is being asked to do several things at once (some with more priority than others) so things like GUI clicks are "waiting" for their turn to be processed.