EventLog Intermittent Exception

Question

Ich habe ein zeitweiliges Problem mit einigen Code, der auf einem Windows-Ereignisprotokoll schreibt, C # und .Net EventLog Klasse.

Im Grunde dieser Code arbeitet Tag-zu-Tag perfekt, aber sehr selten, beginnen wir Fehler wie diese bekommen:

  

"System.ArgumentException: Nur die   ersten acht Zeichen eines benutzerdefinierten Protokoll   Name von Bedeutung ist, und es gibt   bereits ein anderes Protokoll auf dem System   Über die ersten acht Zeichen von   der Name gegeben. Name:   ‚Anwendung‘, der Name des bestehenden Protokoll:   'Anwendung'. "

kann ich von den anderen Informationen über unsere Protokolle identifizieren, das der betroffene Call-Stack wie das ist - Sie können Ich bin in der Tat deutlich sehen, versuchen, zu einem vorhandenen LB_Email Protokoll schreiben (LogEmail heißt zuerst):

public static void LogEmail(string to, string type)
{
    string message = String.Format("{0}\t{1}\t{2}", DateTime.Now, to, type);
    Log(message, "LB_Email", EventLogEntryType.Information);
}

private static void Log(string message, string logName, EventLogEntryType type)
{
    using (EventLog aLog = new EventLog())
    {
        aLog.Source = logName;
        aLog.WriteEntry(message, type);
    }
}

Sobald die auftretenden Fehler zu starten, wie es scheint, den Zugang zu unserer LB_Email eventlog gesperrt ist irgendwie - Betrachtungseigenschaften auf der jeweiligen eventlog zeigt die meisten Informationen abgeblendet und unveränderlich, und andere Prozesse scheinen von der Anmeldung auch in dieses Protokoll zu verhindern. Ich bin jedoch der Fehler zu sehen (die die gleiche Log oben beschriebene Methode verwendet) über einen Try-Catch, die zu einem ‚LB_Error‘ log protokolliert, und dass weiterhin wie erwartet funktionieren.

Ich rufe diesen Code aus einer Multi-Threaded-Anwendung, aber ich habe es nicht gelungen, zu erkennen, ob der Code über Thread-sicher ist oder nicht.

Ich kann auch bestätigen, dass das Protokoll in Frage arbeitet wieder in Ordnung nach dem Töten und den Prozess neu zu starten ... und es hatte die entsprechenden Einstellungen Einträge wieder zu verwenden, wenn es voll zu tun ... obwohl ich nicht glaube, das war das Problem .

Ich würde gerne Ihre Meinung und Vorschläge hören.

Answer 1

Die Dokumentation heißt es:

  

Sie können nur die Quelle verwenden, um zu schreiben   ein Protokoll zu einer Zeit

So vermute ich, dieses Problem durch Ihre multithreaded App verursacht wird, die Log Methode aufrufen, dass einmal mehr zu einem bestimmten Zeitpunkt und für die gleiche Quelle.

Ich schlage vor, dass anstelle einer statischen Klasse (oder Methoden), können Sie eine Thread-sichere Singletonklasse verwenden diese Ereignisse für die Anmeldung.

EDIT:

Jon Skeet hat einen ausgezeichneten Artikel auf Singletons.

Wenn Sie nicht über eine Singleton-Klasse implementieren wollen Sie etwas tun können:

    static readonly object lockObj = new object();

    public static void LogEmail(string to, string type)
    {
        string message = String.Format("{0}\t{1}\t{2}", DateTime.Now, to, type);
        Log(message, "LB_Email", EventLogEntryType.Information);
    }

    private static void Log(string message, string logName, EventLogEntryType type)
    {
        lock (lockObj)
        {
            using (EventLog aLog = new EventLog())
            {
                aLog.Source = logName;
                aLog.WriteEntry(message, type);
            }
        }
    }

Hope dies Ihr Problem löst.

Answer 2

Danke Bruno,

So

, täusche ich mich in der Annahme, dass die EventLog-Instanz in der Log-Methode unterscheidet sich von der EventLog-Instanz in der gleichen Methodenaufruf in einem anderen Thread? Oder bin ich nur verwirrt über Objektinstanzen innerhalb einer statischen Methode?

OK, so habe ich mehrere Wrapper-Methoden auf die Log (...) -Methode. Wenn ich die Log-Methode in eine Singleton-Klasse bewegt, verändert die Wrapper (LogEmail, LogXxxx, LogYyy etc dann konnte ich meine Log.Zzzz halten die gleichen Schnittstellen, aber die Sicherheit des Singletons nutzen LogSingleton.Instance.Log (...) aus den aktuellen Logs. OR, weil ich mag verschiedene Protokolle schreiben, würde jeder erfordert eine eigene LogSingletonXxx?

Man kann sagen, ich bin verwirrt :) Ja - ich wirklich etwas Synchronisationscode zu schätzen wissen würde:)

Nij