Идентичные ожидающие IRP

Question

Я принудительно выполнил полный дамп ядра для приложения, которое, кажется, ожидает в заблокированном потоке в драйвере ядра. Я полагаю, что идентифицировал нить-нарушитель, так как у нее 1920031 тиков (0:08:19:12.675), что примерно соответствует времени ожидания приложения. Поток также потратил всего 0,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) 

1. Как один поток может иметь два почти идентичных ожидающих IRP для одного и того же устройства и файла?
2. Как объект файла может быть открыт в двух IRP, но иметь только один открытый дескриптор?

Спасибо!