KB329291 が近い気もするけど違う気もする...

support.microsoft.com/default.aspx" rel="nofollow">support.microsoft.com/default.aspx">support.microsoft.com/default.aspx" rel="nofollow">support.microsoft.com/default.aspx
          

ちなみに動いてないコードはこんな感じ

# SourceExists() で SecurityException



if (EventLog.SourceExists(sourceName, machineName))

{

EventLog.DeleteEventSource(sourceName, machineName);

}



EventLog.CreateEventSource(sourceName, logName, machineName);



eventLog = new EventLog();

eventLog.Source = sourceName;

eventLog.WriteEntry("EventLogging!", EventLogEntryType.Information);
          

見る権利と書く権利が別の物なんで…

見れないけど書けるって無いですよね。



　ReaderとWriterで権利が別な場合、existsを実行するには通常はReaderが必要になるんで…

　直接CreateEventSourceするのは試しました？

　LocalServiceにイベントログの書き込み権利が無いってのは、そなアホナって感じです。


          

ちゃうか、NetworkServiceか、ASP.NETからですね。

KBの通りかも、インストーラーでイベントソースを登録する必要有りですね。




          

インストーラでイベントソースを登録してみましたが

WriteEntry() が内部で SourceExists() を呼び出しているので

やっぱりレジストリアクセスが拒否され書き込めないです(爆)



ちなみに .Source を指定しない Application ログなら書き込み可能でした

LocalService/NetworkService アカウントだとカスタムログには書き込みできないってことなのだろうか...
          

なんか微妙に変だよね。

EventLogなんてもう全然使ってないからわからないや（ｗ。

てか、イベントソースを登録するんだから

そのときに適切なアクセス権を設定すれば？


          

.NET Framework から ACL っていじれないですよね

なので管理者権限持っているときにアクセス権設定しておきたくてもできなくて...



というかドキュメントを見直していたら SourceExists() に気になる記述を発見しました

"このメソッドはレジストリにアクセスするため、指定したサーバー上で適切なレジストリ アクセス許可を持っている必要があります。このアクセス許可がない場合、クエリは false を返します。"



これの通りなら false を返すはずが SecurityException() を投げてるのでバグっぽいですね～

WriteEntry() も false を期待しているはずなので

それで書き込みすらできない状況になってるのかも

# バグ報告ってどこに送ればいいんですかね...
          

ちなみにしばらくは LocalSystem アカウントで動いてもらうことにします(爆)

あと SourceExists + SecurityException という感じで検索すると

世界中で困っている人がたくさんいたことが判明しました(死)