Thomas Weidenmueller schrieb:
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.
This doesn't sound right, but the current implemention of key objects uses this way.
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.
I see two ways to solve the wrong referencing problem. The first one is, we create the key object and reference it again. One reference is for holding the key object in the parent key structure valid. The second reference is for the caller (ObFindObject..) and he could do what he want with it. The problem is, the first reference is never removed and it is not possible to dereference (delete) the parent. The other way is a special data structur between the parent key and the child keys. This structure has an internal reference count, which is incremented when a child key is created and decremented when a key is deleted. The create or delete operation occurs only if the hive is looked. The creating or deleting of this data structur has nothing to do with the real reference count of the object. It is always triggered by the create (parse) or delete operation.
- Hartmut