Simon Carter wrote:

>> I researched this topic in early 2001 and several
>> bureaucratic steps had to be followed to register properly
>> with the event log facilities. Therefore, I abandoned the
>> issue and I don't remember the details. Alas, I'm not sure I
>> understood all the needed steps.
>>
>> If you find someone that's willing to contribute the needed code...
>> ;-)
>>
>> C.
>
> I would be more than happy to create the mc/dll files with messages
> but I would need a list of error codes/messages that are used.
> Installation is relatively easy, a few extra reg entries would need
> to be created by the installer.

This is really a topic for fb-devel, so if you agree, I will restart the
topic there. You should begin here
http://cvs.sourceforge.net/viewcvs.py/firebird/firebird2/src/iscguard/
and inside iscguard.cpp you will find five calls to write_log() with the
following resource identifiers:
IDS_CANT_START_THREAD
IDS_LOG_START
IDS_STARTUP_ERROR
IDS_LOG_TERM
IDS_LOG_STOP

The aforementioned write_log() is the only place in the guardian that calls
ReportEvent (you will find the guardian's code is a mess and still leaks
after Mike's efforts 3+ years ago to make it less insane). The other place
in fbsyslog.cpp in src/jrd, to manage event log messages for the server.

If you're going to forward to fb-devel, remember to get rid of the
[Firebird-architect] part in the subject, because it's confusing to
piggyback prefixes for more than one list.

Any Borland employee in this list that could explain why the guardian calls
RegisterEventSource each time a new event is posted and never calls
DeregisterEventSource or why some malloc's don't have a free counterpart or
why each time the server crashes, a new thread is added to flash the
guardian's tray icon so in the end the effect is invisible due to many
threads competing to flash the icon?

At this time I cannot run the guardian because it stops in an assertion due
to a NULL pool... well, that's true, I don't have any pool in my garden.
:-)

C.