Hello Everyone -
I am working on a driver that uses CmRegisterCallback() to register for callbacks to monitor registry changes. It’s all happy and seems to behave just like the documentation says until I make changes to the registry using the command line tool Reg.exe. Commands like “reg add xxxx” and “reg delete xxx” seem to generate callbacks in my driver like one would expect.
However, the use of other commands like “reg load” or “reg restore” (which use hive files created by “reg save”) seems to be able to make some pretty significant modifications to the registry without my driver seeing a single callback when it does.
I have searched far and wide for any answers to this with no luck. My only theory at this point is that somehow that utility (provided by Microsoft) is either able to modify the registry files direcly, or uses some other less/un documented APIs that subvert the registry callback mechanism built into the OS. (XP/2K3/Vista).
Does anyone have any ideas about what might be happening here? Any ideas about how my driver can see those changes when they occur?
Thanks in advance for any replies - Much appreciated!
> However, the use of other commands like “reg load” or “reg restore”
(which use hive files created by “reg save”) seems to be able to
make some pretty significant modifications to the registry without
my driver seeing a single callback when it does.
They use RegLoadKey and RegSaveKey, which works with entire
registry hive.
L.
Hello Andy
Like Ladislav said these use the load/save registry api … and of course
there are no callbacks for these api (at least before vista). So I think you
might be out of luck here …
Best Wishes
Lyndon
wrote in message news:xxxxx@ntfsd…
> Hello Everyone -
>
> I am working on a driver that uses CmRegisterCallback() to register for
> callbacks to monitor registry changes. It’s all happy and seems to behave
> just like the documentation says until I make changes to the registry
> using the command line tool Reg.exe. Commands like “reg add xxxx” and
> “reg delete xxx” seem to generate callbacks in my driver like one would
> expect.
>
> However, the use of other commands like “reg load” or “reg restore” (which
> use hive files created by “reg save”) seems to be able to make some pretty
> significant modifications to the registry without my driver seeing a
> single callback when it does.
>
> I have searched far and wide for any answers to this with no luck. My
> only theory at this point is that somehow that utility (provided by
> Microsoft) is either able to modify the registry files direcly, or uses
> some other less/un documented APIs that subvert the registry callback
> mechanism built into the OS. (XP/2K3/Vista).
>
> Does anyone have any ideas about what might be happening here? Any ideas
> about how my driver can see those changes when they occur?
>
> Thanks in advance for any replies - Much appreciated!
> - Andy
>
Thanks everyone for your help.
The RegRestoreKey, RegLoadKey, and RegReplaceKey APIs have been around since Win9x. What I don’t understand is how Microsoft could implement a Registry Callback Mechanism that is so horribly incomplete! I know this isn’t the place to whine about MS, but it’s really frustrating. In any case, it seems that the ONLY way to truly monitor all changes to the registry (pre-Vista) is to hook system APIs, something I hate having to do.
This forum is filled with reams of advice and warnings about hooking the SSDT, most of which I agree with. If there’s another way, please tell me about it. If not, I’m off to build yet another commercial driver that is OS version dependent, can’t be safely unloaded, and will get blamed for crashes that happen when some other driver who hooked the same table entries before me decides to go unload itself 
Thanks again to all for responding to my post, and for all of the fantastic information available here in this forum.
Andy,
I am one of the strongest voices against hooking, but unfortunately you
are right about the registry API’s. Pre-Vista they are worthless for most
applications, and you will have to hook. Unfortunately, I see no movement
by Microsoft to put the Vista registry support in older OS’es, which means
that we still will have this mess for a long time.
Two recomendations on the hooking:
-
First use MmGetSystemRoutineAddress to test for the API’s you
need, if present please don’t hook.
-
While it is a minor stopgap, also consider corralling all the
processors (for instance invoking a DPC on each CPU and waiting for a
counter to reach the CPU count) before hooking. It will not defend against
the people who just stupidly hook, but it increases the chance that your
hooks will all be at the same altitude versus other drivers.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntfsd…
> Thanks everyone for your help.
>
> The RegRestoreKey, RegLoadKey, and RegReplaceKey APIs have been around
> since Win9x. What I don’t understand is how Microsoft could implement a
> Registry Callback Mechanism that is so horribly incomplete! I know this
> isn’t the place to whine about MS, but it’s really frustrating. In any
> case, it seems that the ONLY way to truly monitor all changes to the
> registry (pre-Vista) is to hook system APIs, something I hate having to
> do.
>
> This forum is filled with reams of advice and warnings about hooking the
> SSDT, most of which I agree with. If there’s another way, please tell me
> about it. If not, I’m off to build yet another commercial driver that is
> OS version dependent, can’t be safely unloaded, and will get blamed for
> crashes that happen when some other driver who hooked the same table
> entries before me decides to go unload itself
>
> Thanks again to all for responding to my post, and for all of the
> fantastic information available here in this forum.
>
> - Andy
>
Hi Andy
The pre-vista registry callbacks must be there for a reason, there must ahve
been requirements, use cases - perhaps your requirements, use cases were not
among them. Situation normal 
Good luck
Lyndon
wrote in message news:xxxxx@ntfsd…
> Thanks everyone for your help.
>
> The RegRestoreKey, RegLoadKey, and RegReplaceKey APIs have been around
> since Win9x. What I don’t understand is how Microsoft could implement a
> Registry Callback Mechanism that is so horribly incomplete! I know this
> isn’t the place to whine about MS, but it’s really frustrating. In any
> case, it seems that the ONLY way to truly monitor all changes to the
> registry (pre-Vista) is to hook system APIs, something I hate having to
> do.
>
> This forum is filled with reams of advice and warnings about hooking the
> SSDT, most of which I agree with. If there’s another way, please tell me
> about it. If not, I’m off to build yet another commercial driver that is
> OS version dependent, can’t be safely unloaded, and will get blamed for
> crashes that happen when some other driver who hooked the same table
> entries before me decides to go unload itself
>
> Thanks again to all for responding to my post, and for all of the
> fantastic information available here in this forum.
>
> - Andy
>
“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Hi Andy
>
> The pre-vista registry callbacks must be there for a reason, there must
> ahve been requirements, use cases - perhaps your requirements, use cases
> were not among them. Situation normal
>
Actually, the pre-vista were there for RegMon which at the time they were
developed had gaping holes because it did not monitor the save/restore of
hives. I really wish Microsoft would look at the newsgroups and engage some
of the commentators on these various problems with an NDA so “the solutions”
could be reviewed.
This was part of the strength of KMDF, they got a lot of input from the
community in the beginning.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply