ZwQueryVirtualMemory does not return, called from PLOAD_IMAGE_NOTIFY_ROUTINE

NTFSD
1

I am calling ZwQueryVirtualMemory from PLOAD_IMAGE_NOTIFY_ROUTINE callback. For some image load callback, this call leads to system hang.
Does anyone help me?

Call stack of blocked call:
nt!KiSwapContext+0x7a
nt!KiCommitThreadWait+0x1d2
nt!KeWaitForSingleObject+0x1a3
nt!ExfAcquirePushLockShared+0x138
nt!NtQueryVirtualMemory+0x67a
nt!KiSystemServiceCopyEnd+0x13
nt!KiServiceLinkage
sensor!CheckMemory+0x184
sensor!ImageLoadCallback+0xb5
nt!PsCallImageNotifyRoutines+0xdc
nt!MiMapViewOfImageSection+0x9b2
nt!MiMapViewOfSection+0x367
nt!NtMapViewOfSection+0x2bd
nt!KiSystemServiceCopyEnd+0x13
nt!KiServiceLinkage
klif+0x8279f
klif+0x6a3cd
klif+0xed1ba
klflt!PstUnregisterFilter+0x207
klflt!PstUnregisterFilter+0x295
klflt!PstUnregisterProcess+0x116d
nt! ?? ::NNGAKEGL::`string’+0x24ddd
nt!NtCreateUserProcess+0x94f
nt!KiSystemServiceCopyEnd+0x13
0x76e2a35a

2

Hello,

the documentation for the PLOAD_IMAGE_NOTIFY_ROUTINE states

In Windows 7, Windows Server 2008 R2, and earlier versions of Windows, the operating system holds an internal system lock during calls to load-image notify routines for images loaded in user process address space (user space). To avoid deadlocks, load-image notify routines must not call system routines that map, allocate, query, free, or perform other operations on user-space virtual memory.

Looking at the stack trace, I see that the system waits for a pushlock. I expect that pushlock has been acquired previously somewhere in NtMapViewOfSection. And since pushlocks cannot be acquired recursively (unlike executive resources), you get a deadlock.

You need to avoid any actions regarding process address space during the load image notification.