Hartmut Birr wrote:
If a handle is created, the reference count of an object is dropped to zero. If an object is dereferenced we must look to the handle and the reference count.
after an object was created the reference counter should be 1. dereferencing that object directly after it was created should decrement it to 0 and delete it. the handle count should match the number of handles that exist for the object. When creating the first handle the reference counter should be incremented by 1, when deleting the last handle to the object it should be decremented by 1. For additional handles it should remain unchanged. I implemented this behavior in a local branch that completely replaces the handle implementation using generic executive handle tables. But i still have to track down a few bugs.
If we increase the reference count at the first created handle and decrease it on the last deleted handle, it is not necessary to check the handle count in ObDereferenceObject or related functions.
As mentioned above I implemented this behavior in my local tree.
They look for an existing sub key object. If one is found, the parse routine reference this object and return it. But this is not correct. The parse routine should only use and reference this existing object, if the reference count is greater than zero.
This doesn't sound right, the reference count should never be zero because then the object should be deleted, which means accessing it would be dangerous. The object in any case needs to be removed from the list before it gets deleted.
My idea is to split the data for the key object and the key object itself. The parsing routine creates the data only once, but it creates for each request a seperate key object.
I don't really understand the advantage of this. For file systems it's obvious because these objects represent data streams with different offsets, ... But i don't really understand how it could be useful for registry key objects.
Best Regards, Thomas