{"id":43613,"date":"2014-11-14T07:00:00","date_gmt":"2014-11-14T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2014\/11\/14\/how-to-view-the-stack-of-a-user-mode-thread-when-its-kernel-stack-has-been-paged-out\/"},"modified":"2014-11-14T07:00:00","modified_gmt":"2014-11-14T07:00:00","slug":"how-to-view-the-stack-of-a-user-mode-thread-when-its-kernel-stack-has-been-paged-out","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20141114-00\/?p=43613","title":{"rendered":"How to view the stack of a user-mode thread when its kernel stack has been paged out"},"content":{"rendered":"

\nSuppose you have a machine that has crashed,\nand your investigation shows that the reason is that there\nis a critical section that everybody is waiting for.\nWhile waiting for that critical section, work piles up,\nand eventually the machine keels over.\nSuppose further that this crash is given to you in the form\nof a kernel debugger.\n<\/p>\n

\nIn case it wasn’t obvious, by “you”\n\nI mean “me”<\/a>.\n<\/p>\n

\nOkay, so the critical section that is the cause of the logjam\nis this one:\n<\/p>\n

\n1: kd> !cs CONTOSO!g_csDataLock\n-----------------------------------------\nCritical section   = 0x00007ff7f0ed2f68 (CONTOSO!g_csDataLock+0x0)\nDebugInfo          = 0x0000000022f2efd0\nLOCKED\nLockCount          = 0x5D\nWaiterWoken        = No\nOwningThread       = 0x0000000000004228\nRecursionCount     = 0x1\nLockSemaphore      = 0x17A0\nSpinCount          = 0x00000000020007cb\n<\/pre>\n
\n“Great,” you say.\n“I just need to look at thread 0x4228 to see why it is stuck.\n<\/p>\n
\n1: kd> !process -1 4\nPROCESS ffffe000047ae900\n    SessionId: 1  Cid: 0604    Peb: 7ff74ecfa000  ParentCid: 05cc\n    DirBase: 0eb07000  ObjectTable: ffffc000014c5680  HandleCount: 7003.\n    Image: contoso.exe\n        ...\n        THREAD ffffe0000c136080  Cid 0604.4228  Teb: 00007ff74e94c000 Win32Thread: fffff90144edea60 WAIT\n        ...\n<\/pre>\n
\nWoo-hoo, there’s the thread.\nNow I just need to switch to its context to see what it is stuck on.\n<\/p>\n
\n1: kd> .thread ffffe0000c136080\nCan't retrieve thread context<\/a>, Win32 error 0n30\n<\/pre>\n
\nOkay, that didn’t work out too well.\nNow what?\n<\/p>\n
\nEven though the kernel stack is paged out,\nthe user-mode stack may still be available.\n<\/p>\n
\n1: kd> !thread ffffe0000c136080\nTHREAD ffffe0000c136080  Cid 0604.4228  Teb: 00007ff74e94c000<\/u>\n       Win32Thread: fffff90144edea60 WAIT: (UserRequest) UserMode Non-Alertable\n    ffffe000077a7830  NotificationEvent\nNot impersonating\nDeviceMap                 ffffc00000e89c80\nOwning Process            ffffe000047ae900       Image:         contoso.exe\nAttached Process          N\/A            Image:         N\/A\nWait Start TickCount      12735890       Ticks: 328715 (0:01:25:36.171)\nContext Switch Count      75             IdealProcessor: 2\nUserTime                  00:00:00.000\nKernelTime                00:00:00.031\nKernel stack not resident.\n<\/pre>\n
\nThe limits of the user-mode stack are kept in the Teb.\n<\/p>\n
\n2: kd> !teb 00007ff74e94c000\nTEB at 00007ff74e94c000\n    ExceptionList:        0000000000000000\n    StackBase:            00000001027d0000<\/u>\n    StackLimit:           00000001027c2000<\/u>\n    SubSystemTib:         0000000000000000\n    FiberData:            0000000000001e00\n    ArbitraryUserPointer: 0000000000000000\n    Self:                 00007ff74e94c000\n    EnvironmentPointer:   0000000000000000\n    ClientId:             0000000000000604 . 0000000000004228\n    RpcHandle:            0000000000000000\n    Tls Storage:          000000010132dfc0\n    PEB Address:          00007ff74ecfa000\n    LastErrorValue:       1008\n    LastStatusValue:      c0000034\n    Count Owned Locks:    2\n    HardErrorMode:        0\n<\/pre>\n
\nWe now use the trick we learned some time ago\nwhere we\n\ngrovel the stack of a thread without knowing where its stack pointer is<\/a>.\n<\/p>\n
\nIn this case,\nthe groveling is made easier because we already know that\neverybody is waiting on the data lock.\nThe data lock is taken in only two functions,\nso it’s a matter ot looking for\nany occurrences of one of those two functions.\nAnd here it is:\nData­Wrapper::Verify­Data<\/code>.\n<\/p>\n
\n00000001`027cef88  00007ffe`f1bbac9a NTDLL!NtWaitForSingleObject+0xa\n00000001`027cef90  00000000`00006ac8\n00000001`027cef98  00007ffe`ef1bd085 KERNELBASE!WaitForSingleObjectEx+0xa5\n00000001`027cefa0  00000000`00006ac8\n00000001`027cefa8  00000000`00000000\n00000001`027cefb0  00000000`026d0000\n00000001`027cefb8  00000000`00000000\n00000001`027cefc0  00000001`01739ee0\n00000001`027cefc8  00000000`00000001\n00000001`027cefd0  00000000`00000048\n00000001`027cefd8  00000001`00000001\n00000001`027cefe0  00000000`00000000\n00000001`027cefe8  00000000`00000000\n00000001`027ceff0  00000000`00000000\n00000001`027ceff8  00000000`00000000\n00000001`027cf000  00000000`00000000\n00000001`027cf008  00000000`00000000\n00000001`027cf010  00000000`00000000\n00000001`027cf018  00007ff7`eefe6540 FABRIKAM!Lock::IsInitialized+0xfc\n00000001`027cf020  00000000`00000000\n00000001`027cf028  00000000`3b803fa0\n00000001`027cf030  00000000`00006ac8\n00000001`027cf038  00007ff7`eeff3c43 FABRIKAM!AccessRequest::WaitTimeout+0x87\n00000001`027cf040  00000000`ffffffff\n00000001`027cf048  10f513ec`6a161fb8\n00000001`027cf050  00000000`00000000\n00000001`027cf058  00000000`00006ac8\n00000001`027cf060  00000000`3b803fb8\n00000001`027cf068  00007ff7`eeff3cc0 FABRIKAM!AccessRequest::Wait+0x18\n00000001`027cf070  00000000`8007000e\n00000001`027cf078  00000000`fd416ff0\n00000001`027cf080  4fe80c4a`51236583\n00000001`027cf088  00000000`3b803fb8\n00000001`027cf090  00000000`ffffffff\n00000001`027cf098  00000000`00000000\n00000001`027cf0a0  00000000`3b803fa0\n00000001`027cf0a8  00007ff7`da8375b7 FABRIKAM!DataAccess::RequestAccess+0x93\n00000001`027cf0b0  00000000`3b803fa0\n00000001`027cf0b8  00000000`3b803fb8\n00000001`027cf0c0  4fe80c4a`51236583\n00000001`027cf0c8  10f513ec`6a161fb8\n00000001`027cf0d0  00000000`00000076\n00000001`027cf0d8  00007ff7`f07a8619 CONTOSO!Widget::SetColor+0x9\n00000001`027cf0e0  000095dc`90897985\n00000001`027cf0e8  00000000`00000110\n00000001`027cf0f0  00000000`00000000\n00000001`027cf0f8  00000000`00000000\n00000001`027cf100  00007ff7`4dd8000c\n00000001`027cf108  00007ff7`f07a85e5 CONTOSO!Widget::UpdateColor+0x39\n00000001`027cf110  00000000`ffc03f90\n00000001`027cf118  00000001`027cf1e8\n00000001`027cf120  00000000`ffc03fc8\n00000001`027cf128  00000000`00000000\n00000001`027cf130  00000000`00000000\n00000001`027cf138  00007ff7`4dd8000c\n00000001`027cf140  00007ff7`da5bc420 FABRIKAM!DataAccess::`vftable'+0x18\n00000001`027cf148  00000000`ffc03f90\n00000001`027cf150  00000001`027cf260\n00000001`027cf158  00007ff7`f0b3459c CONTOSO!DataWrapper::VerifyData+0x428\n00000001`027cf160  00000000`3b803fa0\n00000001`027cf168  00007ff7`f0ed1d30 CONTOSO!g_DataManager\n00000001`027cf170  00000000`fe196f10\n00000001`027cf188  00000000`00000001\n00000001`027cf190  00000000`00000000\n00000001`027cf198  00000001`027cf270\n00000001`027cf1a0  00000001`027cf480\n00000001`027cf1a8  00007ff7`00000001\n00000001`027cf1b0  00000001`027cf220\n00000001`027cf1b8  00000000`00000000\n00000001`027cf1c0  00000000`00000000\n<\/pre>\n
\nI left the red herrings in place just to make things a little\nmore interesting.\n<\/p>\n
\nThe Data­Wrapper::Verify­Data<\/code> method\nenters the critical section and then calls\nData­Access::Request­Access<\/code>\nvia a virtual method call:\n<\/p>\n
\n00007ff7`f0b3458f mov     dword ptr [rsp+28h],eax\n00007ff7`f0b34593 mov     eax,dword ptr [rsi+10h]\n00007ff7`f0b34596 mov     dword ptr [rsp+20h],eax\n00007ff7`f0b3459a call    qword ptr [rdi] ←\n<\/pre>\n
\nLet’s disassemble the start of\nData­Access::Request­Access<\/code>\nto see how it sets up its stack.\nThis will help us interpret the other values in the stack dump.\n<\/p>\n
\n0: kd> u 00007ff7`da8375b7-93\nFABRIKAM!DataAccess::RequestAccess\n;; function prologue\n00007ff7`da837524 mov     rax,rsp\n00007ff7`da837527 mov     qword ptr [rax+8],rbx\n00007ff7`da83752b mov     qword ptr [rax+20h],r9\n00007ff7`da83752f mov     qword ptr [rax+18h],r8\n00007ff7`da837533 mov     qword ptr [rax+10h],rdx\n00007ff7`da837537 push    rbp\n00007ff7`da837538 push    rsi\n00007ff7`da837539 push    rdi\n00007ff7`da83753a push    r12\n00007ff7`da83753c push    r13\n00007ff7`da83753e push    r14\n00007ff7`da837540 push    r15\n00007ff7`da837542 sub     rsp,70h\n;; function body\n00007ff7`da837546 lea     rsi,[rcx+18h]\n00007ff7`da83754a mov     rdi,rcx\n00007ff7`da83754d mov     rbp,r9\n00007ff7`da837550 mov     rcx,rsi\n00007ff7`da837553 call    qword ptr [FABRIKAM!_imp_EnterCriticalSection]\n00007ff7`da837559 xor     r13b,r13b\n00007ff7`da83755c mov     ebx,8007000Eh\n...\n00007ffe`da8375b1 call    FABRIKAM!AccessRequest::Wait\n<\/pre>\n
\nWe can replay the above code in our head and annotate the stack\ntrace accordingly.\nOn entry to the function, the stack pointer is\n00000001`027cf158<\/code> (the return address).\nThe function stashes some registers in the caller-provided spill area\nand it pushes others onto the stack,\nand then it subtracts some space for local variables\nas well as for outbound parameters of functions it intends to call.\n<\/p>\n
\n\/-00000001`027cf0b0  00000000`3b803fa0\n| 00000001`027cf0b8  00000000`3b803fb8\n| 00000001`027cf0c0  4fe80c4a`51236583\n| 00000001`027cf0c8  10f513ec`6a161fb8\n| 00000001`027cf0d0  00000000`00000076\n| 00000001`027cf0d8  00007ff7`f07a8619 CONTOSO!Widget::SetColor+0x9\n| 00000001`027cf0e0  000095dc`90897985\n| 00000001`027cf0e8  00000000`00000110\n| 00000001`027cf0f0  00000000`00000000\n| 00000001`027cf0f8  00000000`00000000\n| 00000001`027cf100  00007ff7`4dd8000c\n| 00000001`027cf108  00007ff7`f07a85e5 CONTOSO!Widget::UpdateColor+0x39\n| 00000001`027cf110  00000000`ffc03f90\n\\-00000001`027cf118  00000001`027cf1e8\n  00000001`027cf120  00000000`ffc03fc8 \/\/ VerifyData's r15<\/font>\n  00000001`027cf128  00000000`00000000 \/\/ VerifyData's r14<\/font>\n  00000001`027cf130  00000000`00000000 \/\/ VerifyData's r13<\/font>\n  00000001`027cf138  00007ff7`4dd8000c \/\/ VerifyData's r12<\/font>\n  00000001`027cf140  00007ff7`da5bc420 FABRIKAM!DataAccess::`vftable'+0x18 \/\/ VerifyData's rdi<\/font>\n  00000001`027cf148  00000000`ffc03f90 \/\/ VerifyData's rsi<\/font>\n  00000001`027cf150  00000001`027cf260 \/\/ VerifyData's rbp<\/font>\n  00000001`027cf158  00007ff7`f0b3459c CONTOSO!DataWrapper::VerifyData+0x428 ← ESP is here<\/font>\n  00000001`027cf160  00000000`3b803fa0 \/\/ VerifyData's rbx<\/font>\n  00000001`027cf168  00007ff7`f0ed1d30 CONTOSO!g_DataManager \/\/ VerifyData's rdx<\/font>\n  00000001`027cf170  00000000`fe196f10 \/\/ VerifyData's r8<\/font>\n  00000001`027cf188  00000000`00000001 \/\/ VerifyData's r9<\/font>\n  00000001`027cf190  00000000`00000000\n  00000001`027cf198  00000001`027cf270\n  00000001`027cf1a0  00000001`027cf480\n  00000001`027cf1a8  00007ff7`00000001\n  00000001`027cf1b0  00000001`027cf220\n  00000001`027cf1b8  00000000`00000000\n  00000001`027cf1c0  00000000`00000000\n<\/pre>\n
\nThe region marked in brackets is the 0x70 bytes of space for local variables\nand outbound parameters.\nNotice that some red herring function pointers are in that space.\nThose are probably variables that haven’t been initialized yet,\nand the memory happened previously to have been used to hold some\nreturn addresses.\n<\/p>\n
\nA reassuring observation is that the rdx<\/code>\ncoming from Verify­Data<\/code> is the address of\nCONTOSO!g_Data­Manager<\/code>.\nThat is the second function parameter (or first, if you aren’t\ncounting the hidden this<\/code>)\nto Request­Access<\/code>.\n<\/p>\n
\nAnother reassuring observation is that\nthat Verify­Data<\/code>‘s\nrdi<\/code> points into the vtable for Data­Access<\/code>,\nsince that matches the code we saw at the call point:\ncall qword ptr [rdi]<\/code>.\n<\/p>\n
\nThe mov rdi, rcx<\/code> instruction in the function body\ntells us that the function\nstashed its this<\/code> pointer in rdi<\/code>.\nThat’s good info to keep track of,\nbecause that will let us look at the Data­Access<\/code> object\nonce we figure out what is in rdi<\/code>.\n<\/p>\n
\nThe next function on the stack is\nAccess­Request::Wait<\/code>.\n<\/p>\n
\nFABRIKAM!AccessRequest::Wait:\n00007ff7`eeff3ca8 sub     rsp,38h\n00007ffe`eeff3cb3 mov     dword ptr [rsp+20h],0FFFFFFFFh\n00007ffe`eeff3cbb call    FABRIKAM!AccessRequest::WaitTimeout\n00007ffe`eeff3cc0 add     rsp,38h\n00007ffe`eeff3cc4 ret\n<\/pre>\n
\nThis function doesn’t bother saving any registers;\nit just reserves space for local variables and outbound parameters.\nFrom inspection, you can see that this is a simple wrapper\nthat passes all its parameters onward to\nWait­Timeout<\/code>,\nwith an INFINITE<\/code> tacked onto the end,\nso this function has no local variables at all.\nEverything is just for outbound parameters.\n<\/p>\n
\nWe can annotate some more entries in our stack trace.\n<\/p>\n
\n00000001`027cf070  00000000`8007000e \/\/ spill space for WaitTimeout<\/font>\n00000001`027cf078  00000000`fd416ff0 \/\/ spill space for WaitTimeout<\/font>\n00000001`027cf080  4fe80c4a`51236583 \/\/ spill space for WaitTimeout<\/font>\n00000001`027cf088  00000000`3b803fb8 \/\/ spill space for WaitTimeout<\/font>\n00000001`027cf090  00000000`ffffffff \/\/ INFINITE parameter<\/font>\n00000001`027cf098  00000000`00000000 \/\/ unused<\/font>\n00000001`027cf0a0  00000000`3b803fa0 \/\/ unused<\/font>\n00000001`027cf0a8  00007ff7`da8375b7 FABRIKAM!DataAccess::RequestAccess+0x93\n<\/pre>\n
\nThe next function on the list is\nAccess­Request::Wait­Timeout<\/code>.\n<\/p>\n
\nFABRIKAM!AccessRequest::WaitTimeout:\n00007ff7`eeff3bbc mov     qword ptr [rsp+8],rbx\n00007ff7`eeff3bc1 mov     qword ptr [rsp+10h],rbp\n00007ff7`eeff3bc6 push    rsi\n00007ff7`eeff3bc7 sub     rsp,20h\n00007ff7`eeff3bcb mov     ebx,edx\n00007ff7`eeff3bcd mov     rsi,rcx\n00007ff7`eeff3bd0 mov     edx,0Bh\n00007ff7`eeff3bd5 mov     rcx,r8\n<\/pre>\n
\nThis function stashes two registers in the parameter spill space,\npushes one onto the stack,\nand reserves another 0x20 bytes for local use (outbound parameters).\n<\/p>\n
\n00000001`027cf040  00000000`ffffffff \/\/ spill space for WaitForSingleObjectEx<\/font>\n00000001`027cf048  10f513ec`6a161fb8 \/\/ spill space for WaitForSingleObjectEx<\/font>\n00000001`027cf050  00000000`00000000 \/\/ spill space for WaitForSingleObjectEx<\/font>\n00000001`027cf058  00000000`00006ac8 \/\/ spill space for WaitForSingleObjectEx<\/font>\n00000001`027cf060  00000000`3b803fb8 \/\/ Wait's rsi<\/font>\n00000001`027cf068  00007ff7`eeff3cc0 FABRIKAM!AccessRequest::Wait+0x18\n00000001`027cf070  00000000`8007000e \/\/ Wait's rbx<\/font>\n00000001`027cf078  00000000`fd416ff0\n00000001`027cf080  4fe80c4a`51236583\n00000001`027cf088  00000000`3b803fb8\n<\/pre>\n
\nNotice that the stashed rbx<\/code> value is 8007000E<\/code>,\nwhich conveniently lines up with the\nmov ebx,8007000Eh<\/code>\ninstruction in\nData­Access::Request­Access<\/code>.\nThat’s a bit reassuring, since it’s another sign that we’re\non the right track.\n<\/p>\n
\nNext up is\nWait­For­Single­Object­Ex<\/code>.\n<\/p>\n
\n0: kd> u 00007ffe`ef1bd085 -a5\nKERNELBASE!WaitForSingleObjectEx\n00007ffe`ef1bcfe0 mov     r11,rsp\n00007ffe`ef1bcfe3 mov     qword ptr [r11+8],rbx\n00007ffe`ef1bcfe7 mov     dword ptr [r11+18h],r8d\n00007ffe`ef1bcfeb push    rsi\n00007ffe`ef1bcfec push    rdi\n00007ffe`ef1bcfed push    r14\n00007ffe`ef1bcfef sub     rsp,80h\n00007ffe`ef1bcff6 mov     ebx,r8d\n<\/pre>\n
\nIncorporating this prologue into our stack annotation yields\n<\/p>\n
\n\/-00000001`027cefa0  00000000`00006ac8 \/\/ spill space for NtWaitForSingleObject<\/font>\n| 00000001`027cefa8  00000000`00000000 \/\/ spill space for NtWaitForSingleObject<\/font>\n| 00000001`027cefb0  00000000`026d0000 \/\/ spill space for NtWaitForSingleObject<\/font>\n| 00000001`027cefb8  00000000`00000000 \/\/ spill space for NtWaitForSingleObject<\/font>\n| 00000001`027cefc0  00000001`01739ee0\n| 00000001`027cefc8  00000000`00000001\n| 00000001`027cefd0  00000000`00000048\n| 00000001`027cefd8  00000001`00000001\n| 00000001`027cefe0  00000000`00000000\n| 00000001`027cefe8  00000000`00000000\n| 00000001`027ceff0  00000000`00000000\n| 00000001`027ceff8  00000000`00000000\n| 00000001`027cf000  00000000`00000000\n| 00000001`027cf008  00000000`00000000\n| 00000001`027cf010  00000000`00000000\n\\-00000001`027cf018  00007ff7`eefe6540 FABRIKAM!Lock::IsInitialized+0xfc\n  00000001`027cf020  00000000`00000000 \/\/ WaitTimeout's r14<\/font>\n  00000001`027cf028  00000000`3b803fa0 \/\/ WaitTimeout's rdi<\/font>\n  00000001`027cf030  00000000`00006ac8 \/\/ WaitTimeout's rsi<\/font>\n  00000001`027cf038  00007ff7`eeff3c43 FABRIKAM!AccessRequest::WaitTimeout+0x87\n  00000001`027cf040  00000000`ffffffff \/\/ WaitTimeout's rbx<\/font>\n  00000001`027cf048  10f513ec`6a161fb8\n  00000001`027cf050  00000000`00000000 \/\/ WaitTimeout's r8<\/font>\n  00000001`027cf058  00000000`00006ac8\n<\/pre>\n
\nOoh, another red herring function pointer got caught in the local\nvariables.\n<\/p>\n
\nPutting everything together results in the following annotated stack,\nwith red herrings removed.\n<\/p>\n
\n00000001`027cef88  00007ffe`f1bbac9a NTDLL!NtWaitForSingleObject+0xa\n00000001`027cef90  00000000`00006ac8\n00000001`027cef98  00007ffe`ef1bd085 KERNELBASE!WaitForSingleObjectEx+0xa5\n00000001`027cefa0  00000000`00006ac8\n00000001`027cefa8  00000000`00000000\n00000001`027cefb0  00000000`026d0000\n00000001`027cefb8  00000000`00000000\n00000001`027cefc0  00000001`01739ee0\n00000001`027cefc8  00000000`00000001\n00000001`027cefd0  00000000`00000048\n00000001`027cefd8  00000001`00000001\n00000001`027cefe0  00000000`00000000\n00000001`027cefe8  00000000`00000000\n00000001`027ceff0  00000000`00000000\n00000001`027ceff8  00000000`00000000\n00000001`027cf000  00000000`00000000\n00000001`027cf008  00000000`00000000\n00000001`027cf010  00000000`00000000\n00000001`027cf018  00007ff7`eefe6540\n00000001`027cf020  00000000`00000000 \/\/ WaitTimeout's r14<\/font>\n00000001`027cf028  00000000`3b803fa0 \/\/ WaitTimeout's rdi<\/font>\n00000001`027cf030  00000000`00006ac8 \/\/ WaitTimeout's rsi<\/font>\n00000001`027cf038  00007ff7`eeff3c43 FABRIKAM!AccessRequest::WaitTimeout+0x87\n00000001`027cf040  00000000`ffffffff \/\/ WaitTimeout's rbx<\/font>\n00000001`027cf048  10f513ec`6a161fb8\n00000001`027cf050  00000000`00000000 \/\/ WaitTimeout's r8<\/font>\n00000001`027cf058  00000000`00006ac8\n00000001`027cf060  00000000`3b803fb8 \/\/ Wait's rsi<\/font>\n00000001`027cf068  00007ff7`eeff3cc0 FABRIKAM!AccessRequest::Wait+0x18\n00000001`027cf070  00000000`8007000e \/\/ Wait's rbx<\/font>\n00000001`027cf078  00000000`fd416ff0\n00000001`027cf080  4fe80c4a`51236583\n00000001`027cf088  00000000`3b803fb8\n00000001`027cf090  00000000`ffffffff \/\/ INFINITE parameter<\/font>\n00000001`027cf098  00000000`00000000\n00000001`027cf0a0  00000000`3b803fa0\n00000001`027cf0a8  00007ff7`da8375b7 FABRIKAM!DataAccess::RequestAccess+0x93\n00000001`027cf0b0  00000000`3b803fa0\n00000001`027cf0b8  00000000`3b803fb8\n00000001`027cf0c0  4fe80c4a`51236583\n00000001`027cf0c8  10f513ec`6a161fb8\n00000001`027cf0d0  00000000`00000076\n00000001`027cf0d8  00007ff7`f07a8619\n00000001`027cf0e0  000095dc`90897985\n00000001`027cf0e8  00000000`00000110\n00000001`027cf0f0  00000000`00000000\n00000001`027cf0f8  00000000`00000000\n00000001`027cf100  00007ff7`4dd8000c\n00000001`027cf108  00007ff7`f07a85e5\n00000001`027cf110  00000000`ffc03f90\n00000001`027cf118  00000001`027cf1e8\n00000001`027cf120  00000000`ffc03fc8 \/\/ VerifyData's r15<\/font>\n00000001`027cf128  00000000`00000000 \/\/ VerifyData's r14<\/font>\n00000001`027cf130  00000000`00000000 \/\/ VerifyData's r13<\/font>\n00000001`027cf138  00007ff7`4dd8000c \/\/ VerifyData's r12<\/font>\n00000001`027cf140  00007ff7`da5bc420 FABRIKAM!DataAccess::`vftable'+0x18 \/\/ VerifyData's rdi<\/font>\n00000001`027cf148  00000000`ffc03f90 \/\/ VerifyData's rsi<\/font>\n00000001`027cf150  00000001`027cf260 \/\/ VerifyData's rbp<\/font>\n00000001`027cf158  00007ff7`f0b3459c CONTOSO!DataWrapper::VerifyData+0x428\n00000001`027cf160  00000000`3b803fa0 \/\/ VerifyData's rbx<\/font>\n00000001`027cf168  00007ff7`f0ed1d30 CONTOSO!g_DataManager \/\/ VerifyData's rdx<\/font>\n00000001`027cf170  00000000`fe196f10 \/\/ VerifyData's r8<\/font>\n00000001`027cf188  00000000`00000001 \/\/ VerifyData's r9<\/font>\n00000001`027cf190  00000000`00000000\n00000001`027cf198  00000001`027cf270\n00000001`027cf1a0  00000001`027cf480\n00000001`027cf1a8  00007ff7`00000001\n00000001`027cf1b0  00000001`027cf220\n00000001`027cf1b8  00000000`00000000\n00000001`027cf1c0  00000000`00000000\n<\/pre>\n
\nFrom this, we can also suck out the\nthis<\/code> pointer passed to\nData­Access::Request­Access<\/code>.\nWe saw that it was stashed in rdi<\/code>.\nThe Wait<\/code> function doesn’t use rdi<\/code>\n(because if it did, it would have saved the old value),\nso its rdi<\/code> is the same as\nRequest­Access<\/code>‘s rdi<\/code>.\nSimilarly, the\nWait­Timeout<\/code> function does not use rdi<\/code>.\nTherefore, when\nWait­For­Single­Object<\/code> saves the\nrdi<\/code> register,\nit is saving the value from\nData­Access::Request­Access<\/code>.\n<\/p>\n
\n00000001`027cf028  00000000`3b803fa0 \/\/ WaitTimeout<\/strike> DataAccess's rdi<\/font>\n<\/pre>\n
\nAnd that is the this<\/code> pointer that lets us\nstudy the\nData­Access<\/code> object to figure out why\nits access request is not completing.<\/p>\n","protected":false},"excerpt":{"rendered":"
Suppose you have a machine that has crashed, and your investigation shows that the reason is that there is a critical section that everybody is waiting for. While waiting for that critical section, work piles up, and eventually the machine keels over. Suppose further that this crash is given to you in the form of […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-43613","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
Suppose you have a machine that has crashed, and your investigation shows that the reason is that there is a critical section that everybody is waiting for. While waiting for that critical section, work piles up, and eventually the machine keels over. Suppose further that this crash is given to you in the form of […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/43613","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=43613"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/43613\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=43613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=43613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=43613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}