System.Security.SecurityException beim Schreiben in das Ereignisprotokoll

189

Ich arbeite daran, eine ASP.NET-App von Server 2003 (und IIS6) auf Server 2008 (IIS7) zu portieren.

Wenn ich versuche, die Seite im Browser zu besuchen, erhalte ich Folgendes:

Serverfehler in '/' Anwendung.

Sicherheitsaußnahme

Beschreibung: Die Anwendung hat versucht, einen Vorgang auszuführen, der von der Sicherheitsrichtlinie nicht zugelassen wird. Um dieser Anwendung die erforderliche Berechtigung zu erteilen, wenden Sie sich bitte an Ihren Systemadministrator oder ändern Sie die Vertrauensstufe der Anwendung in der Konfigurationsdatei.

Ausnahmedetails: System.Security.SecurityException: Die Quelle wurde nicht gefunden, aber einige oder alle Ereignisprotokolle konnten nicht durchsucht werden. Unzugängliche Protokolle: Sicherheit

Quellfehler:

Während der Ausführung der aktuellen Webanforderung wurde eine nicht behandelte Ausnahme generiert. Informationen bezüglich des Ursprungs und des Ortes der Ausnahme können mithilfe des Ausnahmestapel-Trace unten identifiziert werden.

Stapelverfolgung:

[SecurityException: Die Quelle wurde nicht gefunden, aber einige oder alle Ereignisprotokolle konnten nicht durchsucht werden. Unzugängliche Protokolle: Sicherheit.]

System.Diagnostics.EventLog.FindSourceRegistration (String-Quelle, String-Maschinenname, Boolean readOnly) +562 System.Diagnostics.EventLog.SourceExists (String-Quelle, String-Maschinenname) +251

[snip]

Dies sind die Dinge, die ich getan habe, um es zu lösen:

  1. Geben Sie "Jeder" die Vollzugriffsberechtigung für den Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security. Das hat funktioniert. Aber natürlich kann ich das in der Produktion nicht machen. Nachdem ich die App einige Minuten lang ausgeführt hatte, löschte ich die Berechtigung "Jeder" und der Fehler trat erneut auf.

  2. Ich habe die Quelle im Anwendungsprotokoll und im Sicherheitsprotokoll (und ich habe überprüft, ob sie über regedit vorhanden ist) während der Installation mit erhöhten Berechtigungen erstellt, aber der Fehler blieb bestehen.

  3. Ich habe der App eine vollständige Vertrauensstufe in die web.configDatei gegeben (und verwendet appcmd.exe), aber ohne Erfolg.

Hat jemand einen Einblick, was hier getan werden könnte?

