No, not that thread, it was some other thread on the forum. In the one you mentioned I simply posted what I got until the moment. The problem of speed was side effect, not the real problem. The side effect was there to solve the thread stucking problem.
I can't find it, could you help? I'd like to get a broader view.
The problem is that NtQueryInformationFile gets access denial on some files. There are 2 issues with it:
1. There are some handles that can't be unlocked. I *guess* that these are some system files, it never caused me any problems. That's why I'd like to know what more knowledgeable people say about it.
2. On access denied it hangs. Yes, doesn't return at all. Therefore you always call NtQueryInformationFile in a separate thread that you can just kill after you decided that it took too long. You have to wait, that's why ForceDel is slow.
I don't know about resource leaks that you are talking about
_beginthread returns uintptr_t.
TerminateThread takes HANDLE, so giving it uintptr_t is mixing different things that currently happen to be the same.
You can't safely assume that _beginthread will always relay on CreateThread or that it doesn't store some information by itself.
, and if I remember correctly (it was about 2 years ago) I started without threads, thread was there because of stucking.
Yeah, right, I don't believe you anyway, this bug is too characteristic.
But it doesn't matter, let's skip this part.
So, what do you want to say ? Did you succesifully solved the stucking or u sucessifully killed the stucked threads ? In any case I downloaded your utility and will give it a longer try.
I just do 2 things:
1. Find handles to all locked files at the same time. All practical solutions (i.e. FileAssissin) do the same.
2. I do the waits simultaneously.
Simple and works great.
Its pitty it doesn't accept command line parameters.
It does. F1.