what is wrong with my code that checks the current process name in WDDM DDI call

Dear experts,

I have these code written in WDDM DDI call DxgkddiBuildpagingbuffer, the purpose is obvious that i want to know what process is calling this DxgkddiBuildpagingbuffer

PAGED_CODE();
PEPROCESS psyspro = PsGetCurrentProcess();
char* buffer = NULL;
buffer = (char*)ExAllocatePoolWithTag(PagedPool, 16, 'xzj');
memset(buffer, 0, 16);
memcpy_s(buffer, 15, (((char*)psyspro) + 0x450), 15);
LARGE_INTEGER systime;
systime.QuadPart = 0;
KeQuerySystemTime(&systime);
DbgPrint("[%lld] BuildPagingBuffer ====> %s\n", systime.QuadPart, buffer);
    ExFreePoolWithTag(buffer, 'xzj');

Then i build the driver, and .kdfiles it , and put a breakpoint on the last line of code to check current call stack with k

[132127558731484617] BuildPagingBuffer ====> 3DMarkTimeSpy.
Breakpoint 0 hit
atikmdag!Dispatch_BuildPagingBuffer+0x123:
fffff806`4db7b8b3 ba6a7a7800 mov edx,787A6Ah
1: kd> k

Child-SP RetAddr Call Site




03 fffffc8ff846e2d0 fffff80647604b19 dxgkrnl!ADAPTER_RENDER::DdiBuildPagingBuffer+0xe3 [onecoreuap\windows\core\dxkernel\dxgkrnl\core\adapterddi.cxx @ 1744]
04 fffffc8ff846e380 fffff8064d3f55c7 dxgkrnl!ADAPTER_RENDER_DdiBuildPagingBuffer+0x9 [onecoreuap\windows\core\dxkernel\dxgkrnl\core\corethnk.cxx @ 1550]
05 fffffc8ff846e3b0 fffff8064d45f389 dxgmms2!ADAPTER_RENDER::DdiBuildPagingBuffer+0x17 [onecoreuap\windows\core\dxkernel\dxgkrnl\inc\dxgmms.hxx @ 236]
06 fffffc8ff846e3e0 fffff8064d45e26b dxgmms2!VIDMM_GLOBAL::FlushGpuVaTlb+0x1a9 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 20399]
07 (Inline Function) ---------------- dxgmms2!CVirtualAddressAllocator::FlushGpuVaTlb+0x8c [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\inc\vidmmva.hxx @ 701] 08 fffffc8ff846e620 fffff8064d467f62 dxgmms2!CVirtualAddressAllocator::UncommitVirtualAddressRange+0x1ab [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 3156] 09 (Inline Function) ---------------- dxgmms2!VIDMM_GLOBAL::FlushScratchGpuVaRanges+0x69e [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 15515]
0a fffffc8ff846e750 fffff8064d465f08 dxgmms2!VIDMM_GLOBAL::FlushPagingBufferInternal+0x732 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 15619]
0b fffffc8ff846e9a0 fffff8064d46145e dxgmms2!VIDMM_GLOBAL::xWaitForAllPagingEngines+0x88 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 16104]
0c (Inline Function) ---------------- dxgmms2!VIDMM_GLOBAL::WaitForAllPagingEngines+0x3d [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 16025] 0d (Inline Function) ---------------- dxgmms2!VIDMM_GLOBAL::WaitForAllPagingOperations+0x3d [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 16043]
0e fffffc8ff846e9f0 fffff8064d4501bb dxgmms2!VIDMM_GLOBAL::CloseOneAllocation+0x11e [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 4869]
0f fffffc8ff846eb40 fffff8064d472911 dxgmms2!VIDMM_PAGE_TABLE::DestroyPageTable+0x7f [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 4225]
10 fffffc8ff846ebc0 fffff8064d472882 dxgmms2!VIDMM_PAGE_DIRECTORY::DestroyPdePageTableData+0x49 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 4906]
11 fffffc8ff846ebf0 fffff8064d45f17a dxgmms2!VIDMM_PAGE_DIRECTORY::HandleFullPageTableCoverage+0x96 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 5012]
12 fffffc8ff846ec50 fffff8064d489b4e dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0xeca [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 5537]
13 fffffc8ff846edf0 fffff8064d489b4e dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x2b89e [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 5809]
14 fffffc8ff846ef90 fffff8064d45e1cc dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x2b89e [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 5809]
15 fffffc8ff846f130 fffff8064d45c2e5 dxgmms2!CVirtualAddressAllocator::UncommitVirtualAddressRange+0x10c [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 3134]
16 fffffc8ff846f260 fffff8064d44abcf dxgmms2!VIDMM_GLOBAL::MakeOneVirtualAddressRangeNotResident+0x16d [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 21147]
17 fffffc8ff846f6f0 fffff8064d44aaae dxgmms2!VIDMM_GLOBAL::MakeVirtualAddressRangeNotResident+0x7f [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 21034]
18 fffffc8ff846f730 fffff8064d466c53 dxgmms2!VIDMM_MEMORY_SEGMENT::EvictResource+0x23e [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmlmseg.cxx @ 2722]
19 fffffc8ff846f780 fffff8064d475682 dxgmms2!VIDMM_GLOBAL::ProcessDeferredCommand+0x493 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 10706]
1a (Inline Function) ---------------- dxgmms2!VIDMM_WORKER_THREAD::ProcessPendingTerminations+0x10ca [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmworker.cxx @ 1536] 1b fffffc8ff846f9f0 fffff8064d47eb19 dxgmms2!VIDMM_WORKER_THREAD::Run+0x1492 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmworker.cxx @ 2510] 1c fffffc8ff846fbe0 fffff80643b30925 dxgmms2!VidMmWorkerThreadProc+0x9 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmworker.cxx @ 51] 1d fffffc8ff846fc10 fffff80643bc3d5a nt!PspSystemThreadStartup+0x55 [minkernel\ntos\ps\psexec.c @ 9310] 1e fffffc8ff846fc60 00000000`00000000 nt!KiStartSystemThread+0x2a [minkernel\ntos\ke\amd64\threadbg.asm @ 83]

so from the call stack it seems like system process is calling DxgkddiBuildpagingbuffer, whereas my code show that current process is 3DMarkTimeSpy other than system process.

i guess k command is correct to show what current process is, or not?
what is wrong with my code?
I am sure ImageFileName is +0x450 offset from EPROCESS as dt nt!_eprocess shows out.

Thanks in advance!

what is wrong with my code?

Everything…

FYI, all strings in NT kernel are in the form of UNICODE_STRING structures ( for the purpose of this discussion let’s overlook the fact that you are directly accessing undocumented fields of the structure - let’s say you expect it to work because know what you re doings)…

Anton Bassov

After analysis and the resulting understanding of the subject, such code might not be necessary at all. Let us try:

  • This DDI is called by dxgkrnl.sys on its own behalf.
  • No WDDM User Mode Driver involved.
  • What call context would dxgkrnl.sys probably use?
  • System Threads? Very likely…
  • Even more likely when call stack above shows dxgmms2!VidMmWorkerThreadProc…

Thus, the expected process is always “System” (PID 4) which is the System Process and home of all System Threads.

Marcel Ruedinger
datronicsoft