PS: Dies ist eine Fortsetzung dieser Frage . Ich folgte den gegebenen Antworten, aber ohne Erfolg (siehe # 2 oben).

encee
quelle
Ich habe dies erhalten, als ich versucht habe, in eine benutzerdefinierte Quelle in einem .NET-Dienst zu schreiben, der als NetworkService ausgeführt wurde. Ich habe gerade die Ereignisprotokollquelle so geändert, dass sie mit dem Dienstnamen übereinstimmt, der über das .Net Service Setup-Paket eingerichtet wurde, und es hat funktioniert, ohne Registrierungsberechtigungen festzulegen. Ich habe es bemerkt, als ich den Dienstnamen als Schlüssel bereits in HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ EventLog \ Application
Jon Adams
1
Siehe auch
Chris S
2
Eine andere mögliche Antwort: Klicken Sie mit der rechten Maustaste auf exe und wählen Sie "Als Administrator
ausführen

Antworten:

169

Befolgen Sie die Anweisungen unter http://geekswithblogs.net/timh/archive/2005/10/05/56029.aspx, um die Network ServiceLeseberechtigung für den EventLog/SecuritySchlüssel zu erteilen (wie von Firenzi und royrules22 vorgeschlagen)

  1. Öffnen Sie den Registrierungseditor:
    1. Wählen Sie StartdannRun
    2. Geben Sie regedt32oder einregedit
  2. Navigieren Sie zu der folgenden Taste / erweitern Sie sie:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Security

  3. Klicken Sie mit der rechten Maustaste auf diesen Eintrag und wählen Sie Berechtigungen

  4. Fügen Sie den Network ServiceBenutzer hinzu

  5. Gib ihm Leseberechtigung

UPDATE: Die obigen Schritte sind auf Entwicklercomputern in Ordnung, auf denen Sie den Bereitstellungsprozess nicht zum Installieren der Anwendung verwenden.
Wenn Sie Ihre Anwendung jedoch auf anderen Computern bereitstellen, sollten Sie während der Installation Ereignisprotokollquellen registrieren, wie in den Antworten von SailAvid und Nicole Calinoiu vorgeschlagen .

Ich verwende die PowerShell-Funktion (Aufruf von Octopus Deploy.ps1).

function Create-EventSources() {
    $eventSources = @("MySource1","MySource2" )
    foreach ($source in $eventSources) {
            if ([System.Diagnostics.EventLog]::SourceExists($source) -eq $false) {
                [System.Diagnostics.EventLog]::CreateEventSource($source, "Application")
            }
    }
}
Michael Freidgeim
quelle
In IIS7 können Sie den "NETWORK SERVICE" als Identität für einen App-Pool zuweisen (möglicherweise ist ApplicationPoolIdentity die Standardeinstellung) oder stattdessen einen neuen Benutzer pro Anwendungspool erstellen und Berechtigungen für dieses "benutzerdefinierte Konto" festlegen. Siehe Festlegen einer Identität für einen Anwendungspool (IIS 7)
Grokodile
5
Die Änderungen werden erst wirksam, nachdem Sie Ihre Anwendung auf IIS
Zé Carlos am
7
Ich habe IIS_IUSRS die Berechtigung zum Lesen / Schreiben des Ereignisprotokollschlüssels und zum Lesen des Sicherheitsschlüssels erteilt. Mein Produkt benötigte Schreibzugriff auf den Ereignisprotokollschlüssel, da es eine eigene Ereignisquelle erstellt.
duck9
1
duck9 Ich korrigiere für IIS8, siehe hier für weitere Details: stackoverflow.com/questions/712203/…
thedrs
1
Informationen zu dieser Lösung finden Sie auch unter serverfault.com/a/81246/219898 in Bezug auf App-Pool-Benutzer und zugehörige Berechtigungen. Danke @Michael Freidgeim - war eine große Hilfe.
Anthony Horne
58

Das Problem ist, dass EventLog.SourceExistsversucht wird, auf den EventLog\SecuritySchlüssel zuzugreifen, der nur einem Administrator gestattet ist.

Ein häufiges Beispiel für die Anmeldung eines C # -Programms EventLogist:

string sSource;
string sLog;
string sEvent;

sSource = "dotNET Sample App";
sLog = "Application";
sEvent = "Sample Event";

if (!EventLog.SourceExists(sSource))
    EventLog.CreateEventSource(sSource, sLog);

EventLog.WriteEntry(sSource, sEvent);
EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Warning, 234);

Die folgenden Zeilen schlagen jedoch fehl, wenn das Programm keine Administratorrechte besitzt und der Schlüssel nicht unter gefunden wird, EventLog\Applicationda EventLog.SourceExistsdann versucht wird, darauf zuzugreifen EventLog\Security.

if (!EventLog.SourceExists(sSource))
    EventLog.CreateEventSource(sSource, sLog);

Daher wird empfohlen, ein Installationsskript zu erstellen, das den entsprechenden Schlüssel erstellt, nämlich:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ EventLog \ Application \ dotNET-Beispielanwendung

Man kann dann diese beiden Zeilen entfernen.

Sie können auch eine .regDatei erstellen, um den Registrierungsschlüssel zu erstellen. Speichern Sie einfach den folgenden Text in einer Datei create.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\dotNET Sample App]
Stefan Profanter
quelle
1
Genau das mache ich für alle meine Dienste. Ich glaube, dass dies das Richtige ist. In jedem Dienst, in dem ich das Ereignisprotokoll verwende, habe ich eine .reg-Datei wie die oben beschriebene. Ein kleiner Hinweis, die Datei muss als Unicode-32 (cp 1200.) gespeichert werden
Valo
Diese Antwort beschreibt den wahren Grund für den Fehler. Die vorhandene Prüfung versucht, den gesamten Schlüssel aufzulisten. Wenn es existiert, funktioniert checkExists einwandfrei.
DanO
EventLog \ Security Dies ist der Funktionsschlüssel. Stellen Sie sicher, dass Sie über die entsprechenden Berechtigungen verfügen.
Princa
45

