{"id":4133,"date":"2010-01-05T12:48:00","date_gmt":"2010-01-05T12:48:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2010\/01\/05\/dia-based-stack-walking\/"},"modified":"2019-02-18T18:45:42","modified_gmt":"2019-02-18T18:45:42","slug":"dia-based-stack-walking","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/dia-based-stack-walking\/","title":{"rendered":"DIA based Stack Walking"},"content":{"rendered":"

Hello, I am Manish Vasani, an SDET on the VC++ compiler backend team. In this series of posts, I will talk about call stacks and how to use the <\/font>DIA SDK<\/font><\/a> for implementing a stack walking client that builds a call stack. If you are interested in knowing how debuggers build the call stack or want to write an application that dumps the call stack for an executing process, you may want to continue reading further. <\/font><\/font><\/p>\n

In this post I’ll start with a brief introduction on stack walking, discuss the DIA APIs for implementing it, and then walkthrough a code sample for a DIA based stack walker. Those who are familiar with stack walking would know that apart from the DIA SDK, there are two other commonly used stack walking APIs: <\/font>StackWalk64<\/font><\/a> (found in <\/font>DbgHelp<\/font><\/a>) and <\/font>RtlVirtualUnwind<\/font><\/a> (found in kernel32.lib). I’ll touch upon these two APIs at the end of the post. <\/p>\n

<\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Introduction:<\/font><\/font><\/u><\/b><\/p>\n

When the Operating system executes a process, it calls into the program’s entry point (or the starting function) and allocates a set of resources to the process. Some of these resources such as stack memory and register context are allocated per thread basis. Every new function call in the thread is allocated a part of this stack memory and has a new register context. A stack frame or an <\/font>activation record<\/font><\/a> is essentially this runtime state information for an active function call. Typical attributes associated with a stack frame are:<\/p>\n

<\/font><\/font><\/p>\n

1)<\/font>      <\/span><\/span><\/span>Function associated with the frame<\/p>\n

<\/font><\/font><\/p>\n

2)<\/font>      <\/span><\/span><\/span>Module (binary) associated with the frame<\/p>\n

<\/font><\/font><\/p>\n

3)<\/font>      <\/span><\/span><\/span>Return address<\/p>\n

<\/font><\/font><\/p>\n

4)<\/font>      <\/span><\/span><\/span>Amount of stack memory allocated for arguments and locals for the function<\/p>\n

<\/font><\/font><\/p>\n

5)<\/font>      <\/span><\/span><\/span>Base pointer (BP) for referencing the arguments passed to the function call<\/p>\n

<\/font><\/font><\/p>\n

6)<\/font>      <\/span><\/span><\/span>Base pointer (BP) for referencing the local variables in the function (most of the time this is same as 5)<\/p>\n

<\/font><\/font><\/p>\n

7)<\/font>      <\/span><\/span><\/span>Program counter or the Instruction Pointer for currently executing instruction (IP)<\/p>\n

<\/font><\/font><\/p>\n

8)<\/font>      <\/span><\/span><\/span>Stack Pointer (SP)<\/p>\n

<\/font><\/font><\/p>\n

9)<\/font>      <\/span><\/span><\/span>Other Register context<\/p>\n

<\/font><\/font><\/p>\n

A sequence of active stack frames in an executing thread is generally referred to as a call stack. Call stacks help developers to debug runtime program errors and also denote the program state at a particular execution point. The process of building this call stack is called stack walking. Stack walking clients (such as debuggers) use the stack frame attributes to retrieve the values of function arguments, locals, etc.<\/p>\n

<\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

DIA APIs for St\nack walking:<\/font><\/font><\/u><\/b><\/p>\n

The primary functionality of the <\/font>DIA SDK<\/font><\/a> is to provide access to the debug information in PDB files. Apart from that, the DIA SDK also provides a set of interfaces  that can be used to implement a platform independent stack walker. These are:<\/p>\n

<\/font><\/font><\/p>\n

1)<\/font>      <\/span><\/span><\/span>IDiaStackWalker<\/font><\/a>: This is the primary initialization interface for the DIA stack walker.<\/p>\n

<\/font><\/font><\/p>\n

2)<\/font>      <\/span><\/span><\/span>IDiaEnumStackFrames<\/font><\/a>: This is the stack frame enumerator interface that exposes the primary API to perform a stack walk to the next frame.<\/p>\n

<\/font><\/font><\/p>\n

3)<\/font>      <\/span><\/span><\/span>IDiaStackFrame<\/font><\/a>: This interface represents a stack frame and exposes attributes of the stack frame. <\/p>\n

<\/font><\/font><\/p>\n

4)<\/font>      <\/span><\/span><\/span>IDiaStackWalkHelper<\/font><\/a>: This is a helper interface for the DIA stack walker. To understand its primary purpose, let us briefly mention the two primary types of inputs required by the stack walker:<\/p>\n

<\/font><\/font><\/p>\n

                              <\/span>i.<\/font>      <\/span><\/span><\/span>Run-time entities: This includes the runtime aspects such as thread’s register context, properties of loaded image files such as <\/font>LOADED_IMAGE<\/font><\/a>, executable binary (or module) corresponding to a given virtual address, etc.<\/p>\n

