By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,573 Members | 3,017 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,573 IT Pros & Developers. It's quick & easy.

Odd registry behaviour

P: n/a
Hi,

can someone explain me this behaviour:

(steps to reproduce)
1. Open HKLM/SYSTEM\CurrentControlSet\Services\Eventlog\Applica tion
2. Look at the "Sources" value
3. Now create new key under the "Application"
4. The new key is magically added to the "Sources" value (along with "New
key #") when you refresh the view

And what is more strange, when you delete all the changes (the value is not
restored back when you delete the key) and do the steps again with the same
new key name, the "Sources" value is not modified.
And when you use different name for the new key, the "Sources" is again
modified and all the new keys that you created/erased somehow magically
reappear.

Regards, Jan

PS: Works for me on Win2k and WinNT (remotely modified from Win2k machine
with regedt32)
PS2: Also works when you use registry API to create the new key (I am
fiddling with services)

Nov 17 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Interesting! But not magic. :)

Using regmon from sysinternals.com you can see services.exe makes this
change... services.exe is (at least) the EventLog service.

You can be notified of registry changes with RegNotifyChangeKeyValue.

The question is why does services.exe do this.

Maybe it's some optimisation - saves having to scan all keys when
writing each event. But why "cache" it back in the registry? I don't
know...


Jan Bares wrote:
Hi,

can someone explain me this behaviour:

(steps to reproduce)
1. Open HKLM/SYSTEM\CurrentControlSet\Services\Eventlog\Applica tion
2. Look at the "Sources" value
3. Now create new key under the "Application"
4. The new key is magically added to the "Sources" value (along with "New
key #") when you refresh the view

And what is more strange, when you delete all the changes (the value is not
restored back when you delete the key) and do the steps again with the same
new key name, the "Sources" value is not modified.
And when you use different name for the new key, the "Sources" is again
modified and all the new keys that you created/erased somehow magically
reappear.

Regards, Jan

PS: Works for me on Win2k and WinNT (remotely modified from Win2k machine
with regedt32)
PS2: Also works when you use registry API to create the new key (I am
fiddling with services)


Nov 17 '05 #2

P: n/a
> Interesting! But not magic. :)

Using regmon from sysinternals.com you can see services.exe makes this
change... services.exe is (at least) the EventLog service.

You can be notified of registry changes with RegNotifyChangeKeyValue.
Yes, I know that this is possible

The question is why does services.exe do this.

Maybe it's some optimisation - saves having to scan all keys when
writing each event. But why "cache" it back in the registry? I don't
know...


Then why when I delete the key the "Sources" are not updated too?
And the caching of old values is really strange things, seems like bug.

Jan
Nov 17 '05 #3

P: n/a
>>The question is why does services.exe do this.

Maybe it's some optimisation - saves having to scan all keys when
writing each event. But why "cache" it back in the registry? I don't
know...

Then why when I delete the key the "Sources" are not updated too?
And the caching of old values is really strange things, seems like bug.


Maybe it fixes up "Sources" when the EventLog service restarts... Maybe
not.

Without knowing the intended behaviour, it's hard to call it a bug.
Nov 17 '05 #4

P: n/a
Hi Doug and Jan,
Maybe it's some optimisation - saves having to scan all keys when
writing each event. But why "cache" it back in the registry? I don't
know...


On the scenario of manipulating the registry key Eventlog\Application
directly, it will seem a little odd, however this behavior is designed for
the use of services.exe, it uses this approach to add the event source
names to the "Sources" value for *itself*, and deletes the expired source
name with another method.

We recommend the developers use the proper way to registry an event log
source application as you know :)
Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Nov 17 '05 #5

P: n/a
Hi Gary
On the scenario of manipulating the registry key Eventlog\Application
directly, it will seem a little odd, however this behavior is designed for
the use of services.exe, it uses this approach to add the event source
names to the "Sources" value for *itself*, and deletes the expired source
name with another method.

We recommend the developers use the proper way to registry an event log
source application as you know :)


What is the proper way then? Call RegisterEventSource() and create the
registry key in SYSTEM\\CurrentControlSet\\Services\\EventLog\\App lication\\
and do not modify "Sources"?
And during uninstall call DeregisterEventSource() and delete the key?

Where should I delete the entries that appear in Event Viewer
View/Filter/EventSource? During debugging I added new values and now I don't
know how to delete them, because they are not present in "Sources" but I
still see them in the Event Viewer filter settings...

Thank you, Jan
Nov 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.