発生するのは規則違反。いうことだと思います。スタックを構成するドライバのどれかがバグっているいるんだと思います。ベンダー製ドライバの可能性も考えられる。チェックすれば簡単に見つかると思います。voter早々に丁寧な回答頂き、ありがとうございます。ほかのMiniDumpも調べていますが、どうもドライバーの作りが悪く排他制御がうまく動作していない様子です。補足しますとデバイスはPCIで、現象発生は数か所のマシンで1時間から2時間に1回程度のランダム、BSOD発生のモジュールは毎回同じMTXP2ですが、ドライバーのコード中では比較的様々な場所で発生しています。Verifier"の実機操作もできない状況なので現在、排他制御の検証コードをドライバーに作っています。結果がわかりましたらここで報告致します。ありがとうございました。voter既に複数のダンプファイルが採取されているのであれば、それらに共通点がないか再検証されることをお勧めします。陥っているようですが、他のダンプでも同様のタイミングで起きているのであれば、メモリ破壊以外に以下の可能性も考えられます。リクエストとして処理した。等に共通点があるのであれば、それが問題箇所を特定するための重要なヒントになります。voterお馬鹿様、回答とアドバイスを頂き、ありがとうございます。Verifierを入れて動かしたところ、あっさりとDRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOLというBSODが出ました。IO」だった処理をDispatchルーチンに移動したところ、発生頻度が減りました。WDF混在だったのがKMDF統一になってスッキリしましたが、まだ別のエラーが出る場合があるので、引き続き調査中です。現在は、比較的シンプルなPCIドライバーとなりました。IRPも動作の機会がありません。この件は一旦クローズさせていただきます。ありがとうございました。止めてみたところ、下記場所でした。二重解放が原因のようです。voterお馬鹿様わざわざ調べて頂いてありがとうございます。ご指摘の場所のコードには何回もぶち当たっています。まれにm_Irpがゼロになり、0x38にResult(information)を書き込むとことでBSODという現象が発生しています。根本原因は治っていない訳です。現在は該当ルーチンに入った時に、処理を進める前に、Requestの値を調べてゼロなら抜けるという消極的なBSOD回避策を試しています。WDFで完了処理していないのに、Requestが無くなる(ゼロになる)というケースは考えられないと思うのですが、いかがでしょう。0x38にResult(information)を書き込むとことでBSODという現象が発生しています。完了していると認識しているはずです。)その状態で再度完了ルーチンでの処理を実施しようとした。発生しているのだと思います。二重解放の状況に陥ってしまうことだと思います。状態に対する認識の不一致が根本的な原因だと思います。不備があると、今回のような問題が発生する可能性が考えられると思います。voterご指摘頂き、ありがとうございます。Cancel関係は使ってないのです。書き換えた事による影響ぐらいですが、それもStartIOを止めてから、通常運用では問題無く動作する様になりました。お客様先の実機でテスト用のアプリを動作させた場合、ごくまれにRequestがゼロになる現象が発生していたのですが、それもさらに「Requestの値を調べてゼロなら抜ける」という処理で発生しなくなりました。Cancelが無く、Completeもしてないのに、どこでRequestがゼロになる場合が発生するのかはいまだに不明なのですが、取りあえずは再現が難しくなってしまったので、このまま様子を見ています。voter釈迦に説法なのかもしれませんが。二重解放が原因だと思います。リクエスト処理」にあると考えます。発生するのがほとんどです。特定できれば、確認すべき実装個所も特定できると思っています。二重解放が発生しているのかを確認する。いう調査を実施すると思います。気にかけて頂きまして、ありがとうございます。消える(ゼロ)になる場所が、ioControlのDispatchルーチンに入った直後だったり、該当ドライバーに入る前だったりしているのです。以前から特定の場所では発生していないのは何となく感じていたのですが、決定的な状況です。モグラ叩き的な対策をした結果、頻度は減ったのですがとんでもない所にモグラが出るようになったという事です。ハンドラhttps://github.com/Microsoft/Windows-Driver-Frameworks/blob/master/src/framework/shared/irphandlers/io/fxioqueue.cppの3238行目のpIrpがゼロなのです。pIrp->GetMajorFunction();根拠はありませんが、ハードウェアがらみの問題ではないかと思っています。3238行目のpIrpがゼロなのです。二重解放かメモリ破壊かのいずれかが起きたと考えるのが妥当だと思います。起因しているのであれば、メモリ破壊の可能性は極めて低いと思います。メンバーの破壊を、不定期に起こせるとは思えません。二重解放が原因だと思います。コードでのみ発生しているのかもしれません。張り止めてみたところ、以下のような感じで確認できました。コードを処理中であることが分かります。ダンプ」を採取すれば、きちんとここまで確認できると思います。なることに起因して発生しているということなので、個人的には「ハードウェアがらみの問題」ということは無いと思います。することなど不可能だと思っています。voterお馬鹿様、この問題は結局のところ、次の2点の方策で解決しましたで、ご報告させていただきます。以前試していた、他のモグラ叩き的な処理は全て外しました。変更この処理で、発生頻度が約半分程度になり5~10時間に1回程度から、1~2日で1回程度になりました。Item処理の廃止この処理で、実験環境で1週間以上連続運転しても発生しなくなりました。Itemのソースコードは公開されていないのと、最終修正の直前状態では、再現までかなりの時間がかかる様になったで、真の原因は不明のままです。真の原因は不明のままです。チェックでも検出できなかったのでしょうか?はい。対応のためにコードをかなりいじってました。有無、設定のいかんにかかわらず、数時間ぐらい経ってRequest(IRP)が空になり、それに起因するBSOD発生という状況でした。テストなので、IoCcontrolを20個ぐらいに絞り、発生頻度を上げるために、アプリ呼び出しをマルチスレッドで繰り返して回しいましたが、発生するIoControlや場所は不定でした。その後、対策が思いつかないので前記1.を試して発生頻度が減ったので、前記2.を試したところ、うまくいったという事です。この処理で、発生頻度が約半分程度になり5~10時間に1回程度から、1~2日で1回程度になりました。処理よりも優先されます。処理において、その優先順位に矛盾が発生するロジックになっていたのだと思います。(私が自分でデバッグしたわけではないので、単なる「空想」ですが。voterそこらへんの確認は基本的な事ですので、何回もしていました。Itemを止めたらピタリと止まったことと合わせて、真相は謎のままです。