Handling large number of file in Visual Basic 2008

750 threads would NOT make the thing better. It would probably bog it down quite a bit.

Dotnet has the FileSystemWatcher.

I don't know how well it would work with 750 of them. I would think it would bog down things.

In my mind a balance would be better.  Consider a thread pool of 10-15 worker max. One thread should control the rest by assigning jobs to them.  That way 10-15 threads are looking at different places.
Using 15, that means that (750/15)=50 iterations would have all 750 done...more or less.  You will need to play with the number as too many threads are counter productive. Find the optimum number and let it run.

Of course if you are real ambitious and have multiple computers sitting around doing nothing, you could write some remoting objects that sit on various computers and have your main computer tell each of them what to do.  10 computers, each running 10 threads, means 100threads processing.  In this case, you might just have each of the 10 computers looking at 75 folders using 10 threads. This would make it super quick.  It just depends on what resources you have and how long you have to process it.

If it just needs to get done in a decent amount of time, you may just use one computer with 10 threads or so.  Maybe each of the thread, either deletes the file itself, or adds it to a queue where another thread watches the queue and deletes everything in it.  I'm not sure which way would be quicker...I do know that the thread finding it would be free to keep looking as soon as it made a string entry in a queue...which would take less time than file I/O.