<\/font><\/font><\/p>\n

                             <\/span>ii.      <\/span><\/span><\/span><\/span>Compile-time generated entities: This includes the PDB records that provide static attributes for frames such as memory allocated for locals\/arguments, whether the function corresponding to the frame contains SEH\/C++ EH, the unwind program to execute to walk to the next frame, etc. <\/p>\n

<\/span><\/span><\/font><\/font><\/p>\n

DIA stack walker uses other DIA interfaces to read the compile time generated entities, i.e. PDB records. It delegates fetching the runtime entities to the DIA clients. The primary reason for this being that DIA doesn’t maintain the runtime state information for the process. For example, a given virtual address in process’ address space might belong to any one of the modules (executable binaries) loaded in the process. Each module would have a different pdb file and hence a different DIA session to read the pdb. DIA isn’t aware about the loaded modules for the process and hence expects its clients to provide this mapping. Most DIA stack walker clients, such as debuggers, already need to fetch and store this runtime information. Hence, it is logical to expect the clients to provide this information to DIA through the implementation of this helper interface.<\/p>\n

<\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

Code Sample Walkthrough:<\/p>\n

<\/font><\/font><\/u><\/b><\/p>\n

I will first give the class design for the DIA based stack walker sample and then walk you through its execution flow.<\/p>\n

<\/font><\/font><\/p>\n

Class design: <\/p>\n

<\/font><\/font><\/u><\/b><\/p>\n

1)<\/font>      <\/span><\/span><\/span>MyDiaStackWalker: <\/i>This is the primary DIA stack walker class. It maintains a handle to the initialization interface (IDiaStackWalker) and the stack frame enumerator (IDiaEnumStackFrames). It also contains few helper methods for other DIA operation\ns.<\/p>\n

<\/u><\/b><\/font><\/font><\/p>\n

2)<\/font>      <\/span><\/span><\/span>MyDiaStackWalkHelper:<\/i> This class implements the IDiaStackWalkHelper interface. I will discuss each of its method in detail later on.<\/p>\n

<\/u><\/b><\/font><\/font><\/p>\n

3)<\/font>      <\/span><\/span><\/span>Debugger<\/i>: This is a Debugger class with a simple debugging engine. It launches the specified executable with debugging enabled and dumps the call stack at every debug break event in the executable. (Debug break events could be trigged by use of <\/font><\/font>__debugbreak<\/font><\/a>() intrinsic in your source code).<\/p>\n

<\/u><\/b><\/font><\/font><\/p>\n

4)<\/font>      <\/span><\/span><\/span>ContextManager<\/i>: This class manages the register context associated with the current stack frame of the current debuggee thread (debuggee is the process being debugged)<\/p>\n

<\/u><\/b><\/font><\/font><\/p>\n

5)<\/font>      <\/span><\/span><\/span>ModuleManager: <\/i>This class maintains the list of modules (executable binaries) loaded in the process along with their attributes.<\/p>\n

<\/u><\/b><\/font><\/font><\/p>\n

Execution Flow:<\/p>\n

<\/font><\/font><\/u><\/b><\/p>\n

1)<\/font>      <\/span><\/span><\/span>Initialization<\/u><\/b>:<\/p>\n

<\/u><\/font><\/font><\/p>\n

The first step in the application is to initialize the DIA stack walker. This is done through the IDiaStackWalker interface. IDiaStackWalker provides two platform specific APIs for initializing the DIA client: <\/font>getEnumFrames<\/font><\/a> (for x86) and <\/font>getEnumFrames2<\/font><\/a> (for x64 and ia64 platforms). Each of these APIs take a pointer to the class that implements IDiaStackWalkHelper (MyDiaStackWalkHelper<\/i>) and returns the stack frame enumerator (IDiaEnumStackFrames). You may refer to the method “MyDiaStackWalker::Initialize” <\/i>in MyDiaStackWalker.cpp to see the initialization logic. <\/p>\n

<\/font><\/font><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

2)<\/font>      <\/span><\/span><\/span><\/b>Walking the stack: <\/p>\n

<\/font><\/font><\/u><\/b><\/p>\n

After the initialization, we launch the specified executable under the debugger. On hitting a debug break event, we initialize the register context and loaded modules for the debuggee. Than we call “MyDiaStackWalker::WalkCallStack” <\/i>method to walk the call stack and retrieve attributes such as module name, function name, Instruction pointer (IP), etc. for each stack frame:<\/p>\n

<\/font><\/font><\/p>\n

\/\/ method to walk all the stack frames in the call stack<\/span><\/p>\n

<\/span><\/p>\n

void<\/span> MyDiaStackWalker::WalkCallStack<\/b>()<\/p>\n

<\/span><\/p>\n

