Identical pending IRPs

Question

I forced a complete kernel dump for an application that appears to be waiting on a deadlocked thread in a kernel driver. I believe I have identified the offending thread as it has 1920031 ticks (0:08:19:12.675) which is roughly how long the application has been waiting. The thread has also only spent .015 milliseconds in user and kernel time:

        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

It has two pending IRPs to the same device and same file.

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 on that file confirms MyApplication.exe has access to it.

600: Entry ba707c00 Granted Access 100080

The file is not locked:

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)

How can one thread have two nearly-identical pending IRPs to the same device and file?
How can the file object be open in two IRPs but only have one open handle?

Thanks!

I would assume that multiple asynchronous I/O requests would result in multiple pending IRPs from the same thread and/or handle, although that might not be the only possible cause. (But are you trying to debug the application or the driver? It isn't clear to me.) — Harry Johnston, Apr 01 '16 at 23:18
Unfortunately, I can't tell. Either could be the culprit but due to certain circumstances I can only get post-mortem debugging on it. The application itself is waiting on something - which could be the problem. But what it's waiting on could be a number of kernel drivers - which could also be the problem. — mitchellJ, Apr 02 '16 at 04:40
`!stacks 2 nsiproxy` will show you all the stacks that have 1 or more frames belonging to the nsiproxy driver. It may show you what blocking call that driver is making. — Marc Sherman, Apr 04 '16 at 17:31

Identical pending IRPs

0 Answers0