PodMaster is right. You cannot share objects across threads.

The answer may be to create a new instance of the scripting object in each thread. I haven't tried this, so you'll have to suck it and see, but I don't see any reason why it wouldn't work.

As for the free to wrong pool. Do you get these messages when the program closes down?

One note of caution. Multi-threading directory scans, especially if the all (or many of) the paths are on the same physical drive, will have rapidly diminishing returns in terms of performance. Each time a context switch occurs--ie. one thread gets switch for another by the scheduler--then the drive head will have to move to another part of the disk to scan the path for that thread, and then move somewhere else as the next thread takes its turn.

Moving heads between tracks is hugely more expensive than just waiting for the disk to roll passed the head, so the penalty can outweight the benefits. Additionally, reading another part of the disc can cause data already read from the disc into cache but not yet supplied to the program to be invalidated and discarded so that when the program does get around to asking for that information it has to be re-read.

Don't let that put you off trying, but don't be surprised if you find that whilst two or three threads improves performance that 4 starts to diminish it, and 5 really slows things up.

NOTE: Those numbers are just examples. The breakpoint could 6 or 8 or 2. Even just 1, but normally not.