スキップしてメイン コンテンツへ

 none
PNPDTESTでPNPFILTERがダンマリになる RRS feed

  • 質問

  • 開発したUSBデバイスドライバを、Plag and Play Driver Test(PNPDTEST)で動作確認するとPNPFILTERがダンマリになる現象が発生し、PNPDTESTが最後まで進みません。
    このドライバはWDMで開発し、WinXPでのWHQL実績あります。
    この度の不具合がネックでWHQL再取得が困難な状況です。対処方法を御教示ください。

    <テスト内容>
    ツール:PNPDTEST
    設 定:Power Test OptionsでEnable Power TestsをSleep state=S4に設定にしてTest Surprise Remove実行。
    その他:Power Test Optionsを設定せずにTest Surprise Remove実行した場合は最後まで正常に動作する。Verifer有効

    <現象詳細>
    WindbgにPNPFILTRが出力するログを下記に示す。
    ログ最後尾("PNPFILTR: Waiting for result to be stored")以降、PNPFILTRがダンマリになりハイバネート状態にならない(ディスプレイは電源断となる)。一定時間経過後、DRIVER_POWER_STATE_FAILURE(9f)となる。
    ドライバでIRP_MN_SURPRISE_REMOVAL処理後、IRP_MN_REMOVE_DEVICE要求受信前のPNPFILTRの処理中でダンマリになっているものと推測する。

    <発生頻度>
    必ず発生

    <参考情報>
    他USBデバイス(市販のUSBメモリ)でも同一の手順で同一の現象が発生することを確認


    <Bugcheck Analysis出力内容>

    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    DRIVER_POWER_STATE_FAILURE (9f)
    A driver is causing an inconsistent power state.
    Arguments:
    Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp
       subsystem.
    Arg2: 00000258, Timeout in seconds.
    Arg3: 849b4798, The thread currently holding on to the Pnp lock.
    Arg4: 82962b24


    <WinDbgで出力したPNPFILTRのログ>

    Start: Surprise Remove, TUID=

    Running Surprise Removal Test on node with hwid:

    USB\VID_XXXX&PID_XXXX&REV_0100

    PNPFILTR: Received IOCTL_QUERY_DEVICE_COUNT
    PNPFILTR: Received IOCTL_QUERY_HARDWARE_ID_SIZE for PDO 0x86683030
    PNPFILTR: Received IOCTL_QUERY_HARDWARE_ID for PDO 0x86683030
    PNPFILTR: Received IOCTL_SURPRISE_REMOVE_DEVICE for PDO 0x86683030
    PNPFILTR: Calling IoInvalidateDeviceState to start rebalance on PDO 86683030
    PNPFILTR: Received IRP_MN_QUERY_PNP_DEVICE_STATE for stack with PDO 0x86683030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Completing IRP_MN_QUERY_PNP_DEVICE_STATE for PDO 0x86683030 with status 0x00000000 and information 0x00000004
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_SURPRISE_REMOVAL for stack with PDO 0x86683030
    PNPFILTR: FilterSurpriseRemove returning 0x00000004 for stack with PDO 0x86683030
    PNPFILTR: Received IRP_MN_REMOVE_DEVICE for stack with PDO 0x86683030
    PNPFILTR: Setting the test completed event
    PNPFILTR: Waiting for result to be stored
     

    • 移動 Mike Wang (MSCS) 2012年10月2日 12:40 (移動元:Windows デバイスドライバー開発)
    2010年6月22日 11:11