{  <\/p>\n

<\/span><\/p>\n

  wprintf(L“nWalking call stack…n”<\/span>);<\/p>\n

<\/span><\/p>\n

  IDiaSymbol *pFuncSym = NULL;    <\/p>\n

<\/span><\/p>\n

  DWORD count = 0<\/span>;<\/p>\n

<\/span><\/p>\n

  BSTR szFunctionName;<\/p>\n

<\/span><\/p>\n

  ULONGLONG ip = 0<\/span>;<\/p>\n

<\/span><\/p>\n

  <\/p>\n

<\/span><\/p>\n

  do<\/span> {<\/p>\n

<\/span><\/p>\n

    \/\/ Get IP for current stack frame<\/span><\/p>\n

<\/span><\/p>\n

&n\nbsp;   pContextManager->get_currentIP(&ip);<\/p>\n

<\/span><\/p>\n

    if<\/span> (!ip) {<\/p>\n

<\/span><\/p>\n

      break<\/span>;<\/p>\n

<\/span><\/p>\n

    }<\/p>\n

<\/span><\/p>\n

    \/\/ Get module for stack frame<\/span><\/p>\n

<\/span><\/p>\n

    Module *pModule = pModuleManager->FindModuleByVA(ip);<\/p>\n

<\/span><\/p>\n

    \/\/ Get DIA function symbol for stack frame<\/span><\/p>\n

<\/span><\/p>\n

    pMyDiaStackWalkHelper->symbolForVA(ip, &pFuncSym);<\/p>\n

<\/span><\/p>\n

    \/\/ Display stack frame attributes<\/span><\/p>\n

<\/span><\/p>\n

    if<\/span> (pFuncSym == NULL) {<\/p>\n

<\/span><\/p>\n

      \/\/ function symbol could be null if symbols for the module were not loaded.<\/p>\n

<\/span><\/span><\/p>\n

      \/\/ just dump the IP for the stack frame<\/p>\n

<\/span><\/p>\n

      wprintf(L“Stack Frame %d: ‘%ws!%#x()’n”<\/span>, ++count, pModule->name, ip);<\/p>\n

<\/span><\/p>\n

      continue<\/span>;<\/p>\n

<\/span><\/p>\n

    }<\/p>\n

<\/span><\/p>\n

    if<\/span> (pFuncSym->get_name(&szFunctionName) == S_OK) {<\/p>\n

<\/span><\/p>\n

      wprintf(L“Stack Frame %d: ‘%ws!%ws’n”<\/span>, ++count, pModule->name, szFunctionName);<\/p>\n

<\/span><\/p>\n

      SysFreeString(szFunctionName);<\/p>\n

<\/span><\/p>\n

    }<\/p>\n

<\/span><\/p>\n

    pFuncSym->Release();<\/p>\n

<\/span><\/p>\n

    pFuncSym = NULL; <\/p>\n

<\/span><\/p>\n

    \/\/ Walk to next stack frame<\/span><\/p>\n

<\/span><\/p>\n

  } while<\/span> (WalkStackFrame() == S_OK);<\/p>\n

<\/span><\/p>\n

}<\/p>\n

<\/span><\/p>\n

\n

 <\/font><\/p>\n<\/p>\n

“WalkCallStack”<\/i> method calls into “WalkStackFrame”<\/i> to walk each stack frame. WalkStackFrame <\/i>uses the stack frame enumerator API (<\/font>IDiaEnumStackFrames::Next<\/font><\/a>) to do the stack walk to next frame. Following snippet shows this:<\/p>\n

<\/font><\/font><\/p>\n

\/\/ MyDiaStackWalker.cpp<\/p>\n

<\/span><\/p>\n

\/\/ method to walk to the next stack frame<\/span><\/p>\n

<\/span><\/p>\n

HRESULT MyDiaStackWalker::WalkStackFrame<\/b>(IDiaStackFrame **ppStackFrame)<\/p>\n

<\/span><\/p>\n

{<\/p>\n

<\/span><\/p>\n

  IFVERBOSE {<\/p>\n

<\/span><\/p>\n

    wprintf(L“MyDiaStackWalker::WalkStackFramen”<\/span>);<\/p>\n

<\/span><\/p>\n

  }<\/p>\n

<\/span><\/p>\n

  <\/p>\n

<\/span><\/p>\n

  ULONG celtFetched = 0<\/span>;  <\/p>\n

<\/span><\/p>\n

  IDiaStackFrame *pStackFrame = NULL;<\/p>\n

<\/span><\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

Hello, I am Manish Vasani, an SDET on the VC++ compiler backend team. In this series of posts, I will talk about call stacks and how to use the DIA SDK for implementing a stack walking client that builds a call stack. If you are interested in knowing how debuggers build the call stack or […]<\/p>\n","protected":false},"author":289,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[55,56,57],"class_list":["post-4133","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","tag-debugging","tag-dia-sdk","tag-stack-walking"],"acf":[],"blog_post_summary":"

Hello, I am Manish Vasani, an SDET on the VC++ compiler backend team. In this series of posts, I will talk about call stacks and how to use the DIA SDK for implementing a stack walking client that builds a call stack. If you are interested in knowing how debuggers build the call stack or […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4133","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/289"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=4133"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4133\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=4133"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=4133"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=4133"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}