Die Lösung bestand darin, dem Konto "Netzwerkdienst" die Leseberechtigung für den EventLog / Sicherheitsschlüssel zu erteilen.

encee
quelle
1
Ich sehe ähnliche Lösungen. Aber ich frage mich nur, warum es so ist. Weil ich sehe, dass viele Dienste als NetworkService angemeldet sind und das Ereignisprotokoll / die Sicherheit lesen können müssen. Warum muss die Berechtigung für NetworkService hinzugefügt werden?
h - n
11
Für diejenigen von uns, die normalerweise nicht durch die Registrierung kriechen, kann dieser Link hilfreich sein: social.msdn.microsoft.com/forums/en-US/…
Allan
Netter Link Allan. Punkt 3 der akzeptierten Antwort ist wichtig und hat mich schon einmal gebissen. Das Erteilen der Berechtigung für den übergeordneten EventLog-Registrierungsschlüssel wird NICHT an "unzugängliche Protokolle" wie "Sicherheit" und "Virtueller Server" weitergegeben, obwohl es sich um untergeordnete Schlüssel in der Registrierung handelt. Wenn Sie vollen Zugriff auf das Ereignisprotokoll wünschen, müssen Sie die Berechtigung sowohl für die übergeordnete Ereignisprotokollstufe als auch für die untergeordnete Sicherheitsstufe erteilen.
Ben Barreth
1
Die Änderungen werden erst wirksam, nachdem Sie Ihre Anwendung auf IIS
Zé Carlos am
Stellen Sie für diejenigen, die versucht haben, zu kopieren / einzufügen, sicher, dass zwischen den Wörtern "Netzwerkdienst" ein Leerzeichen steht.
Chris Fremgen
7

Für mich hat es nur funktioniert, dem gesamten 'EventLog'- Zweig ' Lese'-Berechtigungen für 'NetworkService' zu erteilen .

evictorov
quelle
Dies ist nicht sehr relevant, da die für die Unterschlüssel wie "Sicherheit" oder "Virtueller Server" Lesezugriff einzeln gewähren müssen, da die Berechtigungen so festgelegt wurden, dass sie nicht vom übergeordneten Schlüssel erben.
Serge
7

Ich hatte ein sehr ähnliches Problem mit einem Konsolenprogramm, das ich unter VS2010 entwickelt habe (Upgrade von VS2008 unter XP). Mein Prog verwendet EnLib, um einige Protokollierungen durchzuführen. Der Fehler wurde ausgelöst, weil EntLib nicht berechtigt war, eine neue Ereignisquelle zu registrieren.

Also habe ich einmal meinen kompilierten Prog als Administrator gestartet : Er hat die Ereignisquelle registriert. Dann ging ich zurück und entwickelte und debuggte problemlos aus VS heraus.

