Open Handles v2

[stdedos]

Intersting:

• What is a big number of handles?
• How do I check that? Open each process manually? 😀

[dmex]

What is a big number of handles?

256 GB

How do I check that? Open each process manually?

One of the processes is going to have an abnormally high memory usage/non-existent handle table.

[stdedos]

What is a big number of handles?

256 GB

Strange - I had a bulk of 16M, but definitely not anywhere close to G.
Unless, you are talking of the combined open file's size (since you prepended with GB and not only G)

[dmex]

Unless, you are talking of the combined open file's size

I'm referring to the byte size of the buffer required to copy the handle information.

I've removed the buffer limits for handle searches in the latest nightly... You should be able to use the search feature when there are large amounts of handles but it'll require more memory usage.

[stdedos]

I've removed the buffer limits for handle searches in the latest nightly... You should be able to use the search feature when there are large amounts of handles but it'll require more memory usage.

No, I didn't mean that this is something that was to be done necessarily 😕

I just saw it, and I was wondering what is it?
When I killed the app that carried the 16M handles (it wasn't specifically services.exe), I noticed a considerably faster enumeration performance.

Now I also have a new "Handles" column, among the other 30 that exist too 😂

[dmex]

I didn't mean that this is something that was to be done necessarily

The buffer length was multiplied by 2 so you were only able to actually utilize half of the buffer before exceeding the limit. The changes I made now use the actual return length allowing dynamically sized buffer lengths which will signifigantly reduce the memory requirements when querying handles but also allow querying larger amounts of handles.

When I killed the app that carried the 16M handles (it wasn't specifically services.exe), I noticed a considerably faster enumeration performance.

You need to have KPH enabled for faster enumeration since the NTAPI requires first duplicating the handle before you're able to query the name of the handle while KPH can just query the name directly. There isn't much else you can do to improve performance without the driver... The difference is basically:

KPH: Reference process -> Query handle name -> Dereference process
vs
NT-API: OpenProcess -> Reference process -> Duplicate handle from process -> Dereference process -> NtClose -> NtQueryObject -> Reference process -> Query handle name -> Dereference process

'16M handles' would obviously take time since every last handle has to go through a reference/deference before querying the name. It could be optimized such that the handle queries are batched into groups instead of the current single queries so you would only need a single reference before querying all the handles at once?