2017-05-25 2 views
0

私たちは、アプリケーションで多くのカスタムWindowsサービスを使用します。しかし、私が現在取り組んでいるのは厄介な問題です。サービスは稼動し続けているだけで、機能は停止します。Windowsサービスの内部障害を特定する方法

サービスの主な方法は、このように、try/catchブロック内にラップされています

static void Main() 
{ 
    IRepository rep = new Repository(); 
    ILogger log = LogManager.GetLogger(GetType().Name); 

    TimeSpan loadWindowStart = new TimeSpan(9, 0, 0); 
    TimeSpan loadWindowEnd = new TimeSpan(18, 0, 0); 

    foreach (SuppressionLoad sl in rep.GetSuppressionLoads().ToList()) 
    { 
     try 
     { 
      // do stuff 
     } 
     catch(Exception ex) 
     { 
      // log error 
     } 
    } 
} 

それはものがそうであるようにサービスも記録し、我々はそれが忙しいながら、ログがいっぱいに見ることができます。

ただし、ログが停止することがあります。データベースの他の場所での活動は、サービス全体が機能しなくなったことを示しています。サーバー上のサービスをチェックインすると、サービスには「開始済み」のステータスが表示されます。これは、通常はかなりプロセッサを使用していますが、この状態になっている間はほとんどゼロのシステムリソースを占有します。もしあなたがそれを試して止めれば、試しにタイムアウトするだけで、私たちが知る限り、それは決して決して止まることはありません。タスクマネージャでプロセスを強制終了する必要があります。

ログには、これらのストールまでの実行中に不都合なことはありません。イベントビューアには何も見つかりません。

エラーをログに記録しないため、ここで何が起こっているのか、ここからフォールトを診断して診断するためにできることについては迷っています。それは非常に断続的です。状態に入る前に何日も問題なく実行されることがよくあります。何が起こっているのかを調べるために私たちは何ができますか?

+0

サービスのコードを見て、デバッガを使用してコードをステップ実行する必要があるように聞こえます。おそらく、ログの記録方法を変更することを検討することをおすすめします。ログファイルまたは毎回新しいログファイルを作成します。 – MethodMan

+0

@MethodManステッピングスルーは問題ありませんが、この失敗は非常に断続的なので実際的な選択肢ではありません。 –

+0

私はそれ以外の場合を除いてはお勧めできません。おそらくあなたはリソースを作成していて、正しく処分していないのですが、例外メッセージの何時にトラップしていますか? – MethodMan

答えて

1

マット;あなたのサービスがスレッドを使用している場合(それは私が想定している)、それは非常に難しくなり、グローバルなtry/catchに頼ることはできません。

シンプルなことは、NBug(関連付けなし)です。処理されない例外をキャッチし、それらについての情報を提供します。私はそれが十分にあなたを得るとは思わない。

これらの種類のものを見つける一般的な方法は、log、log、logです。できるだけ問題を再現することに近づくことができなければなりません。各メソッドへのエントリーポイント、可変値、ヒットした場合の例外スタックトレース、各メソッドで費やした時間などを示すログが必要です。ログアウトのためのいくつかの本当に良いツールがありますので、私は何か推薦しても構いません。条件付きコンパイルスイッチでログをラップすることができます。問題が見つかると、電源を切ったときにパフォーマンスが低下することはありません。

おそらくあなたが望む答えではありませんが、実際に私のために長年働いていた唯一のものです。

SteveJ

+0

私が聞きたいものではなく、他の人が参考にしていることがあります。 +1 –

1

問題はどこでも可能性があり、必ずしも提供されているコードとはあまりを持っていないようですね。 、それについて

  1. するとサービスがハングを行くデバッガをアタッチして、スレッドを見て、それぞれがある場所を確認する方法について

    提案。デバッガが必要なコンテキストシンボルデータを持つように、ソリューションのデバッグバージョンを再構築して実行する必要があります。質問する質問:

    1. 私がそこにいることを期待しているスレッドはありますか、あるいは何も知られていないのですか?
    2. スレッドがデッドロック状態に陥っています(私はそれが起こっていると考えています)。
  2. 詳細なログをオンにし、コードの流れの中で、それが最後だったとどこでそれが行っていない、その後、場所を絞り込んでおく場所を隔離するために多くのデバッグログステートメントを中に振りかけます。問題のある行またはコードブロックを分離するときに、異常な動作が発生する理由を理解しようとするコンテキストがあるように、コンテキストデータを記録することを検討してください。
  3. IInspectableのコメントに全面的な記入をして、SysInternal's Process ExplorerまたはProcDump、またはTask Manager)プロセスのフルダンプを試みることができます。このツールを使用することはかなりの経験になる傾向がありますが、使用された権利は多くの洞察力を与えることができ、おそらく最初の発生時に問題を見つけることができます。

何が起こっているのか、どこのフィールドが広く開いているかを考慮すると、範囲を絞り込むために問題が発生している可能性があります。

+0

スコープを絞り込んでも、それでも理由がわからない場合は、質問を更新して私にpingしてください。 – LB2

関連する問題