(Sie können auch auf http://www.blackwasp.co.uk/EventLog_3.aspx verweisen , es hat mir geholfen

Oldbrazil
quelle
7

Diese Ausnahme trat bei einer .NET-Konsolen-App auf, die als geplante Aufgabe ausgeführt wurde, und ich habe versucht, im Grunde das Gleiche zu tun: eine neue Ereignisquelle erstellen und in das Ereignisprotokoll schreiben.

Am Ende hat das Festlegen der vollständigen Berechtigungen für den Benutzer, unter dem die Aufgabe ausgeführt wurde, mit den folgenden Schlüsseln den Trick für mich getan:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Security
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
tswann
quelle
3
Du hast meinen Tag gerettet. Übrigens war die Leseerlaubnis am eventlog\Applicationund ausreichend eventlog\Security; volle Kontrolle nur auf der eventlogWurzel erforderlich .
Ruud Helderman
6

Ich versuche hier fast alles, um dieses Problem zu lösen ... Ich teile hier die Antwort, die mir hilft:

Eine andere Möglichkeit, das Problem zu beheben:

  • Wechseln Sie in der IIS-Konsole zum Anwendungspool, der Ihre Site verwaltet, und notieren Sie sich die Identität, auf der sie ausgeführt wird (normalerweise Netzwerkdienst).
  • Stellen Sie sicher, dass diese Identität KEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Eventlog lesen kann (Rechtsklick, Berechtigungen).
  • Ändern Sie nun die Identität dieses Anwendungspools in Lokales System, bewerben Sie sich und wechseln Sie zurück zum Netzwerkdienst

Die Anmeldeinformationen werden neu geladen und EventLog ist erreichbar

in http://geekswithblogs.net/timh/archive/2005/10/05/56029.aspx , danke Michael Freidgeim

Gelásio
quelle
Durch Ändern des App-Pools von "ApplicationPoolIdentity" in "LocalSystem" wurde das Problem des Erstellens / Lesens von Ereignisprotokollen für mich behoben.
Majestzim
4

Ich bin auf dasselbe Problem gestoßen, musste aber eine Ebene höher gehen und allen den vollständigen Zugriff auf den Schlüssel HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ EventLog \ gewähren, anstatt zur Sicherheit zu gehen, wodurch das Problem für mich behoben wurde.

Nodonoghue
quelle
1
Versuchen Sie auch, die Anwendung so einzustellen, dass sie als LocalSystem ausgeführt wird, damit der Registrierungsschlüssel erstellt wird. Anschließend können Sie wieder zu NetworkService wechseln.
Demoncodemonkey
4

Gleiches Problem unter Windows 7 64-Bit. Als Administrator ausführen hat das Problem behoben.

Dom
quelle
4

Ein neuer Schlüssel mit dem verwendeten Quellennamen muss unter HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog \ Application in regEdit erstellt werden, wenn Sie System.Diagnostics.EventLog.WriteEntry verwenden ("SourceName", "ErrorMessage", EventLogEntryType.Error).

Grundsätzlich hat Ihr Benutzer keine Berechtigung zum Erstellen des Schlüssels. Je nach verwendetem Benutzer können Sie anhand des Identitätswerts in den erweiterten Einstellungen des Anwendungspools Folgendes tun:

  1. Führen Sie RegEdit aus und wechseln Sie zu HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog
  2. Klicken Sie mit der rechten Maustaste in den EventLog-Schlüssel und wählen Sie die Option Berechtigungen ... aus. 3. Fügen Sie Ihrem Benutzer den vollständigen Kontrollzugriff hinzu.

    -Wenn Sie "NetworkService" verwenden, fügen Sie den Benutzer NETWORK SERVICE hinzu

    -Wenn Sie usinf "ApplicationPoolIdentity" verwenden fügen Sie IIS APPPOL {Name Ihres App-Pools} hinzu (verwenden Sie den lokalen Computerstandort, wenn Sie den Benutzer suchen).

    -Wenn Sie "LocalSystem" verwenden, stellen Sie sicher, dass der Benutzer über Administratorrechte verfügt. Es wird nicht für Sicherheitslücken empfohlen.

  3. Wiederholen Sie die Schritte 1 bis 3 für HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ eventlog \ Security

Zum Debuggen mit Visual Studio verwende ich "NetworkService" (es ist ein ASP.NET-Benutzer) und beim Veröffentlichen der Site "AppicationPoolIdentity".

Pablishe
quelle
3

Zu Ihrer Information ... mein Problem war, dass versehentlich "Lokaler Dienst" als Konto für Eigenschaften des ProcessInstaller anstelle von "Lokales System" ausgewählt wurde. Ich erwähne nur für alle anderen, die dem MSDN-Tutorial gefolgt sind, wie die Auswahl des lokalen Dienstes zuerst zeigt, und ich habe nicht genau aufgepasst ...

DaleS
quelle
3

Es scheint eine offensichtliche Lösung dafür zu geben, dass ich noch keinen großen Nachteil gesehen habe, zumindest dort, wo es nicht praktikabel ist, Administratorrechte zu erhalten, um eine eigene Ereignisquelle zu erstellen: Verwenden Sie eine, die bereits vorhanden ist.

Die beiden, von denen ich angefangen habe, sie zu verwenden, sind ".Net Runtime" und "Application Error", die beide auf den meisten Computern vorhanden zu sein scheinen.

Die Hauptnachteile sind die Unfähigkeit, nach diesem Ereignis zu gruppieren, und dass Ihnen wahrscheinlich keine Ereignis-ID zugeordnet ist. Dies bedeutet, dass dem Protokolleintrag möglicherweise ein Präfix mit dem Effekt "Die Beschreibung für Ereignis-ID 0 aus Quelle .Net" vorangestellt wird Die Laufzeit kann nicht gefunden werden ... ", wenn Sie sie weglassen, aber das Protokoll eingeht und die Ausgabe im Großen und Ganzen sinnvoll erscheint.

Der resultierende Code sieht am Ende folgendermaßen aus:

EventLog.WriteEntry(
    ".Net Runtime", 
    "Some message text here, maybe an exception you want to log",
    EventLogEntryType.Error
    );

Da es immer die Möglichkeit gibt, dass Sie sich auf einem Computer befinden, auf dem diese Ereignisquellen aus irgendeinem Grund nicht vorhanden sind, möchten Sie sie wahrscheinlich try {} catch{}einpacken, falls sie fehlschlägt und die Situation verschlimmert, aber Ereignisse können jetzt gespeichert werden.

tobriand
quelle
2

Ich arbeite nicht an IIS, aber ich habe eine Anwendung, die denselben Fehler auf einer 2K8-Box auslöst. Es funktioniert gut auf einer 2K3-Box.

Mein Vorsatz war "Als Administrator ausführen", um der Anwendung erhöhte Rechte zu gewähren, und alles funktioniert problemlos. Ich hoffe, das hilft Ihnen, in die richtige Richtung zu führen.

Windows 2008 ist Rechte / Berechtigungen / Erhöhung ist wirklich anders als Windows 2003, gar.

omgtitb
quelle
2

Hallo, ich bin auf dasselbe Problem gestoßen, als ich eine Anwendung entwickelt habe und sie auf einem Remote-PC installieren wollte. Ich habe es wie folgt behoben:

1) Gehen Sie zu Ihrer Registrierung und suchen Sie: HKLM \ System \ CurrentControlSet \ Services \ EventLog \ Application (??? YOUR_SERVICE_OR_APP_NAME ???)

