EventLog.CreateEventSource Method (String, String)
Updated: September 2010
Establishes the specified source name as a valid event source for writing entries to a log on the local computer. This method can also create a new custom log on the local computer.
Assembly: System (in System.dll)
source is an empty string ("") or a null reference (Nothing in Visual Basic).
- or -
logName is not a valid event log name. Event log names must consist of printable characters, and cannot include the characters '*', '?', or '\'.
- or -
logName is not valid for user log creation. The event log names AppEvent, SysEvent, and SecEvent are reserved for system use.
- or -
The log name matches an existing event source name.
- or -
The source name results in a registry key path longer than 254 characters.
- or -
The first 8 characters of logName match the first 8 characters of an existing event log name.
- or -
The source cannot be registered because it already exists on the local computer.
- or -
The source name matches an existing event log name.
The registry key for the event log could not be opened on the local computer.
Use this overload to create a custom log or to create and register a Source to an existing log on the local computer.
If logName is a null reference (Nothing in Visual Basic) or an empty string ("") when you call CreateEventSource, the log defaults to the Application log. If the log does not exist on the local computer, the system creates a custom log and registers your application as a Source for that log.
To create an event source in Windows Vista and later or Windows Server 2003, you must have administrative privileges.
The reason for this requirement is that all event logs, including security, must be searched to determine whether the event source is unique. Starting with Windows Vista, users do not have permission to access the security log; therefore, a SecurityException is thrown.
Starting with Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. To execute the code that accesses the security log, you must first elevate your privileges from standard user to administrator. You can do this when you start an application by right-clicking the application icon and indicating that you want to run as an administrator.
You only need to create an event source if you are writing to the event log. Before writing an entry to an event log, you must register the event source with the event log as a valid source of events. When you write a log entry, the system uses the Source to find the appropriate log in which to place your entry. If you are reading the event log, you can either specify the Source, or a Log and MachineName.
You are not required to specify the MachineName if you are connecting to a log on the local computer. If you do not specify the MachineName when reading from a log, the local computer (".") is assumed.
Use WriteEvent and WriteEntry to write events to an event log. You must specify an event source to write events; you must create and configure the event source before writing the first entry with the source.
Create the new event source during the installation of your application. This allows time for the operating system to refresh its list of registered event sources and their configuration. If the operating system has not refreshed its list of event sources, and you attempt to write an event with the new source, the write operation will fail. You can configure a new source using an EventLogInstaller, or using the CreateEventSource method. You must have administrative rights on the computer to create a new event source.
You can create an event source for an existing event log or a new event log. When you create a new source for a new event log, the system registers the source for that log, but the log is not created until the first entry is written to it.
The operating system stores event logs as files. When you use EventLogInstaller or CreateEventSource to create a new event log, the associated file is stored in the %SystemRoot%\System32\Config directory on the specified computer. The file name is set by appending the first 8 characters of the Log property with the ".evt" file name extension.
The source must be unique on the local computer; a new source name cannot match an existing source name or an existing event log name. Each source can write to only one event log at a time; however, your application can use multiple sources to write to multiple event logs. For example, your application might require multiple sources configured for different event logs or different resource files.
The source must be configured either for writing localized entries or for writing direct strings. If your application writes entries using both resource identifiers and string values, you must register two separate sources. For example, configure one source with resource files, and then use that source in the WriteEvent method to write entries using resource identifiers to the event log. Then create a different source without resource files, and use that source in the WriteEntry method to write strings directly to the event log using that source.
To change the configuration details of an existing source, you must delete the source and then create it with the new configuration. If other applications or components use the existing source, create a new source with the updated configuration rather than deleting the existing source.
If a source has already been mapped to a log and you remap it to a new log, you must restart the computer for the changes to take effect.
Windows 7, Windows Vista, Windows XP SP2, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP Starter Edition, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows Server 2000 SP4, Windows Millennium Edition, Windows 98
The .NET Framework and .NET Compact Framework do not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.