I am working with RegistryCallback routine.
This routine has three parameters , the second one specifies the type of registry operation and the third one specifies the structure which contains the parameters used in that registry operation.
For RegDeleteKey operation, the REG_DELETE_KEY_INFORMATION structure is supplied. First member of the structure, Object is a void pointer which points to a pointer to registry key object.
I would like to know , what exactly is the data type of this pointer to registry key object. I think it is POBJECT_ATTRIBUTES. But when I tried to read the PUNICODE_STRING, in this object attribute, I god BSOD.
Would someone tell, how to obtain (read) the information pointed by the Object parameter ?
I want to get the path to registry key which is to be deleted.
Thanks in advance.
It is a pointer to the CM Key object type, the kernel object that backs a registry key handle. You should treat it as an opaque pointer except for use by routines such as ObOpenObjectByPointer, in general.
? S
-----Original Message-----
From: xxxxx@yahoo.com
Sent: Friday, December 19, 2008 05:34
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Reading REG_DELETE_KEY_INFORMATION structure
I am working with RegistryCallback routine.
This routine has three parameters , the second one specifies the type of registry operation and the third one specifies the structure which contains the parameters used in that registry operation.
For RegDeleteKey operation, the REG_DELETE_KEY_INFORMATION structure is supplied. First member of the structure, Object is a void pointer which points to a pointer to registry key object.
I would like to know , what exactly is the data type of this pointer to registry key object. I think it is POBJECT_ATTRIBUTES. But when I tried to read the PUNICODE_STRING, in this object attribute, I god BSOD.
Would someone tell, how to obtain (read) the information pointed by the Object parameter ?
I want to get the path to registry key which is to be deleted.
Thanks in advance.
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Sorry, typo. It is a pointer to an object of the type CM Key.
? S
-----Original Message-----
From: Skywing
Sent: Friday, December 19, 2008 06:57
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Reading REG_DELETE_KEY_INFORMATION structure
It is a pointer to the CM Key object type, the kernel object that backs a registry key handle. You should treat it as an opaque pointer except for use by routines such as ObOpenObjectByPointer, in general.
? S
-----Original Message-----
From: xxxxx@yahoo.com
Sent: Friday, December 19, 2008 05:34
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Reading REG_DELETE_KEY_INFORMATION structure
I am working with RegistryCallback routine.
This routine has three parameters , the second one specifies the type of registry operation and the third one specifies the structure which contains the parameters used in that registry operation.
For RegDeleteKey operation, the REG_DELETE_KEY_INFORMATION structure is supplied. First member of the structure, Object is a void pointer which points to a pointer to registry key object.
I would like to know , what exactly is the data type of this pointer to registry key object. I think it is POBJECT_ATTRIBUTES. But when I tried to read the PUNICODE_STRING, in this object attribute, I god BSOD.
Would someone tell, how to obtain (read) the information pointed by the Object parameter ?
I want to get the path to registry key which is to be deleted.
Thanks in advance.
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks Ken.
Can you please tell the exact data type for CM Key object
I tried to find it in WDK but couldn’t get any information.
Not documented. It is an object manager object whose body is defined by Cm (the registry subsystem). The corresponding POBJECT_TYPE is not available externally (nt!CmpKeyType IIRC) as of Vista/Srv08. You should not try to directly modify the contents of the object as the object layout is subject to change without warning from service pack to service pack and OS release to OS release.
? S-----Original Message-----
From: xxxxx@yahoo.com
Sent: Saturday, December 20, 2008 07:59
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Reading REG_DELETE_KEY_INFORMATION structure
Thanks Ken.
Can you please tell the exact data type for CM Key object
I tried to find it in WDK but couldn’t get any information.
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
PVOID 
wrote in message news:xxxxx@ntfsd…
> Thanks Ken.
> Can you please tell the exact data type for CM Key object
> I tried to find it in WDK but couldn’t get any information.
>
>
>
>It is a pointer to the CM Key object type, the kernel object that backs a registry key handle. You should
treat it as an opaque pointer except for use by routines such as ObOpenObjectByPointer, in general.
But at least it is guaranteed that the handle from ZwXxxKey will give this CM object as a result of ObReferenceObjectByHandle.
Note that user mode RegXxx handles are not kernel handles, but some pointers to internal structures of advapi32.dll. This is because advapi32 is also the remote registry client.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Only remote registry handles have that property. Local HKEYs are kernel objects.
? S
-----Original Message-----
From: Maxim S. Shatskih
Sent: Sunday, December 21, 2008 04:04
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Reading REG_DELETE_KEY_INFORMATION structure
>It is a pointer to the CM Key object type, the kernel object that backs a registry key handle. You should
>treat it as an opaque pointer except for use by routines such as ObOpenObjectByPointer, in general.
But at least it is guaranteed that the handle from ZwXxxKey will give this CM object as a result of ObReferenceObjectByHandle.
Note that user mode RegXxx handles are not kernel handles, but some pointers to internal structures of advapi32.dll. This is because advapi32 is also the remote registry client.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Then why RegCloseKey is used for them and not CloseHandle?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Skywing” wrote in message news:xxxxx@ntfsd…
Only remote registry handles have that property. Local HKEYs are kernel objects.
Exactly to give the subsystem the chance to sort out what type of handle it
is, so it either does a system call to ZwClose (local) or goes inside an RPC
mess (remote).
//Daniel
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
Then why RegCloseKey is used for them and not CloseHandle?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Skywing” wrote in message news:xxxxx@ntfsd…
Only remote registry handles have that property. Local HKEYs are kernel
objects.
Well, there are the magic number pre-defined root key “handles”, performance
data IIRC goes down a different path, then there are the remote handles
which leads to NdrClientCall2 … but otherwise for a regular plain old
local key handle I understood RegCloseKey boils down to NtClose.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
Then why RegCloseKey is used for them and not CloseHandle?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Skywing” wrote in message news:xxxxx@ntfsd…
Only remote registry handles have that property. Local HKEYs are kernel
objects.
Maxim S. Shatskih wrote:
Then why RegCloseKey is used for them and not CloseHandle?
Because the argument of CloseHandle is of
type HANDLE, and you have a HKEY.
Also, even for local registry, a HKEY may contain something cooked up by
win32, instead of HANDLE, for example:
#define HKEY_LOCAL_MACHINE (( HKEY ) (ULONG_PTR)((LONG)0x80000002) )
Only true kernel handles seem to get to the syscall level, there’s no
separate HKEY type in the kernel - only HANDLEs.
Regards,
–PA
To provide a uniform interface. RegCloseKey can tell if a handle is a remote registry handle (tag bits IIRC), and do thr right thing if so.
? S
-----Original Message-----
From: Maxim S. Shatskih
Sent: Sunday, December 21, 2008 10:06
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:Reading REG_DELETE_KEY_INFORMATION structure
Then why RegCloseKey is used for them and not CloseHandle?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Skywing” wrote in message news:xxxxx@ntfsd…
Only remote registry handles have that property. Local HKEYs are kernel objects.
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
> Because the argument of CloseHandle is of
type HANDLE, and you have a HKEY.
So, probably a helper advapi32 structure is involved even for local handles.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
No, remote registry handles have one of the low-order (tag) bits set as I recall. The object manager guarantees that no handle will have the two low-order bits set.
I recall that advapi32 uses one such tag bit to denote that a handle is a remote registry handle.
It is trivially easy to prove that local registry handles are kernel objects; simply use !handle on one in WinDbg.
? S
-----Original Message-----
From: Maxim S. Shatskih
Sent: Sunday, December 21, 2008 11:45
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Reading REG_DELETE_KEY_INFORMATION structure
> Because the argument of CloseHandle is of
> type HANDLE, and you have a HKEY.
So, probably a helper advapi32 structure is involved even for local handles.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Yes, least significant bit is tested - after checks for magic number
pre-defined root key handles.
“Skywing” wrote in message news:xxxxx@ntfsd…
No, remote registry handles have one of the low-order (tag) bits set as I
recall. The object manager guarantees that no handle will have the two
low-order bits set.
I recall that advapi32 uses one such tag bit to denote that a handle is a
remote registry handle.
It is trivially easy to prove that local registry handles are kernel
objects; simply use !handle on one in WinDbg.
– S
-----Original Message-----
From: Maxim S. Shatskih
Sent: Sunday, December 21, 2008 11:45
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Reading REG_DELETE_KEY_INFORMATION structure
> Because the argument of CloseHandle is of
> type HANDLE, and you have a HKEY.
So, probably a helper advapi32 structure is involved even for local handles.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
The Object parameter in REG_DELETE_KEY_INFORMATION structure points to object pointer which points to complete registry key path for the key being deleted. I want to get this path.
For Vista CmCallbackGetKeyObjectID function is available which gives the complete key path as a UNICODE_STRING. But it is not available for XP.
Is there any way to get this path in XP. If anyone knows of some undocumented function for this, then please let me know.
Well, it’s an object, so you could think about ObQueryNameString? I’d
generally say, the XP reg callbacks are very poor. That;s been quite a bit
discussed on ntfsd/ntdev over the last few years.
Good Luck!
wrote in message news:xxxxx@ntfsd…
> The Object parameter in REG_DELETE_KEY_INFORMATION structure points to
> object pointer which points to complete registry key path for the key
> being deleted. I want to get this path.
> For Vista CmCallbackGetKeyObjectID function is available which gives the
> complete key path as a UNICODE_STRING. But it is not available for XP.
> Is there any way to get this path in XP. If anyone knows of some
> undocumented function for this, then please let me know.
>
Thank you Lyndon.
My problem is solved using ObQueryNameString.