Beachten Sie, dass "(??? YOUR_SERVICE_OR_APP_NAME ???)" der Name Ihres Anwendungsdienstes ist, wie Sie ihn beim Erstellen Ihrer .NET-Bereitstellung definiert haben. Wenn Sie beispielsweise Ihre neue Anwendung "Meine neue App" genannt haben, lautet der Schlüssel: HKLM \ System \ CurrentControlSet \ Services \ EventLog \ Application \ Meine neue App

Hinweis 2: Je nachdem, in welches eventLog Sie schreiben, finden Sie in Ihrer DEV-Box möglicherweise \ Application \ (wie oben angegeben) oder auch (\ System) oder (\ Security), je nachdem, in welches Ereignis Ihre Anwendung hauptsächlich schreibt , (\ Application) sollte immer in Ordnung sein.

2) Auf der Taste oben sein, Aus dem Menü; Wählen Sie "DATEI" -> "Exportieren" und speichern Sie die Datei. (Hinweis: Dadurch werden die erforderlichen Registrierungseinstellungen erstellt, wenn die Anwendung auf diesen Schlüssel zugreifen muss, um in die Ereignisanzeige zu schreiben.) Die neue Datei ist eine .REG-Datei. Nennen Sie sie aus Gründen des Arguments "Meine neue App.REG" ""

3) Wenden Sie sich bei der Bereitstellung unter PRODuction an den Systemadministrator (SA) des Servers, übergeben Sie die Datei "My New App.REG" zusammen mit der Anwendung und bitten Sie die SA, diese REG-Datei zu installieren, sobald dies (als Administrator) geschehen ist Erstellen Sie den Schlüssel für Ihre Anwendung.

4) Führen Sie Ihre Anwendung aus. Sie sollte nur auf diesen Schlüssel zugreifen müssen.

Das Problem sollte jetzt gelöst sein.

Ursache:

