does windbg k command show the user-mode call stack when kernel debugging

tony_zhu

I have code like this and build into driver run it

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);
if (strncmp(buffer, "System", 6) != 0)
{
    ASSERT(FALSE);
}
ExFreePoolWithTag(buffer, 'xzj');

and i have place a break point on the line of ASSERT(FALSE);

So that when the current process running this code isn't system, stop

However when i get this log, then breakpoint hit.
[132130922083347725] BuildPagingBuffer ====> LogonUI.exe

then i use k command in windbg , i get this
03 ffffef8d3c2bff90 fffff8051d434b19 dxgkrnl!ADAPTER_RENDER::DdiBuildPagingBuffer+0xe3 [onecoreuap\windows\core\dxkernel\dxgkrnl\core\adapterddi.cxx @ 1744]
04 ffffef8d3c2c0040 fffff8051e5955c7 dxgkrnl!ADAPTER_RENDER_DdiBuildPagingBuffer+0x9 [onecoreuap\windows\core\dxkernel\dxgkrnl\core\corethnk.cxx @ 1550]
05 ffffef8d3c2c0070 fffff8051e5ff968 dxgmms2!ADAPTER_RENDER::DdiBuildPagingBuffer+0x17 [onecoreuap\windows\core\dxkernel\dxgkrnl\inc\dxgmms.hxx @ 236]
06 ffffef8d3c2c00a0 fffff8051e60008b dxgmms2!VIDMM_GLOBAL::UpdatePageTable+0x318 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 20311]
07 (Inline Function) ---------------- dxgmms2!VIDMM_PAGE_TABLE::UpdatePageTable+0x113 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 3782] 08 ffffef8d3c2c0330 fffff8051e5fec78 dxgmms2!VIDMM_PAGE_TABLE::CommitVirtualAddressRange+0x29b [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 4509] 09 ffffef8d3c2c0410 fffff8051e629b4e dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x9c8 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 5762] 0a ffffef8d3c2c05b0 fffff8051e629b4e dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x2b89e [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 5809] 0b ffffef8d3c2c0750 fffff8051e5fde53 dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x2b89e [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 5809] 0c ffffef8d3c2c08f0 fffff8051e5ec120 dxgmms2!CVirtualAddressAllocator::CommitVirtualAddressRange+0x2e3 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 2853] 0d ffffef8d3c2c0a60 fffff8051e610de1 dxgmms2!VIDMM_PAGING_PROCESS::MapScratchAreaVaRange+0x14c [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmva.cxx @ 7541] 0e ffffef8d3c2c0ae0 fffff8051e610bff dxgmms2!VIDMM_GLOBAL::MemoryTransferUsingGpuVaWorker+0x1b9 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 14607] 0f ffffef8d3c2c0d70 fffff8051e610a4c dxgmms2!VIDMM_GLOBAL::MemoryTransferInternal+0x127 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 14219] 10 ffffef8d3c2c0f70 fffff8051e6106ea dxgmms2!VIDMM_GLOBAL::MemoryTransfer+0x88 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 13944] 11 ffffef8d3c2c0fe0 fffff80519bda15c dxgmms2!VIDMM_MEMORY_SEGMENT::RotateFrameBufferCopyCallback+0x9a [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmlmseg.cxx @ 3226] 12 ffffef8d3c2c1050 fffff8051e612c1c nt!MmRotatePhysicalView+0x13348c [minkernel\ntos\mm\vidsup.c @ 657] 13 (Inline Function) ---------------- dxgmms2!VidMmiDebugRotate+0x2b [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmrecycleheap.cxx @ 145]
14 ffffef8d3c2c12f0 fffff8051e612add dxgmms2!VIDMM_RECYCLE_MULTIRANGE::Rotate+0xfc [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmrecycleheap.cxx @ 3655]
15 ffffef8d3c2c13b0 fffff8051e61367f dxgmms2!VIDMM_RECYCLE_HEAP_MGR::Rotate+0x8d [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmrecycleheap.cxx @ 10331]
16 ffffef8d3c2c1440 fffff8051e5eb4c6 dxgmms2!VIDMM_GLOBAL::Rotate+0x7b [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 29537]
17 ffffef8d3c2c14b0 fffff8051e5eafd2 dxgmms2!VIDMM_MEMORY_SEGMENT::TransferToSegment+0x316 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmlmseg.cxx @ 643]
18 ffffef8d3c2c1620 fffff8051e5fcadf dxgmms2!VIDMM_MEMORY_SEGMENT::CommitResource+0x62 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmlmseg.cxx @ 1240]
19 ffffef8d3c2c1670 fffff8051e607022 dxgmms2!VIDMM_GLOBAL::PageInOneAllocation+0x1ef [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 17087]
1a ffffef8d3c2c1780 fffff8051e614e0b dxgmms2!VIDMM_GLOBAL::ProcessDeferredCommand+0x862 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmglobal.cxx @ 10865]
1b (Inline Function) ---------------- dxgmms2!VIDMM_WORKER_THREAD::SubmitPacket+0xbf [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmworker.cxx @ 209] 1c ffffef8d3c2c19f0 fffff8051e61eb19 dxgmms2!VIDMM_WORKER_THREAD::Run+0xc1b [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmworker.cxx @ 1915] 1d ffffef8d3c2c1be0 fffff80519530925 dxgmms2!VidMmWorkerThreadProc+0x9 [onecoreuap\windows\core\dxkernel\dxgkrnl\dxgmms2\vidmm\mmworker.cxx @ 51] 1e ffffef8d3c2c1c10 fffff805195c3d5a nt!PspSystemThreadStartup+0x55 [minkernel\ntos\ps\psexec.c @ 9310] 1f ffffef8d3c2c1c60 00000000`00000000 nt!KiStartSystemThread+0x2a [minkernel\ntos\ke\amd64\threadbg.asm @ 83]

so as you can see, call stack is from nt!KiStartSystemTread, not LogonUI.exe related call stack.

Can someone explain to me why?

Thanks!

entelferidun

I am not sure if it is right thing to answer an old question, but I will answer it anyway. strncmp returns 0 if the contents of both strings are equal

Tim_Roberts

Amazing. Not only did you resurrect a dead thread, which is against the rules, but you provided a totally unhelpful answer. Not a good start.

entelferidun

OMG! I see my mistakes now. I thought a little mistake had gone unnoticed all this time. Sorry for that.