HOWTO: Troubleshooting the "Event Message Not Found" Message (166902)


The information in this article applies to:

  • Microsoft Win32 Application Programming Interface (API), when used with:
    • the operating system: Microsoft Windows NT 3.51
    • the operating system: Microsoft Windows NT 4.0
    • the operating system: Microsoft Windows 2000
    • the operating system: Microsoft Windows XP
This article was previously published under Q166902

SUMMARY

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>.
This article helps to troubleshoot this problem.

MORE INFORMATION

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.
  2. The path to the .dll or .exe file in the registry is incorrect. In the 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.
  3. The registered message source is the wrong .dll or .exe file. In the 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.
  4. Message resources are not bound in the EventMessageFile source.

    A version of the Logging sample failed to include the .rc file as part of the build in the makefile. As a result, 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 an ID of 1 and type 11 (RT_MESSAGETABLE). This is required for Event Viewer to find the message resources.

    If you are using Visual C++ to build the EventMessageFile DLL, you must add the .rc file that is output from the message compiler as a source file of the Visual C++ project. This will tell Visual C++ to compile the .rc file and then link the resources to the DLL.
  5. Make sure the correct ID is passed to the ReportEvent function.

    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.
  6. Event Viewer was not restarted since you added the EventMessageFile 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.
Modification Type:MajorLast Reviewed:3/15/2004
Keywords:kbAPI kbEventLog kbhowto kbKernBase KB166902
©2004 Microsoft Corporation. All rights reserved.