Wenn Sie eine Anwendung entwickeln, die etwas in das EventLog schreibt, ist ein SCHLÜSSEL in der Eventlog-Registrierung erforderlich. Wenn dieser Schlüssel nicht gefunden wird, wird versucht, ihn zu erstellen. Dies schlägt fehl, wenn Sie keine Berechtigungen dazu haben. Der oben beschriebene Vorgang ähnelt dem Bereitstellen einer Anwendung (manuell), während wir diese selbst erstellen. Sie müssen keine Kopfschmerzen haben, da Sie die Registrierung nicht optimieren, indem Sie JEDEM Berechtigungen hinzufügen, was ein Sicherheitsrisiko für Produktionsserver darstellt.

Ich hoffe, das hilft bei der Lösung.

Heider Sati
quelle
2

Obwohl die Antwort des Installationsprogramms eine gute Antwort ist, ist sie beim Umgang mit Software, die Sie nicht geschrieben haben, nicht immer praktisch. Eine einfache Antwort besteht darin, das Protokoll und die Ereignisquelle mit dem PowerShell-Befehl New-EventLog ( http://technet.microsoft.com/en-us/library/hh849768.aspx ) zu erstellen.

Führen Sie PowerShell als Administrator aus und führen Sie den folgenden Befehl aus, indem Sie den Protokollnamen und die Quelle ändern, die Sie benötigen.

New-EventLog -LogName Application -Source TFSAggregator

Ich habe es verwendet, um die Ereignisprotokollausnahme zu lösen, wenn Aggregator ein Problem mit Codeplex ausführt.

John Brown
quelle
1

Hatte ein ähnliches Problem mit allen unseren 2008-Servern. Das Sicherheitsprotokoll funktionierte aufgrund eines Gruppenrichtlinienobjekts, bei dem die Gruppe Authentifizierte Benutzer und Leseberechtigung vom Schlüssel entfernt wurden, nicht mehrHKLM\System\CurrentControlSet\Services\EventLog\security

Durch Zurücksetzen gemäß der Empfehlung von Microsoft wurde das Problem behoben. Ich vermute, dass es Ihr Problem auch behebt, wenn alle authentifizierten Benutzer auf einer höheren Ebene gelesen werden.

Steve M.
quelle
1

Ich bin auf ein ähnliches Problem gestoßen - in meinem Fall Quelle enthalten <, >Zeichen. 64-Bit-Maschinen verwenden eine neue gerade log-xml-Basis, würde ich sagen, und diese Zeichen (aus Zeichenfolge festgelegt) erzeugen ungültige XML-Dateien, die Ausnahmen verursachen. Möglicherweise sollte dies ein Microsoft-Problem sein - die Quelle (Name / Zeichenfolge) wird nicht korrekt behandelt.

alflesio
quelle
1

Die Lösung ist sehr einfach: Führen Sie Visual Studio Application im Admin-Modus aus!

Fregatte
quelle
Bei der Fehlerbehebung in VS und diesem Fehler wurde dies für mich
behoben
Dies würde zu einem Fehler führen, da nicht VS diesen Aufruf aufruft, sondern die Anwendung, die wahrscheinlich in einem anderen Sicherheitskontext ausgeführt wird.
CodeMonkey1313
0

Meine App wird auf Client-Webservern installiert. Anstatt mit den Netzwerkdienstberechtigungen und der Registrierung herumzuspielen, habe ich mich dafür entschieden, mein Installationsprogramm zu überprüfen SourceExistsund auszuführen CreateEventSource.

Ich habe log.source = "xx"der App auch einen Versuch / Fang hinzugefügt , um sie auf eine bekannte Quelle zu setzen, wenn meine Ereignisquelle nicht erstellt wurde (dies würde nur angezeigt, wenn ich eine DLL im laufenden Betrieb ausgetauscht hätte, anstatt sie erneut zu installieren).

basher
quelle
0

versuchen Sie es unten in web.config

 <system.web>

<trust level="Full"/>

</system.web>
Anjan Kant
quelle
-1

Ich hatte dieses Problem beim Ausführen einer App in VS. Ich musste das Programm nur einmal als Administrator ausführen und dann von VS aus ausführen.

Um als Administrator ausgeführt zu werden, navigieren Sie einfach zu Ihrem Debug-Ordner im Windows Explorer. Klicken Sie mit der rechten Maustaste auf das Programm und wählen Sie Als Administrator ausführen.

Bob Horn
quelle
-3

Der Wiederaufbau der Lösung hat bei mir funktioniert

stephen ebichondo
quelle