Whenever someone kills an application because it is hung we get a little report with the stack and some other information (if the user chooses to send it). About 1% of the reports for IE are from users who have killed IE (or the Internet Control Panel) while it was clearing the cache. This is only slightly related to index.dat; I am using this series of postings as an excuse to talk about it on the assumption that someone might find it interesting.
In IE, Tools->Internet Options->Delete Files…->OK. Depending on how big you have set your cache and how long it has been since it was last cleared, this little operation can take a long time. I have personally seen it take as long as 20 minutes, which is a long time to stare at the little hourglass cursor. Of course the Internet Control Panel dialog is modal to the IE window, which means you cannot get back to whatever you were doing in the IE window until it is done. And if you click on things like the title bar, etc, as most people do when some program is taking an infuriating amount of time to accomplish something, Windows appends the [not responding] text to the title text. So people kill it.
The moral of this story is known to us in advance, I think: do not do blocking stuff on the UI thread.
It is an interesting problem though. The solution is not as straight-forward as one may initially think. The obvious thing to do is to spin up a background thread and have the cache-clearing done on the new thread. Assume that has been done; you open IE, clear the cache, the thread kicks off, you close the inetcpl, you close IE, you shutdown your computer. Did the cache get cleared? You asked for it to be cleared but you do not know for sure. What if it was still going 20 minutes later when you shutdown your machine? There are privacy implications here–I want to know when it has finished.
A proper solution would implement some sort of feedback, like file copy operations or the file download dialog in IE, that can live in a non-modal state even if the parent IE window has closed. Which is probably why nobody fixed it in previous releases–bigger fish to fry.