none
ReportingServicesがハングアップすることがある RRS feed

  • 質問

  • ReportingServicesが突然ハングアップする事象がありました。

    ReportingServices構成ツールからインスタンスに接続しようとしても、接続ボタンがグレーアウトされている状態になっており、サービスを再起動することで復旧しました。

    ログを確認すると、下記のようなエラーが出ていました。

    特に環境の変更などはおこなっておらず、日中の使用中に突然エラーが発生していました。

    レポートサーバデータベース上の ExecutionLog3ビューでレポートの実行履歴までは分かるのですが、具体的に何が原因かを調査するにはどのような方法があるでしょうか?

    尚、SQLServerのバージョンは SQLServer2012, OSはWindows2008R2 です。

    rshost!rshost!5024!07/01/2015-09:58:40:: e ERROR: Failed to process request 0x80131530, pipeline=0x00000009D4385F00.
    rshost!rshost!5024!07/01/2015-09:58:40:: e ERROR: HttpPipelineCallback::SendResponse(): failed writing response.
    rshost!rshost!5024!07/01/2015-09:58:40:: e ERROR: Failed with win32 error 0x10DD, pipeline=0x00000009D4385F00.
    rshost!rshost!7aa0!07/01/2015-09:58:57:: e ERROR: Failed to process request 0x8007000e, pipeline=0x00000009D4385F00.
    rshost!rshost!7aa0!07/01/2015-09:58:57:: e ERROR: HttpPipelineCallback::SendResponse(): failed writing response.


    • 編集済み y-ohara 2015年7月15日 6:36
    2015年7月15日 6:32

回答

  • 確か 0x80131530 は何か問題があって処理が中断されたことを示すコードで、0x10DD は何か不正な処理を行おうとしたので処理が実行されなかったことを示すコードですので、残念ながらこのエラーコードの場合は原因がはっきりしません。

    pipeline のコードから追うのは一つの手ですが、相当なスキルが必要になると思いますので有償サポートを頼らないと難しいと思います。
    また別の手として、エラーになった状況でユーザーがどのような操作を行ったりサーバーでどのような処理が行われていたかという状況から追うのもありかと思います。

    Reporting Services であまりに巨大なレポートやデータを処理させようとするとこのようなエラーが出たような気がするので、単発で同じ現象が再発していないようでしたら、何かそういった操作を行っていたユーザーがいないか一度確認されるのも良いかと思います。


    MCITP(Database Developer/Database Administrator)

    • 回答としてマーク y-ohara 2015年7月16日 7:13
    2015年7月15日 15:20

すべての返信

  • フォーラム オペレーターの星 睦美です。
    y-ohara さん、投稿ありがとうございます。

    先に投稿いただいた質問「レポートのエクスポート時に「ASP.netセッションの有効期限が切れています」のエラーが表示される」と同様に利用しているブラウザはInternet Explorer 8 で、サーバーには最新の修正プログラムが適用されている状態でしょうか。

    またイベントログに出力されているエラーの有無や詳細を確認してみるとトラブルシューティングの手がかりになるのではないかと思います。詳しい情報をお知らせいただくとより役立つ回答につながりますのでよろしければお知らせください。

    フォーラムのご利用方法(質問の投稿)について


    フォーラム オペレーター 星 睦美 - MSDN Community Support



    • 編集済み 星 睦美 2015年7月15日 8:30 編集
    2015年7月15日 7:06
  • FYI
    ----------------------------------------------------------
    [Debugging] ハング (フリーズ) したあのコを激しく解析!~
    DebugDiag & Windbg : 1 / 2
    http://blogs.technet.com/b/jpilmblg/archive/2009/03/02/debug-1.aspx

    [Debugging] ハング (フリーズ) したあのコを激しく解析!~
    DebugDiag & Windbg : 2 / 2
    http://blogs.technet.com/b/jpilmblg/archive/2009/06/11/debugging-debugdiag-windbg-2-2.aspx
    ----------------------------------------------------------

    ちょっと古い記事ですけど、参考になりましたら幸いです。

    2015年7月15日 10:29
  • 確か 0x80131530 は何か問題があって処理が中断されたことを示すコードで、0x10DD は何か不正な処理を行おうとしたので処理が実行されなかったことを示すコードですので、残念ながらこのエラーコードの場合は原因がはっきりしません。

    pipeline のコードから追うのは一つの手ですが、相当なスキルが必要になると思いますので有償サポートを頼らないと難しいと思います。
    また別の手として、エラーになった状況でユーザーがどのような操作を行ったりサーバーでどのような処理が行われていたかという状況から追うのもありかと思います。

    Reporting Services であまりに巨大なレポートやデータを処理させようとするとこのようなエラーが出たような気がするので、単発で同じ現象が再発していないようでしたら、何かそういった操作を行っていたユーザーがいないか一度確認されるのも良いかと思います。


    MCITP(Database Developer/Database Administrator)

    • 回答としてマーク y-ohara 2015年7月16日 7:13
    2015年7月15日 15:20
  • 星 睦美様:

    返信ありがとうございます。

    現在最新のパッチは適用されておらず、ログファイルに記載のバージョンは下記のようになっております。

      <Product>Microsoft SQL Server Reporting Services Version 2011.0110.3000.00 ((SQL11_PCU_Main).121019-1325 )</Product>
      <OSName>Microsoft Windows NT 6.1.7601 Service Pack 1</OSName>
      <OSVersion>6.1.7601</OSVersion>

    2015年7月16日 6:59
  • 回答ありがとうございます。

    >[Debugging] ハング (フリーズ) したあのコを激しく解析!~
    >DebugDiag & Windbg : 1 / 2

    ダンプファイルの取得による解析ですね。最終的にはこういった手段もあるかもしれません。

    参考にさせていただきます。


    • 編集済み y-ohara 2015年7月16日 7:04
    2015年7月16日 7:01
  • nagino様:

    おっしゃるように、レポートの定義や処理しているレコードの大きさが起因になっている可能性もありますね。

    操作ログからある程度は状況の再現ができますので、再現試験をおこなってみたいと思います。

    アドバイスありがとうございます。

    2015年7月16日 7:13