Whoa. Looks like ATI might have a major bug in their 4.10 Cats then.
I've encountered similar issues, when trying to make .PAR2 files using QuickPAR. The HD would start thrashing like MAD, and yet, CPU utilization, as well as virtual-memory usage by the program, were very small, on the order of nothing running at all. (This is under W2K SP2.) It was almost like there was a "ghost in the machine" taking over, and thrashing the HD.
What I believe was happening, was that, because of the size of files that I was trying to create the PAR2 files for (CD-sized, I think - 690MB Ghost split images), that QuickPAR was attempting to allocate/commit a virtual-memory address space much larger than, well, anything. I think on the order of 10 gigabytes worth of VM space. Also, when it starts to work, it attempts to "test memory", which I assume based on observed behavior, means that it naively allocates a huge span of virtual-memory, and then attempts to read/write it first, before using, to prevent data-corruption in the generated output files.
The reason that the HD was thrashing, was indeed that it was paging madly. The reason that the VM utilization of the program was very low, as shown by Task Manager, was that it was not
application VM that was getting thrashed/paged, but
the system-level virtual-memory page tables themselves!.
I suspect that this may be the case with the ATI drivers as well. They are well-known to have issues with excessive page-table entry allocation in certain cases, which is what causes the "delayed write failure" issue in XP, because W2K and XP's behavior WRT to page-table entry allocations appear to be different - W2K pre-allocates them, XP lazy-allocates them on-demand. (At best that I can figure, based on the observation on how they perform - not based on any sort of code analysis - so I could be quite wrong here.) Additionally, I feel that this is the same reason that PunkBusters causes long "pauses" on XP, but not on W2K - because when it fires, and attempts to scan system RAM for "cheat programs", it has to set up a secondary virtual-memory mapping, pointing to the real system RAM, which causes the immediate lazy-allocation of a
huge number of PTEs, which causes the system to pretty-much freeze-up for a period of time until the allocation is finished. (That's my theory, anyways.)
I believe that these sorts of issues, are also why MS is moving towards pushing for use of their "Universal GART 3.0/3.5 driver", instead of vendor/chipset-specific ones, because they can in some cases cause significant issues.
This issue in specific may also be related to why so many people have reported problems running games like COD using the 4.10 Cats. I plan on never installing them, based on so many reports of problems. (Like
this thread.)
