ID: Q166902
The information in this article applies to:
There may be several possible reasons why the following error message appears for events in Event Viewer:
The description for Event ID ( <####> ) in Source (<application name>)
could not be found. It contains the following insertion string(s): <the
text of the message logged by ReportEvent>.
Listed below are the possible causes and more information on how to correct the problem. The cause may be one or more of the following:
1. An incorrect source name parameter was passed to RegisterEventSource.
Make sure the source name in the registry matches that of what is passed
to RegisterEventSource. This function will succeed even if the source is
not found in the registry. The source name in the registry should be in
a subkey of:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog
Typically an application source is listed under the application subkey.
registry value named EventMessageFile found at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\EventLog\Application\sourcename
verify that the path to the .dll or .exe file is correct and the name of
the .dll or .exe file is correct. In this case the Event Viewer
application fails to load the source of the message resources. Also, if
you use %SystemRoot% or some other macro, you must use the REG_EXPAND_SZ
registry value type. Otherwise, the macro does not get expanded.
registry value named EventMessageFile found at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\EventLog\Application\sourcename
verify that the path to the .dll or .exe file is the one which contains
the expected message resources. Be careful of listing an
EventMessageFile without a path and having multiple files with the same
name. Event Viewer follows the rules to find the message source by using
the search algorithm documented in the comments for the LoadLibrary API.
For Windows NT 4.0 be aware of whether or not the DLL name is listed in
the registry as a KnownDLL to the system, because the rebuilt DLL will
not be used until you reboot. Please search the Microsoft Knowledge Base
on the keywords WinNT and KnownDLLs for further information on this
topic.
A version of the Logging sample failed to include the .rc file as part
of the build in the makefile. So the DLL is built, but no message
resources are included in the build. Some developers have tried to
include the .bin file, which is output from the message compiler, as the
resource. This does not properly bind the resource to the DLL. You must
use the .rc file that is output from the message compiler because it
marks the resource with ID of 1 and of type 11 (RT_MESSAGETABLE). This
is required for Event Viewer to find the message resources.
Many think that the literal ID number found in the .mc file is the
correct ID. This is not so because the message compiler bitwise ORs the
ID number into the LOWORD and bitwise ORs the severity and facility bits
into the HIWORD. An application should always use the symbolic name in
the header file that is output from the message compiler.
Verify the MessageIdTypedef= statement in the .mc file. Some example .mc
files show how to define the MessageIDTypedef to WORD for Category IDs.
However, this causes Event IDs to loose the HIWORD. To correct this
issue, define MessageIdTypedef= only once and set it to DWORD.
Also be sure that the MC -c command line is consistently used for the
message resources and header file. The -c switch turns on a bit in the
HIWORD of the message ID.
entry in the registry.
Event Viewer caches the DLLs it loads for event sources. If you have
changed the registry to give a proper directory or source name after the
event viewer has been started, you need to restart Event Viewer.
Keywords : kbprg kbtshoot kbAPI kbEventLog kbKernBase kbNTOS351 kbNTOS400 kbSDKPlatform kbGrpKernBase
Version : NT:3.51 4.0
Platform : NT WINDOWS
Issue type : kbhowtoLast Reviewed: January 8, 1999