Feedback

Eventlog – Eintrag schreiben

C# - Jan Welker Januar 8, 2007
1 Ratings 5/5

Sprache: C#

Diese Funktion fügt dem Eventlog (auch Fehlerprotokoll genannt) einen Eintrag hinzu
/// <summary>
/// schreibt einen Eintrag ins Eventlog von Windows NT/2000/XP
/// </summary>
/// <param name="source">Quelle</param>
/// <param name="message">Nachricht</param>
/// <param name="type">Typ</param>
private  void WriteEventlogMessage(string source, string message, System.Diagnostics.EventLogEntryType type)
{
    System.Diagnostics.EventLog myEV = new System.Diagnostics.EventLog();
    myEV.Source = source;
    myEV.WriteEntry(message, type);
    myEV.Close();
}
/// <summary>
/// schreibt einen Eintrag ins Eventlog von Windows NT/2000/XP
/// </summary>
/// <param name="source">Quelle</param>
/// <param name="message">Nachricht</param>
/// <param name="type">Typ</param>
private  void WriteEventlogMessage(string source, string message, System.Diagnostics.EventLogEntryType type)
{
    System.Diagnostics.EventLog myEV = new System.Diagnostics.EventLog();
    myEV.Source = source;
    myEV.WriteEntry(message, type);
    myEV.Close();
}
Abgelegt unter EventLog Fehlerprotokoll

Alte URL: /snippet/eventlog-eintrag-schreiben/413

1 Kommentar

  1. Der Code ist ein typisches Beispiel aus der .NET-2.0/3.5-Ära: schnell einen EventLog-Eintrag schreiben, am besten gleich noch die Source anlegen. In modernen Windows-Setups und erst recht in Cloud-/Container-Szenarien ist das aber deutlich heikler, weil das Anlegen einer Source Adminrechte braucht, weil EventLog Windows-only ist und weil man Logging heute normalerweise über ILogger/ETW/EventSource abstrahiert.

    [b]Analyse nach heutigen Kriterien:[/b]
    – [u]Cross-Platform[/u]: System.Diagnostics.EventLog ist Windows-only. Auf Linux/macOS gibt es kein Windows Event Log. Ohne Plattform-Gating führt das zu Laufzeitproblemen.
    – [u]Cloud/Container[/u]: In Containern und in vielen Cloud-Deployments ist das Windows Event Log nicht das primäre Logging-Ziel. Üblich sind STDOUT/STDERR, zentrale Log-Aggregation und strukturierte Logs.
    – [u]Sicherheit/Rechte[/u]: EventLog.CreateEventSource erfordert typischerweise administrative Rechte und schreibt in die Registry. Das zur Laufzeit in einer App zu tun ist ein Anti-Pattern und kann in gehärteten Umgebungen scheitern.
    – [u]Robustheit[/u]: „Existiert Source? dann anlegen“ ist race-condition-anfällig, wenn mehrere Prozesse parallel starten. Außerdem fehlt sauberes Fehlerhandling und eine klare Trennung zwischen Setup (Install) und Laufzeit (Log schreiben).
    – [u]Performance[/u]: EventLog ist relativ teuer, insbesondere wenn die Source erst erzeugt oder geprüft wird. Auch das permanente Prüfen auf Source-Existenz kostet.
    – [u]Thread-Safety[/u]: Schreiben ist grundsätzlich thread-safe genug für typische Nutzung, aber die Source-Erstellung ist globaler Zustand und parallel problematisch.
    – [u]Standard-.NET-Ansatz heute[/u]: In modernen Apps ist ILogger (Microsoft.Extensions.Logging) der Standard. Für Windows Event Log gibt es Provider, und unter Windows kann man zusätzlich ETW/EventSource nutzen.

    [b]Modernisierte Variante (ILogger-first, optional Windows Event Log via Provider, keine Source-Erstellung zur Laufzeit):[/b]
    [code]
    using System;
    using Microsoft.Extensions.Logging;

    public static class AppLogging
    {
    public static void LogStartup(ILogger logger)
    {
    if (logger is null) throw new ArgumentNullException(nameof(logger));
    logger.LogInformation(„Application started.“);
    }

    public static void LogError(ILogger logger, Exception ex)
    {
    if (logger is null) throw new ArgumentNullException(nameof(logger));
    if (ex is null) throw new ArgumentNullException(nameof(ex));
    logger.LogError(ex, „Unhandled exception.“);
    }
    }
    [/code]

    [b]Hinweis zur EventLog-Anbindung:[/b]
    Wenn du wirklich ins Windows Event Log schreiben willst, dann nicht per CreateEventSource zur Laufzeit, sondern als Install-/Deployment-Schritt (z. B. MSI/Script/Installer) und dann über den passenden Logging-Provider. In vielen Fällen reicht es, strukturierte Logs über ILogger auszugeben und die Plattform entscheidet, wohin sie gehen.

    [b]Warum das heute objektiv besser ist:[/b]
    – [u]Plattformtauglichkeit[/u]: Der Code bleibt auf allen Plattformen lauffähig; die Entscheidung „EventLog ja/nein“ liegt im Hosting/Deployment.
    – [u]Robustheit[/u]: Kein globaler Seiteneffekt (Source-Erstellung) beim App-Start, keine Race-Conditions zwischen Prozessen.
    – [u]Cloud-Fähigkeit[/u]: Funktioniert mit modernen Logging-Pipelines (Container logs, OpenTelemetry, zentrale Aggregation).
    – [u]Wartbarkeit[/u]: Logging ist standardisiert und austauschbar, statt hart an Windows Event Log gebunden zu sein.

    [b]Security-Realitätscheck:[/b]
    Wenn eine App versucht, zur Laufzeit eine EventLog-Source anzulegen, ist das in vielen Umgebungen ein rotes Tuch (Adminrechte, Registry-Schreibzugriff). Source-Anlage gehört in den Installationsprozess, nicht in den normalen Programmablauf.