none
Windows7にてOutlookでメール送信時にDRIVER_IRQL_NOT_LESS_OR_EQUAL(d1)が出る現象について RRS feed

  • 質問

  • タイトルの現象について、BlueScreenViewerとWindbgを使い原因を調べ
    対処法を探ろうと思いましたが、お手上げです。

    何か原因特定の糸口になる情報などありましたらお教え願います。

    ・現象について
     2017年12月頃より、複数のPCで、Outlook2010にてメール送信ボタン押下後、
     DRIVER_IRQL_NOT_LESS_OR_EQUAL(d1)が表示される現象が発生しています。
     エラー画面が出た後、通常通り再起動が可能ですが、送ろうとしたメールは、送れておらず
     送信トレイ・送信済みトレイにも入っていません。
     またこの現象は、再発する場合もありますが、100%ではない上に、発生頻度が低いです。

    ・対象OS
     Windows 7 Professional SP1 x86
     
    ・ソフトウェア
     Outlook 2010 SP2

    ・BSODについて
     BlueScreenViewerとWindbgで確認出来た情報
     ○BluScreenViewer
      DRIVER_IRQL_NOT_LESS_OR_EQUAL
      0x000000d1(0x00000006,0x00000002,0x00000000,0x8da7e662)
      tcpip.sys,tcpip.sys+70662,TCP/IP ドライバー

     ○Windbg
      DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT
      BUGCHECK_STR:  0xD1
      IMAGE_NAME:  fwpkclnt.sys
    2018年3月6日 9:47

回答

  • > またこの現象は、再発する場合もありますが、100%ではない上に、発生頻度が低いです。

    再現率は低くても複数の PC で起きているということは、複数のダンプ ファイルが採取されているはずですよね?
    その複数のダンプ ファイルで、STOP コードが DRIVER_IRQL_NOT_LESS_OR_EQUAL で、かつ tcpip.sys や fwpkclnt.sys のドライバ名が表示されているのでしょうか?

    すでに参照されているかもしれませんが、DRIVER_IRQL_NOT_LESS_OR_EQUAL の詳細情報は、下記サイトにあります。
    ------------------------------------------
    Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL
    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xd1--driver-irql-not-less-or-equal
    ------------------------------------------

    ちょっと難しいかもしれませんが、BlueScreenView が表示している
    "0x000000d1(0x00000006,0x00000002,0x00000000,0x8da7e662)"
    は、
    「カーネル モード側の仮想メモリ空間 0x8da7e662 の処理において、IRQL が DISPATCH_LEVEL (0x00000002) 状態で仮想メモリ アドレス 0x00000006 に対する Read (0x00000000) 要求が発生したので、ブルースクリーンで落とした。」
    ということを意味しています。
    これの何が問題なのかというと、0x00000006 へのメモリ参照が発生することが問題で、これは典型的なメモリ破壊を示しています。
    (もっと厳密にいえば、0x00000006 へのメモリ参照要求により、DISPATCH_LEVEL で Page Fault が発生したことが問題。)
    メモリ破壊でブルースクリーンが発生するのは、破壊された仮想メモリ アドレスへのアクセスが発生したタイミングで、その時に処理を行っていたドライバ名が、BlueScreenView や WinDBG で表示されます。
    でも、悪いのは BlueScreenView や WinDBG が表示する破壊された仮想メモリ アドレスへアクセスしたドライバではなく、仮想メモリの内容を破壊した別のドライバです。
    だけど別のドライバが仮想メモリの内容を破壊したのは、ブルースクリーンが発生する前なので、ダンプ ファイルにその情報が残らない可能性があるのであるのです。
    例えると、地雷 (メモリ破壊) を仕掛ける人 (メモリを破壊したドライバ) と、地雷を踏んじゃった人 (仮想メモリ アドレスへアクセスしたドライバ) の関係で、当然地雷を踏んじゃった人は悪くありません。
    複数のダンプで tcpip.sys や fwpkclnt.sys のドライバ名が表示されているのであれば、それらドライバに起因している可能性が高いですが、異なる STOP コードがドライバ名で落ちる場合があるなら、tcpip.sys や fwpkclnt.sys 以外の可能性の方が高いと思います。

    ということで。。。
    既に WinDBG を使っているとのことなので、採取出来ているすべてのダンプ ファイルに対して "!analyze -v" コマンドを実施し、その結果にどのような共通点があるのか、きっちり精査することをお勧めします。

    > ちなみにですが、何のソフトウェアがfwpkclnt.sysを利用しているか確認する方法はありますでしょうか?

    fwpkclnt.sys はすべてのネットワーク通信処理に介在してくるはずです。
    つまりネットワーク通信を行うすべてのソフトウェアが、fwpkclnt.sys を利用しています。
    先に説明したように、ブルースクリーン発生時に毎回 tcpip.sys や fwpkclnt.sys のドライバ名が表示されるのであれば、このドライバの処理に起因している可能性が高い。。。。ということになります。
    もっとも私は fwpkclnt.sys 関連の問題である可能性は、現状においてはとっても低いと思ってますけど。
    (この手のブルースクリーンでは、BlueScreenView や WinDBG で表示されるドライバが原因であることは、むしろまれ。)

    • 編集済み お馬鹿 2018年3月7日 9:13
    • 回答としてマーク kamiyajun 2018年3月13日 7:49
    2018年3月7日 9:13