すべての返信

  • 投稿されてからかなり時間が経過しているので、既に解決しているかもしれませんが...
    参考になるかどうかわかりませんが、とりあえず気になったことを書いておきます。

    PNPFILTR: Completing IRP_MN_QUERY_PNP_DEVICE_STATE for PDO 0x86683030 with status 0x00000000 and information 0x00000004

     ↑ 上記ログが手掛かりになるかもしれないと思います。

    このログは、IRP_MJ_PNP - IRP_MN_QUERY_PNP_DEVICE_STATE で、IO_STATUS_BLOCK 構造体 Information メンバに PNP_DEVICE_FAILED
    フラグがセットされたことを意味している思いますが、その直前に IoInvalidateDeviceState() コールが発行されている形跡があります。

    つまり、デバイス PnP ステートが変化したことを示唆しているのだと思うのですが、このとき IO_STATUS_BLOCK 構造体 Information メンバに
    セットされるフラグが PNP_DEVICE_FAILED だけというのは不自然の様な気がします。

    "PNP_DEVICE_FAILED" をキーワードに、グーグル先生に聞いてみたところ、PNPDTEST と IRP_MN_QUERY_PNP_DEVICE_STATE に関連した
    下記サイトを見つけました。
    (...とは言ってもかなり古い情報なので、現在もこの情報が有効であるのかは不明ですが。。。)

    Windows Vista の PCI マルチレベル リバランス
    http://www.microsoft.com/japan/whdc/archive/multilevel-rebal.mspx


    リバランスのシナリオに対するドライバのテスト

    ....
    ....

    ドライバにテスト インターフェイスを追加するユーザー モードのテスト アプリケーションから呼び出されたときに IoInvalidateDeviceState ルーチンを呼び出すテスト インターフェイスを、ドライバ コード内に実装できます。
    それに応え、カーネルのプラグ アンド プレイ マネージャは、IRP_MN_QUERY_PNP_DEVICE_STATE 要求でデバイス スタックを呼び出します。これを受けてドライバは、Irp->IoStatus.Status を STATUS_SUCCESS に設定します。
    また、Irp->IoStatus.Information を、 PNP_DEVICE_FAILED フラグと PNP_DEVICE_RESOURCE_REQUIREMENTS_CHANGED フラグが設定された PNP_DEVICE_STATE ビットマスクに設定します。
    次に、カーネルのプラグ アンド プレイ マネージャは、IRP_MN_QUERY_STOP 要求でデバイス スタックを呼び出します。
    これで、Query Stop のロジックと処理の機能をテストできます。

    ....
    ....

     ということで、IRP_MJ_PNP - IRP_MN_QUERY_PNP_DEVICE_STATE で PNP_DEVICE_FAILED フラグをセットする際には、
    一緒に PNP_DEVICE_RESOURCE_REQUIREMENTS_CHANGED フラグもセットするように実装を変更して試してみてはいかがでしょうか?
    (...まったく根拠はありませんけど。)

    2010年7月5日 5:08
  • ニコチャン大王様

    返信有難うございました。
    早速、御教示頂いた情報をドライバに盛り込み、動作確認したところPower Test Options設定した状態でのTest Surprise Removeは正常に動作するようになりました。
    大変助かりました。
    そこでWHQL本来のテストである、Power Test Options設定した状態でStress Testを確認したところ、まだPNPFILTERの同じ個所(ログ最後尾)でダンマリになるようです。
    ただ今回対策したことで、Stress TestでのDRIVER_POWER_STATE_FAILURE(9f)の発生頻度は少なくなったようです(Stress Testが最後まで正常に動作する頻度が増えた)。
    何度か試してみましたが、IRP_MN_SURPRISE_REMOVAL処理の前後に"[SC-CLIENT] !! Service timeout"が発生した場合に、必ずPNPFILTERがダンマリになり、ハイバネート状態にならないようです。
    Power Test Options設定をしなくても"[SC-CLIENT] !! Service timeout"ログは稀に発生するのですが、Stress Testは最後迄正常に動作します。
    何か判りましたら再度御教示頂けると大変助かります。


    <WinDbgで出力したPNPFILTERのログ>
    *******************************************************************************
    *
    * This is the string you add to your checkin description
    * Driver Verifier: Enabled for pnpfiltr.sys on Build 7600 WOPJkbwlQfZ92hQiJGWSzG
    *
    *******************************************************************************
    PNPFILTR: Entered Pnpfiltr DriverEntry of built on Nov 21 2009 at 00:19:33
    PNPFILTR: Events being initialized
    PNPFILTR: Received IRP_MN_QUERY_LEGACY_BUS_INFORMATION which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_RESOURCE_REQUIREMENTS  which I am simply passing down
    PNPFILTR: Received IRP_MN_FILTER_RESOURCE_REQUIREMENT for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterFilterResourceRequirement returning 0x00000004 for stack with PDO 0x82DD42E0
    PNPFILTR: Received IRP_MN_START_DEVICE for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Time taken for IRP_MN_START_DEVICE to get processed for the PDO 82DD42E0 is 197 miliseconds
    PNPFILTR: Completing Start request with status == 0x00000002 PDO = 0x82DD42E0
    PNPFILTR: Received IRP_MN_QUERY_INTERFACE  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_PNP_DEVICE_STATE for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Completing IRP_MN_QUERY_PNP_DEVICE_STATE for PDO 0x82DD42E0 with status 0x00000000 and information 0x00000010
    PNPFILTR: List has 0 entries
    PNPFILTR: Processed 0 IRPs
    PNPFILTR: List has 0 entries
    PNPFILTR: Processed 0 IRPs
    PNPFILTR: Passing down unhandled PNP IRP - minor function = 0xff
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_TEXT  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_ID which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_INTERFACE  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_INTERFACE  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_RESOURCE_REQUIREMENTS  which I am simply passing down
    PNPFILTR: Received IRP_MN_FILTER_RESOURCE_REQUIREMENT for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterFilterResourceRequirement returning 0x00000004 for stack with PDO 0x82DD42E0
    PNPFILTR: Received IOCTL_QUERY_DEVICE_COUNT
    PNPFILTR: Received IOCTL_QUERY_HARDWARE_ID_SIZE for PDO 0x82DD42E0
    PNPFILTR: Received IOCTL_QUERY_HARDWARE_ID for PDO 0x82DD42E0
    PNPFILTR: Received IOCTL_REBALANCE_DEVICE for PDO 0x82DD42E0
    PNPFILTR: Calling IoInvalidateDeviceState on PDO 82DD42E0
    PNPFILTR: Received IRP_MN_QUERY_PNP_DEVICE_STATE for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Completing IRP_MN_QUERY_PNP_DEVICE_STATE for PDO 0x82DD42E0 with status 0x00000000 and information 0x00000014
    PNPFILTR: Received IRP_MN_QUERY_STOP_DEVICE for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterQueryStop returning 0x00000004 for stack with PDO 0x82DD42E0
    PNPFILTR: Received IRP_MN_QUERY_RESOURCE_REQUIREMENTS  which I am simply passing down
    PNPFILTR: Received IRP_MN_FILTER_RESOURCE_REQUIREMENT for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Fake(new) Requirements created for PDO 0x82DD42E0
    PNPFILTR: FilterFilterResourceRequirement returning 0x00000004 for stack with PDO 0x82DD42E0
    PNPFILTR: Received IRP_MN_QUERY_INTERFACE  which I am simply passing down
    PNPFILTR: Received IRP_MN_STOP_DEVICE for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Time taken for IRP_MN_STOP_DEVICE to get processed for the PDO 82DD42E0 is 171 miliseconds
    PNPFILTR: Completing FilterStop with status 0x2 for stack with PDO 0x82dd42e0
    PNPFILTR: Received IRP_MN_START_DEVICE for stack with PDO 0x82DD42E0
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Time taken for IRP_MN_START_DEVICE to get processed for the PDO 82DD42E0 is 187 miliseconds
    PNPFILTR: Failing IRP_MN_START_DEVICE as requested . PDO = 0x82DD42E0
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_SURPRISE_REMOVAL for stack with PDO 0x82DD42E0
    [SC-CLIENT] !! Service timeout: Service CertPropSvc, PID 0x000003e8, OpCode 0x0000000b, Timeout 0x00007530 took 90031 msec !!
    PNPFILTR: FilterSurpriseRemove returning 0x00000004 for stack with PDO 0x82DD42E0
    PNPFILTR: Received IRP_MN_REMOVE_DEVICE for stack with PDO 0x82DD42E0
    PNPFILTR: Setting the test completed event
    PNPFILTR: Waiting for result to be stored

     

    2010年7月6日 5:14
  • ちょっと話を戻して申し訳無いのですが、一番初めに提示されていた "DRIVER_POWER_STATE_FAILURE (9f)" で
    BSOD になった時まで遡らせていただきます。

    このログの一番初めには、以下の出力があります。

    DRIVER_POWER_STATE_FAILURE (9f)
    A driver is causing an inconsistent power state.
    Arguments:
    Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp subsystem.
    Arg2: 00000258, Timeout in seconds.
    Arg3: 849b4798, The thread currently holding on to the Pnp lock.
    Arg4: 82962b24

     つまり、根本的な原因は、Thread 0x849b4798 で、PnP リクエストが完了せずに Pending 状態になったままに
    なってしまっている可能性が考えられると思います。
    なので、Thread 0x849b4798 でなんの PnP リクエストがどのような理由により Pending 状態になってしまっている
    のかを突き詰めれば、問題は解決すると思います。

    この手の調査は、WinDBG によるダンプ解析か、もしくはライブ デバッグが一番確実です。
    既に WinDBG を使われているようですが、シンボル パスの設定はされていますでしょうか?
    ライブ デバッグを行うためには、ご自身のドライバのシンボルを合わせるのはもちろん、Micorosoft が提供している
    シンボル サーバーへのパスを設定することが重要です。
    (Microsoft が提供しているシンボル サーバーにパスを通すと、必要な pdb ファイルを自動的にダウンロードしてくれので、
     とても便利で、かつ今まで見れなかった OS 内部の「入口」が覗けるようになります。)

    WinDBG 上でのシンボル サーバーの設定は、以下のサイトが参考になると思います。

    デバッグ ツールとシンボル: はじめ
    http://www.microsoft.com/japan/whdc/devtools/debugging/debugstart.mspx
    ....
    たとえば、シンボルを c:\websymbols にダウンロードするには、シンボル パスに下記を追加します。
    SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
    ....

     Microsoft のシンボル サーバと、ご自身のドライバのシンボル パスを設定したら、
    Bugcheck 9f でデバッガに落ちたタイミングで、"kvn" コマンド等でコール スタックの状態を確認すれば、
    なんで Arg3 が示す Thread で PnP リクエストが Lock された状態のままになってしまっているかが、
    分かるかもしれません。
    もしかしたら、"!thread <address>" コマンドの方が、Thread の詳細情報が確認できるかもしれません。
    (上記 <address> 部分は、Arg3 で示される値になります。
    また Arg4 が何を示しているのかは不明ですが、もしかししたら IRP かも...もしそうなら、かなりの手がかりになるはず。)

    それと今回のご質問である

    "[SC-CLIENT] !! Service timeout" 出力時にダンマリになる。。。

    件ですが、推測ですけど、

     タイムアウト発生時に、その PnP リクエストを適切に完了もしくはキャンセルしていないためでは。。。

    と思います。
    なので、結局は一番初めの DRIVER_POWER_STATE_FAILURE (9f) と同じ問題のような気がしています。
    (間違っていたらごめんなさい...)

     

     

    2010年7月6日 9:05
  • ニコチャン大王様

    度々の御返信大変感謝しています。
    早速、WindbgのThreadコマンドで情報を出力しました。
    まだこちらでは出力された情報が何を示しているのか良く判らず調査中ですが、参考までに出力情報を添付させて頂きました。
    もし、何か判りましたら御教示頂けると幸いです。

    <WindbgのThreadコマンドで出力した情報>

    *** Fatal System Error: 0x0000009f
                           (0x00000004,0x00000258,0x84BF0798,0x83179B24)

    Break instruction exception - code 80000003 (first chance)

    A fatal system error has occurred.
    Debugger entered on first try; Bugcheck callbacks have not been invoked.

    A fatal system error has occurred.

    Connected to Windows Vista 7600 x86 compatible target, ptr64 FALSE
    Loading Kernel Symbols
    ...........................................................................................................................................
    Loading User Symbols

    Loading unloaded module list
    ...................
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 9F, {4, 258, 84bf0798, 83179b24}

    Probably caused by : memory_corruption

    Followup: memory_corruption
    ---------

    nt!RtlpBreakWithStatusInstruction:
    830be394 cc              int     3
    kd> .reload
    Connected to Windows Vista 7600 x86 compatible target, ptr64 FALSE
    Loading Kernel Symbols
    ...........................................................................................................................................
    Loading User Symbols

    Loading unloaded module list
    ...................
    kd> !thread 0x84BF0798
    THREAD 84bf0798  Cid 0004.0044  Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
        86762e1c  NotificationEvent
    IRP List:
        8a0dee28: (0006,01d8) Flags: 40000000  Mdl: 00000000
    Not impersonating
    DeviceMap                 86207888
    Owning Process            84b37a20       Image:         System
    Wait Start TickCount      14647          Ticks: 38383 (0:00:09:59.734)
    Context Switch Count      462  NoStackSwap
    UserTime                  00:00:00.0000
    KernelTime                00:00:01.0015
    Win32 Start Address nt!ExpWorkerThread (0x830c0e1e)
    Stack Init 807f1fd0 Current 807f17e8 Base 807f2000 Limit 807ef000 Call 0
    Priority 13 BasePriority 12 PriorityDecrement 0
    *** ERROR: Module load completed but symbols could not be loaded for pnpfiltr.sys
    ChildEBP RetAddr  Args to Child             
    807f1800 830c1b15 84bf0798 00000000 8317cd20 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
    807f1838 830c0403 84bf0858 84bf0798 86762e1c nt!KiSwapThread+0x266
    807f1860 830ba2cf 84bf0798 84bf0858 00000000 nt!KiCommitThreadWait+0x1df
    807f18dc 8338d9b3 86762e1c 00000000 00000000 nt!KeWaitForSingleObject+0x393
    807f190c 9354e007 86762e1c 00000000 00000000 nt!VerifierKeWaitForSingleObject+0xfe
    WARNING: Stack unwind information not available. Following frames may be wrong.
    807f1934 9354dcc7 86762cd8 8a0dee28 86689248 pnpfiltr+0x3007
    807f194c 833826c3 86762cd8 8a0dee28 86762cd8 pnpfiltr+0x2cc7
    807f1970 8308f473 00000000 8a0defd4 86762cd8 nt!IovCallDriver+0x258
    807f1984 833941e8 86651b00 8a0dee28 867ed020 nt!IofCallDriver+0x1b
    807f199c 833826c3 867ed020 86762cd8 8a0defd4 nt!ViFilterDispatchPnp+0xd3
    807f19c0 8308f473 00000000 8a0deff8 867ed020 nt!IovCallDriver+0x258
    807f19d4 837d9913 00000000 867430e0 807f1a38 nt!IofCallDriver+0x1b
    807f19e8 837d26d6 807f1a38 8676be40 867430e0 Wdf01000!FxPkgFdo::ProcessRemoveDeviceOverload+0x52 (FPO: [Non-Fpo])
    807f1a10 837d3e02 867430e0 8676be40 8a0dee28 Wdf01000!FxPkgPnp::_PnpRemoveDevice+0xd2 (FPO: [Non-Fpo])
    807f1a30 837b0a3f 8a0dee28 807f1a58 837b0c63 Wdf01000!FxPkgPnp::Dispatch+0x207 (FPO: [Non-Fpo])
    807f1a3c 837b0c63 913504a8 8a0dee28 867a6618 Wdf01000!FxDevice::Dispatch+0x7f (FPO: [Non-Fpo])
    807f1a58 833826c3 913504a8 00000000 8a0df000 Wdf01000!FxDevice::DispatchWithLock+0x7b (FPO: [Non-Fpo])
    807f1a7c 8308f473 00000000 807f1b14 913504a8 nt!IovCallDriver+0x258
    807f1a90 8322fedf 866546a8 866a9008 866546a8 nt!IofCallDriver+0x1b
    807f1ac0 83206b3d 866546a8 00000000 866a9008 nt!IopSynchronousCall+0xc2
    807f1b18 83067c3a 866546a8 00000002 93b43450 nt!IopRemoveDevice+0xd4
    807f1b44 83206951 0000000a 93b43450 00000000 nt!PnpRemoveLockedDeviceNode+0x16c
    807f1b58 832068b7 00000002 0000000a 00000000 nt!PnpDeleteLockedDeviceNode+0x2d
    807f1b8c 83311973 866546a8 93b43450 00000002 nt!PnpDeleteLockedDeviceNodes+0x4c
    807f1bc4 833118f3 867a9b30 00000000 8301f870 nt!PnpDelayedRemoveWorker+0x54
    807f1be0 8306855e 866546a8 00000001 866a9008 nt!PnpChainDereferenceComplete+0xe7
    807f1c0c 83206534 8f2341c0 00000002 00000000 nt!PnpIsChainDereferenced+0x77
    807f1cc4 83208210 807f1cf4 00000000 87003750 nt!PnpProcessQueryRemoveAndEject+0xc42
    807f1cdc 83209d58 00000000 9139dc40 84bf0798 nt!PnpProcessTargetDeviceEvent+0x38
    807f1d00 830c0f2b 9139dc40 00000000 84bf0798 nt!PnpDeviceEventWorker+0x216
    807f1d50 8326166d 00000001 c5bc8701 00000000 nt!ExpWorkerThread+0x10d
    807f1d90 831130d9 830c0e1e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

     

    2010年7月7日 2:06
  • このコール スタックを見ると、以前のログでも出力されていたように、IRP_MN_REMOVE_DEVICE の完了待ちの
    状態だと思います。
    (ただ、開発素人さんのドライバのフレームが見当たらないのがちょっと気になりますけど。)

    まず解析の第一歩として、このコール スタックの処理で、開発素人さんのドライバが介在しているかを確認する
    ことが大切だと思います。
    開発素人さんのドライバが介在しているが確認出来たら、このコールスタックがどの PNP IRP の処理中なのか
    確認して、その IRP 処理に対応する Source Code での実装を確認されることをお勧め致します。

    開発素人さんのドライバが介在しているかの確認方法ですが、デバイス スタックを確認すれば良いと思います。
    今回ご提示いただいたコール スタックですと、Frame 06 の以下の部分を手掛かりにすれば良いと思います。

    807f194c 833826c3 86762cd8 8a0dee28 86762cd8 pnpfiltr+0x2cc7

     上記 Frame 06 は pnpfilter ドライバの ディスパッチ ルーチンであると考えられますので、表示されている値は、
    ログ出力にもありますように以下の情報を示していると思います。

    807f194c : Child EBP
    833826c3 : Return Address
    86762cd8 : 1st Parameter <PDEVICE_OBJECT>
    8a0dee28 : 2nd Parameter <PIRP>

    つまり 1st Parameter である 0x86762cd8 は pnpfilter ドライバの DEIVCE_OBJECT 構造体へのポインタ、
    2nd Parameter である 0x8a0dee28 はこのドライバにリクエストされた IRP 構造体へのポインタであると考えられます。

    0x86762cd8 が本当に DEIVCE_OBJECT 構造体へのポインタであるかを手っ取り早く確認するには (色々と方法はありますが) 、
    "!devobj <address>" コマンドと使うと良いと思います。
    この場合ですと以下のようになります。

    kd> !devobj 0x86762cd8

    0x86762cd8 がデバイス オブジェクトである場合、その情報がデバッガ上に表示されるはずです。
    次に、ご自身のドライバが介在しているかを確認するには、以下のコマンドを使えば良いと思います。

    kd> !devstack 0x86762cd8

    上記コマンドを実行すると、pnpfilter のデバイス オブジェクトである 0x86762cd8 が属する デバイス スタック情報が
    表示されると思います。
    ここに、ご自身のドライバがリストされているかを確認すればよいと思います。
    (ただし、表示されなかったからと言って、必ずしもご自身のドライバが無関係であることにはならないので、ご注意ください。)

    次に IRP の確認ですが、"!irp <address>" コマンドを使えば確認できると思います。
    先のデバッグ ログにも 0x8a0dee28 が IRP である旨の出力がありましたので、以下のようになります。

    kd> !irp 0x8a0dee28

    上記コマンドを実行すると、IRP の Major Function / Minor Function をはじめとする情報が出てきますので、
    このスレッドがどのような IRP の処理中なのかを特定することができると思います。
    (おそらく IRP_MJ_PNP - IRP_MN_REMOVE_DEVICE だと思いますが...)

    後はライブデバッグで丹念にトレースして、正常に動作する場合をとそうでない場合の違いがどこにあるかを
    追っていけば、問題現象の原因に辿りつけると思います。

    2010年7月7日 5:01
  • ニコチャン大王様

    早速の御返信とても感謝しております。
    この度御教示頂いた情報は出力情報が多く、何を意味しているのか判りませんが、取りあえず添付させて頂きますので、再度何か判りましたら御教示頂けると幸いです。
    尚、出力情報のうち、弊社開発のドライバ名称をMyDriver、ベンダーID及びプロダクトIDを0000とさせて頂きますので予め御了承ください。


    kd> !devobj 0x86762cd8
    Device object (86762cd8) is for:
      \Driver\pnpstress DriverObject 938b5040
    Current Irp 00000000 RefCount 0 Type 00000031 Flags 00002004
    DevExt 86762d90 DevObjExt 86762e68
    ExtensionFlags (0xc0000808)  DOE_REMOVE_PROCESSED, DOE_BOTTOM_OF_FDO_STACK,
                                 DOE_DESIGNATED_FDO
                                 Unknown flags 0x00000800
    AttachedDevice (Upper) 867ed020 \DRIVER\VERIFIER_FILTER
    AttachedTo (Lower) 8f206020 \DRIVER\VERIFIER_FILTER
    Device queue is not busy.

    kd> !devstack 0x86762cd8
      !DevObj   !DrvObj            !DevExt   ObjectName
      913504a8  \Driver\scfilter   938a91d8 
      867ed020  \DRIVER\VERIFIER_FILTER867ed0d8 
    > 86762cd8  \Driver\pnpstress  86762d90 
      8f206020  \DRIVER\VERIFIER_FILTER8f2060d8 
      938f5638  \Driver\MyDriver   938f56f0 
      938f18e8  \DRIVER\VERIFIER_FILTER938f19a0 
      866546a8  \Driver\usbhub     86654760 
    !DevNode 866a9008 :
      DeviceInst is "USB\VID_0000&PID_0000\5&1cd9330c&0&1"
      ServiceName is "MyDriver"

    kd> !irp 0x8a0dee28
    Irp is active with 10 stacks 8 is current (= 0x8a0def94)
     No Mdl: No System Buffer: Thread 84bf0798:  Irp stack trace. 
         cmd  flg cl Device   File     Completion-Context
     [  0, 0]   0  0 00000000 00000000 00000000-00000000   

       Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0  0 00000000 00000000 00000000-00000000   

       Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0  0 00000000 00000000 00000000-00000000   

       Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0  0 00000000 00000000 00000000-00000000   

       Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0  0 00000000 00000000 00000000-00000000   

       Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0  0 00000000 00000000 00000000-00000000   

       Args: 00000000 00000000 00000000 00000000
     [  0, 0]   0 10 00000000 00000000 00000000-00000000   

       Args: 00000000 00000000 00000000 00000000
    >[ 1b, 2]   0 e0 86762cd8 00000000 83388d3a-8a0defb8 Success Error Cancel
            \Driver\pnpstress nt!IovpInternalCompletionTrap
       Args: 00000000 00000000 00000000 00000000
     [ 1b, 2]   0 e0 867ed020 00000000 83388d3a-8a0defdc Success Error Cancel
            \DRIVER\VERIFIER_FILTER nt!IovpInternalCompletionTrap
       Args: 00000000 00000000 00000000 00000000
     [ 1b, 2]   0  0 913504a8 00000000 00000000-00000000   
            \Driver\scfilter
       Args: 00000000 00000000 00000000 00000000

     

    2010年7月7日 6:23
  • "!irp 0x8a0dee28" の結果に "[ 1b, 2]" とありますので、一番初めのログにもありました
    IRP_MJ_PNP - IRP_MN_REMOVE_DEVICE の処理でダンマリになっていると思います。
    ただ、"!irp 0x8a0dee28" が示す IO_STACK_LOCATION 情報には開発素人さんの "MyDriver" の
    スタック ロケーションが存在していないので、根本的な問題は一つ前の IRP_MN_SURPRISE_REMOVAL
    の処理で起きている可能性があると思います。

    (ちなみに、開発素人さんが開発されているのは、Samart Card Reader 用のドライバでしょうか?)

    "!devstack 0x86762cd8" コマンドの結果から、"MyDriver" が作成したデバイス オブジェクトが
    0x938f5638 であることが分かりますので、以下のコマンドでそのデバイス オブジェクトがどのような
    状態にあるかを確認する必要があると思います。

    kd> !devobj 0x938f5638

    IRP_MN_SURPRISE_REMOVAL での処理に関しては、下記サイトに詳細情報がありますので、
    開発素人さんのドライバの実装が、このドキュメントで示されている処理に準じているかを確認されては
    いかがでしょうか?

    Handling an IRP_MN_SURPRISE_REMOVAL Request
    http://msdn.microsoft.com/en-us/library/ff546699(VS.85).aspx

     既に参照されているかもしれませんが (Windows 7 以降の WDK からは削除されてしまいましたが)、
    Vsita / Server2008 WDK (6001.18002) には bulkusb.sys というサンプル ドライバが提供されており、
    このドライバ ソース コード内に IRP_MN_SURPRISE_REMOVAL に関する実装例がありますので、そちらも
    参考になると思います。

    ただその他にも、IoAcquireRemoveLock() / IoReleseRemoveLock() がちゃんとペアにならないケースが
    ある場合でも、このような現象が発生する可能性があると思います。

    (まったくの推測なので、間違っていたらごめんなさい。)

    2010年7月7日 12:13
  • ニコチャン大王様

    度々の御返信とても感謝しております。
    こちらもいい勉強になっています。
    MyDriverのデバイスオブジェクトの状態を出力しましたので添付致します。
    本日、改めて現象を再現させての出力結果ですので、アドレスが異なっていますが御了承ください。
    再度IRP_MN_SURPRISE_REMOVAL処理を見直します。

    >Samart Card Reader 用のドライバでしょうか?
      やはり判りますか。そのとおりです。

    kd> !devobj 0x8e8aa358
    Device object (8e8aa358) is for:
      \Driver\MyDriver DriverObject 86604e70
    Current Irp 00000000 RefCount 0 Type 00000031 Flags 0000200c
    DevExt 8e8aa410 DevObjExt 8e8aa808
    ExtensionFlags (0xe0000808)  DOE_REMOVE_PROCESSED, DOE_RAW_FDO,
                                 DOE_BOTTOM_OF_FDO_STACK, DOE_DESIGNATED_FDO
                                 Unknown flags 0x00000800
    AttachedDevice (Upper) 82dc8638 \DRIVER\VERIFIER_FILTER
    AttachedTo (Lower) 8e8dd020 \DRIVER\VERIFIER_FILTER
    Device queue is not busy.

     

    2010年7月8日 0:50
  • やっぱり、ExtensionFlags には DOE_REMOVE_PROCESSED はセットされていますが、DOE_DELETE_PENDING はセット
    されていませんね。。。
    なので、ここまでの状況を整理すると、MyDriver は IRP_MN_SURPRISE_REMOVAL リクエストは一応受け取っているけど、
    その後の IRP_MN_REMOVE_DEVICE リクエストが届かないので、今回の問題が発生しているように思います。

    つまり本来ならば、MyDriver に IRP_MN_REMOVE_DEVICE リクエストが来て、MyDriver 自身が IoDeleteDevice() を
    コールして、自身が作成したデバイス オブジェクトを破棄して...という一連のデバイスの削除処理が行われなければ
    ならないと思うのですが、そのリクエストが MyDriver に届かないのでデバイス オブジェクトを破棄出来ず、
    デバイス スタックも残ったままの状態になってるんだと思います。

    もしかしたら (相変わらず推測で申し訳ありませんが)、WinDB に "[SC-CLIENT] !! Service timeout" が出力される時と
    されない時では、IO_STATUS_BLOCK 構造体の Information メンバにセットされるフラグが異なっていて、それが引き金に
    なって今回の現象が発生しているのかも。

    正直ここまで来ると、後はライブ デバッグで PnP State の状態遷移をトレースしていく以外に調査方法は無いと思うので、
    大したアドバイスはできないのですが、とりあえず以下の点を確認されてはいかがでしょうか?

     - MyDriver の PnP ディスパッチ ルーチンに IRP_MN_SURPRISE_REMOVAL が渡されてきたときに
       リターンする際の、IO_STATUS_BLOCK 構造体 Information メンバにセットされている値。
       ("[SC-CLIENT] !! Service timeout" が出力される場合とされない場合で差異はあるか?)

     - "[SC-CLIENT] !! Service timeout" が出力された場合に、その後の IRP_MN_REMOVE_DEVICE リクエストが
       MyDriver の PnP ディスパッチ ルーチンにまで届いているか?

    上記2点に差異が見られない場合、IRP_MN_SURPRISE_REMOVAL よりもさらに前のリクエストについても、
    同じようにトレースしていく必要があるかもしれません。

    また、もしかしたら「DTM ツール、あるいは Smart Card サービスの不具合。。。」なんてケースも考えられますので、
    それも考慮しないといけないのかも...と、ちょっとだけ思います。
    (もっとも、DTM ツールやサービス、あるいは環境等を疑うのは、ご自身の潔白を確認された後でも遅くはないとおもいますが。)

    余談ですが...
    Smart Card Reader 用のドライバだとわかったのは、!devobj コマンドの出力に、"Type 00000031" とあったからです。
    この表示は、DEVICE_OBJECT 構造体の DeviceType メンバに対応しているようで、wdm.h ヘッダーファイルに定義されている、
    FILE_DEVICE_XXX を示しているはずだったと思います。
    DeviceType == 0x00000031 ... つまり FILE_DEVICE_SMARTCARD なので Smart Card Reader なのかな...と思った次第です。

    あと、私は DTM をほとんど使っていないので、残念ながら(?)このような問題に遭遇したことは無いのですが、
    ロゴを取得されたドライバの開発者の中には、今回のケースの様な問題に遭遇されたは方が結構いらっしゃるのでは...
    そういう方々がもっと積極的に発信してくださるととっても嬉しいのに...と、ちょっと感じております。(独り言)

    2010年7月8日 7:10
  • ニコチャン大王様

    度々の御返信深謝致します。
    この度の投稿の初期のころ、ニコチャン大王様より

    「IRP_MJ_PNP - IRP_MN_QUERY_PNP_DEVICE_STATE で PNP_DEVICE_FAILED フラグをセットする際には、一緒に PNP_DEVICE_RESOURCE_REQUIREMENTS_CHANGED フラグもセットするように実装を変更」

    との御提案に沿って対策し「Power Test OptionsでEnable Power TestsをSleep state=S4に設定にしてTest Surprise Remove実行」の条件でも問題なく動作することが出来ました。
    対策後の「Power Test OptionsでEnable Power TestsをSleep state=S4に設定にしてTest Surprise Remove実行」した時のWinDbgで出力したPNPFILTERのログを下記に示します。
    対策することによって、IRP_MN_SURPRISE_REMOVAL要求が無くなり正常動作するようになったようです。
    このテストケースでは対策前後の何れも"[SC-CLIENT] !! Service timeout"が発生しないことから、"[SC-CLIENT] !! Service timeout"が原因でなく、何れかのドライバのIRP_MN_SURPRISE_REMOVAL処理あたりに問題があるものと推測しています。
    尚補足ですが、最初の投稿に「市販のUSBメモリでも必ず発生」と記載しましたが、その後確認したところでは複数のパソコン環境で他社製Smart Card Reader(VistaでのWHQL取得済)、USBマウス等も必ず発生することを確認しています(むしろ正常動作を確認したデバイスは未だない)。

    まだ解決には至っておりませんが、多々御教示頂いたニコチャン大王様には大変感謝しております。


    <WinDbgで出力したPNPFILTERのログ>

    Start: Surprise Remove, TUID=
    Running Surprise Removal Test on node with hwid:
    USB\VID_0000&PID_0000&REV_0100
    PNPFILTR: Received IOCTL_QUERY_DEVICE_COUNT
    PNPFILTR: Received IOCTL_QUERY_HARDWARE_ID_SIZE for PDO 0x827C1030
    PNPFILTR: Received IOCTL_QUERY_HARDWARE_ID for PDO 0x827C1030
    PNPFILTR: Received IOCTL_SURPRISE_REMOVE_DEVICE for PDO 0x827C1030
    PNPFILTR: Calling IoInvalidateDeviceState to start rebalance on PDO 827C1030
    PNPFILTR: Received IRP_MN_QUERY_PNP_DEVICE_STATE for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Completing IRP_MN_QUERY_PNP_DEVICE_STATE for PDO 0x827C1030 with status 0x00000000 and information 0x00000014
    PNPFILTR: Received IRP_MN_QUERY_STOP_DEVICE for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterQueryStop returning 0x00000004 for stack with PDO 0x827C1030
    PNPFILTR: Received IRP_MN_QUERY_RESOURCE_REQUIREMENTS  which I am simply passing down
    PNPFILTR: Received IRP_MN_FILTER_RESOURCE_REQUIREMENT for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterFilterResourceRequirement returning 0x00000004 for stack with PDO 0x827C1030
    PNPFILTR: Received IRP_MN_CANCEL_STOP_DEVICE for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterCancelStop Setting TestCompleteEvent for stack with PDO 0x827C1030
    PNPFILTR: FilterCancelStop returning 0x00000004 for stack with PDO 0x827C1030
    HAL: Current Time:  2010-07-09, 09:05:51:500 1cb1f45edeb0cc0
    HAL: Wake Alarm Set: 2010-07-09, 09:04:23:062 1cb1f45b9347b60
    HAL: Delta   :  ffffffffcb496ea0
    HAL: Wakeup Time Expired in SetAlarm. Alarm not set.
    HAL: Current Time:  2010-07-09, 09:05:51:500 1cb1f45edeb0cc0
    HAL: Wake Alarm Set: 2010-07-09, 09:05:23:062 1cb1f45dcf7c160
    HAL: Delta   :  ffffffffef0cb4a0
    HAL: Wakeup Time Expired in SetAlarm. Alarm not set.
    HAL: Current Time:  2010-07-09, 09:05:51:500 1cb1f45edeb0cc0
    HAL: Wake Alarm Set: 2010-07-09, 09:06:23:062 1cb1f4600bb0760
    Inventoried: 104397 pages to hibernate
        42045 ranges of consecutive physical pages
        3325 pages not required to hibernate
    Hibernate occurred
    Waiting to reconnect...
    Connected to Windows 7 7600 x86 compatible target at (Fri Jul  9 09:08:54.643 2010 (UTC + 9:00)), ptr64 FALSE
    Kernel Debugger connection established.
    Symbol search path is: C:\Windows\Symbols
    Executable search path is:
    *** ERROR: Module load completed but symbols could not be loaded for ntkrpamp.exe
    Windows 7 Kernel Version 7600 MP (1 procs) Free x86 compatible
    Product: WinNt, suite: TerminalServer SingleUserTS Personal
    Built by: 7600.16385.x86fre.win7_rtm.090713-1255
    Machine Name:
    Kernel base = 0x8300a000 PsLoadedModuleList = 0x83152810
    Debug session time: Fri Jul  9 09:06:43.500 2010 (UTC + 9:00)
    System Uptime: 0 days 0:06:31.437
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Recieved Query Result
    PNPFILTR: Waiting for test to be completed - will wait for 3 minutes
    PNPFILTR: Query Result Wait Satisfied...  5
    PNPFILTR: Number of IRPs Stored... 5
    PNPFILTR: Query Result - Releasing the remove
    PNPFILTR: Query Result -Result Stored Event set
    Relevant Sequence of Irps:
    IRP_MN_QUERY_PNP_DEVICE_STATE
    IRP_MN_QUERY_STOP_DEVICE
    IRP_MN_QUERY_RESOURCE_REQUIREMENTS
    IRP_MN_FILTER_RESOURCE_REQUIREMENTS
    IRP_MN_CANCEL_STOP_DEVICE
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_REMOVE_DEVICE for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterQueryRemove returning 0x00000004 for stack with PDO 0x827C1030
    PNPFILTR: Received IRP_MN_REMOVE_DEVICE for stack with PDO 0x827C1030
    PNPFILTR: List has 0 entries
    PNPFILTR: Processed 0 IRPs
    PNPFILTR: Deleting the global control object
    PNPFILTR: FilterRemove returning 0x00000004 for stack with PDO 0x827C1030
    *******************************************************************************
    *
    * This is the string you add to your checkin description
    * Driver Verifier: Enabled for MyDriver.sys on Build 7600 7bGhhThGwnkB4Xs3lcnkiH
    *
    *******************************************************************************
    PNPFILTR: Events being initialized
    PNPFILTR: Received IRP_MN_QUERY_LEGACY_BUS_INFORMATION which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_RESOURCE_REQUIREMENTS  which I am simply passing down
    PNPFILTR: Received IRP_MN_FILTER_RESOURCE_REQUIREMENT for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterFilterResourceRequirement returning 0x00000004 for stack with PDO 0x827C1030
    PNPFILTR: Received IRP_MN_START_DEVICE for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Time taken for IRP_MN_START_DEVICE to get processed for the PDO 827C1030 is 203 miliseconds
    PNPFILTR: Completing Start request with status == 0x00000002 PDO = 0x827C1030
    PNPFILTR: Received IRP_MN_QUERY_INTERFACE  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_PNP_DEVICE_STATE for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: Completing IRP_MN_QUERY_PNP_DEVICE_STATE for PDO 0x827C1030 with status 0x00000000 and information 0x00000010
    PNPFILTR: List has 0 entries
    PNPFILTR: Processed 0 IRPs
    PNPFILTR: List has 0 entries
    PNPFILTR: Processed 0 IRPs
    PNPFILTR: Passing down unhandled PNP IRP - minor function = 0xff
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_TEXT  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_ID which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_INTERFACE  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_INTERFACE  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_CAPABILITIES  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_RESOURCE_REQUIREMENTS  which I am simply passing down
    PNPFILTR: Received IRP_MN_FILTER_RESOURCE_REQUIREMENT for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterFilterResourceRequirement returning 0x00000004 for stack with PDO 0x827C1030
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_DEVICE_RELATIONS  which I am simply passing down
    PNPFILTR: Received IRP_MN_QUERY_REMOVE_DEVICE for stack with PDO 0x827C1030
    PNPFILTR: FilterCompletionRoutine Completed, event set.
    PNPFILTR: FilterQueryRemove returning 0x00000004 for stack with PDO 0x827C1030
    PNPFILTR: Received IRP_MN_REMOVE_DEVICE for stack with PDO 0x827C1030
    PNPFILTR: List has 0 entries
    PNPFILTR: Processed 0 IRPs
    PNPFILTR: Deleting the global control object
    PNPFILTR: FilterRemove returning 0x00000004 for stack with PDO 0x827C1030
    *******************************************************************************
    *
    * This is the string you add to your checkin description
    * Driver Verifier: Enabled for MyDriver.sys on Build 7600 7bGhhThGwnkB4Xs3lcnkiH
    *
    *******************************************************************************
    Filter driver removed - Test finished

     

     

    2010年7月9日 1:13