Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


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

tony_zhutony_zhu Member Posts: 42

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!

Comments

  • entelferidunentelferidun Member Posts: 2

    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_RobertsTim_Roberts Member - All Emails Posts: 14,658

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • entelferidunentelferidun Member Posts: 2
    OMG! I see my mistakes now. I thought a little mistake had gone unnoticed all this time. Sorry for that.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 16-20 October 2023 Live, Online
Developing Minifilters 13-17 November 2023 Live, Online
Internals & Software Drivers 4-8 Dec 2023 Live, Online
Writing WDF Drivers 10-14 July 2023 Live, Online