Debugging 相同的待处理IRP

我强制一个应用程序完成内核转储，该应用程序似乎在内核驱动程序中等待一个死锁线程。我相信我已经识别了有问题的线程，因为它有1920031个滴答声（0:08:19:12.675），这大概就是应用程序等待的时间。线程在用户和内核时间上也只花费了.015毫秒：

        THREAD 85e18cf8  Cid 0988.1160  Teb: 7ffa8000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Non-Alertable
        85dac938  NotificationEvent
        85da5350  SynchronizationEvent
    IRP List:
        b7d67818: (0006,0094) Flags: 00060000  Mdl: 00000000
        85d95c70: (0006,0094) Flags: 00060000  Mdl: 00000000
    Not impersonating
    DeviceMap                 8c808980
    Owning Process            ba224730       Image:         MyApplication.exe
    Attached Process          N/A            Image:         N/A
    Wait Start TickCount      2447201        Ticks: 1920031 (0:08:19:12.675)
    Context Switch Count      326            IdealProcessor: 1             
    UserTime                  00:00:00.015
    KernelTime                00:00:00.015
    Win32 Start Address 0x6b19f28e
    Stack Init c5463fd0 Current c5463748 Base c5464000 Limit c5461000 Call 0
    Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
    Kernel stack not resident.
    ChildEBP RetAddr  
    c5463760 830ce8d5 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
    c5463798 830cd733 nt!KiSwapThread+0x266
    c54637c0 830c94e4 nt!KiCommitThreadWait+0x1df
    c546393c 8327d1db nt!KeWaitForMultipleObjects+0x535
    c5463bc8 8327cf48 nt!ObpWaitForMultipleObjects+0x262
    c5463d18 8308da16 nt!NtWaitForMultipleObjects+0xcd
    c5463d18 777870d4 nt!KiSystemServicePostCall (FPO: [0,3] TrapFrame @ c5463d34)
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    012af6f8 00000000 0x777870d4

它对同一设备和同一文件有两个待处理的IRP

2: kd> !irp 85d95c70
Irp is active with 1 stacks 1 is current (= 0x85d95ce0)
 No Mdl: No System Buffer: Thread 85e18cf8:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
>[IRP_MJ_DEVICE_CONTROL(e), N/A(0)]
            0  1 8886d6b8 a1b90a48 00000000-00000000    pending
           \Driver\nsiproxy
            Args: 00000014 00000014 0012003f 012af5b0

2: kd> !object a1b90a48
Object: a1b90a48  Type: (85b36518) File
    ObjectHeader: a1b90a30 (new version)
    HandleCount: 1  PointerCount: 10

!！该文件上的findhandle确认MyApplication.exe有权访问该文件

600: Entry ba707c00 Granted Access 100080

文件未锁定：

2: kd> dt -r nt!_OBJECT_HEADER a1b90a30
   +0x000 PointerCount     : 0n10
   +0x004 HandleCount      : 0n1
   +0x004 NextToFree       : 0x00000001 Void
   +0x008 Lock             : _EX_PUSH_LOCK
      +0x000 Locked           : 0y0
      +0x000 Waiting          : 0y0
  +0x000 Waking           : 0y0
  +0x000 MultipleShared   : 0y0
  +0x000 Shared           : 0y0000000000000000000000000000 (0)
  +0x000 Value            : 0
  +0x000 Ptr              : (null) 

一个线程如何能对同一设备和文件拥有两个几乎相同的挂起IRP

文件对象如何在两个IRP中打开，但只有一个打开句柄

---

谢谢

我假设多个异步I/O请求将导致来自同一线程和/或句柄的多个挂起IRP，尽管这可能不是唯一可能的原因。（但你是在调试应用程序还是驱动程序？我不清楚。）不幸的是，我说不出来。两者都可能是罪魁祸首，但由于某些情况，我只能对其进行事后调试。应用程序本身正在等待一些东西，这可能是问题所在。但它等待的可能是大量内核驱动程序——这也可能是问题所在。

！stacks 2 nsiproxy

将显示具有属于nsiproxy驱动程序的1个或多个帧的所有堆栈。它可能会显示驱动程序正在进行的阻塞调用。这不会返回线程。