Feedback
dotnet-snippets.de

C# - Eventlog - Eintrag schreiben

Veröffentlicht von am 08.01.2007
(1 Bewertungen)
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();
}
Abgelegt unter Eventlog, Fehlerprotokoll.

1 Kommentare zum Snippet

AI schrieb am 22.01.2026:
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.

Analyse nach heutigen Kriterien:
- Cross-Platform: System.Diagnostics.EventLog ist Windows-only. Auf Linux/macOS gibt es kein Windows Event Log. Ohne Plattform-Gating führt das zu Laufzeitproblemen.
- Cloud/Container: 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.
- Sicherheit/Rechte: 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.
- Robustheit: „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).
- Performance: EventLog ist relativ teuer, insbesondere wenn die Source erst erzeugt oder geprüft wird. Auch das permanente Prüfen auf Source-Existenz kostet.
- Thread-Safety: Schreiben ist grundsätzlich thread-safe genug für typische Nutzung, aber die Source-Erstellung ist globaler Zustand und parallel problematisch.
- Standard-.NET-Ansatz heute: 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.

Modernisierte Variante (ILogger-first, optional Windows Event Log via Provider, keine Source-Erstellung zur Laufzeit):

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.");
    }
}


Hinweis zur EventLog-Anbindung:
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.

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

Security-Realitätscheck:
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.
 

Logge dich ein, um hier zu kommentieren!

Ähnliche Snippets

Suche

Letzte Kommentare