すべての返信

  • fwpkclnt.sys は Windows フィルタリング プラットフォームのモジュールなので、サードパーティのファイアウォールなどのネットワーク トラフィックをフィルタリングするソフトウェアが原因の可能性が考えられます。

    まずは Windows および利用しているサードパーティのファイアウォールなどのセキュリティ対策ソフトウェアが最新の状態に更新されているかどうか確認しましょう。


    hebikuzure

    2018年3月6日 16:18
  • hebikuzure様

    ご回答いただきありがとうございます。

    >まずは Windows および利用しているサードパーティのファイアウォールなどのセキュリティ対策ソフトウェアが最新の状態に更新されているかどうか確認しましょう。

    この線で原因の調査を進めみたいと思います。
    ちなみにですが、何のソフトウェアがfwpkclnt.sysを利用しているか確認する方法はありますでしょうか?
    2018年3月7日 5:00
  • 何のソフトウェアがfwpkclnt.sysを利用しているか確認する方法はありますでしょうか?

    このケースのようにクラッシュする場合、一般的にはクラッシュ ダンプ ファイルを解析することでしょう。


    hebikuzure

    2018年3月7日 8:20
  • > またこの現象は、再発する場合もありますが、100%ではない上に、発生頻度が低いです。

    再現率は低くても複数の PC で起きているということは、複数のダンプ ファイルが採取されているはずですよね?
    その複数のダンプ ファイルで、STOP コードが DRIVER_IRQL_NOT_LESS_OR_EQUAL で、かつ tcpip.sys や fwpkclnt.sys のドライバ名が表示されているのでしょうか?

    すでに参照されているかもしれませんが、DRIVER_IRQL_NOT_LESS_OR_EQUAL の詳細情報は、下記サイトにあります。
    ------------------------------------------
    Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL
    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xd1--driver-irql-not-less-or-equal
    ------------------------------------------

    ちょっと難しいかもしれませんが、BlueScreenView が表示している
    "0x000000d1(0x00000006,0x00000002,0x00000000,0x8da7e662)"
    は、
    「カーネル モード側の仮想メモリ空間 0x8da7e662 の処理において、IRQL が DISPATCH_LEVEL (0x00000002) 状態で仮想メモリ アドレス 0x00000006 に対する Read (0x00000000) 要求が発生したので、ブルースクリーンで落とした。」
    ということを意味しています。
    これの何が問題なのかというと、0x00000006 へのメモリ参照が発生することが問題で、これは典型的なメモリ破壊を示しています。
    (もっと厳密にいえば、0x00000006 へのメモリ参照要求により、DISPATCH_LEVEL で Page Fault が発生したことが問題。)
    メモリ破壊でブルースクリーンが発生するのは、破壊された仮想メモリ アドレスへのアクセスが発生したタイミングで、その時に処理を行っていたドライバ名が、BlueScreenView や WinDBG で表示されます。
    でも、悪いのは BlueScreenView や WinDBG が表示する破壊された仮想メモリ アドレスへアクセスしたドライバではなく、仮想メモリの内容を破壊した別のドライバです。
    だけど別のドライバが仮想メモリの内容を破壊したのは、ブルースクリーンが発生する前なので、ダンプ ファイルにその情報が残らない可能性があるのであるのです。
    例えると、地雷 (メモリ破壊) を仕掛ける人 (メモリを破壊したドライバ) と、地雷を踏んじゃった人 (仮想メモリ アドレスへアクセスしたドライバ) の関係で、当然地雷を踏んじゃった人は悪くありません。
    複数のダンプで tcpip.sys や fwpkclnt.sys のドライバ名が表示されているのであれば、それらドライバに起因している可能性が高いですが、異なる STOP コードがドライバ名で落ちる場合があるなら、tcpip.sys や fwpkclnt.sys 以外の可能性の方が高いと思います。

    ということで。。。
    既に WinDBG を使っているとのことなので、採取出来ているすべてのダンプ ファイルに対して "!analyze -v" コマンドを実施し、その結果にどのような共通点があるのか、きっちり精査することをお勧めします。

    > ちなみにですが、何のソフトウェアがfwpkclnt.sysを利用しているか確認する方法はありますでしょうか?

    fwpkclnt.sys はすべてのネットワーク通信処理に介在してくるはずです。
    つまりネットワーク通信を行うすべてのソフトウェアが、fwpkclnt.sys を利用しています。
    先に説明したように、ブルースクリーン発生時に毎回 tcpip.sys や fwpkclnt.sys のドライバ名が表示されるのであれば、このドライバの処理に起因している可能性が高い。。。。ということになります。
    もっとも私は fwpkclnt.sys 関連の問題である可能性は、現状においてはとっても低いと思ってますけど。
    (この手のブルースクリーンでは、BlueScreenView や WinDBG で表示されるドライバが原因であることは、むしろまれ。)

    • 編集済み お馬鹿 2018年3月7日 9:13
    • 回答としてマーク kamiyajun 2018年3月13日 7:49
    2018年3月7日 9:13
  • お馬鹿 様

    非常に丁寧に、解りやすく解説いただきありがとうございます。
    お陰様で、地雷(メモリ破壊)を仕掛けた人(ドライバ)の目星がつきました。

    まだ原因が確定したわけではありませんが、質問の回答としては十分すぎるほどの
    情報をいただけたと思いますので、回答済みとさせていただきました。

    以上
    2018年3月13日 8:18