Click here to Skip to main content
15,843,865 members
Articles / Web Development / HTML

Walking the callstack

Rate me:
Please Sign up or sign in to vote.
4.95/5 (140 votes)
14 Nov 2005BSD12 min read 1.6M   19.1K   361   376
This article describes the (documented) way to walk a callstack for any thread (own, other and remote). It has an abstraction layer, so the calling app does not need to know the internals.

Sample Image - StackWalker.gif

This project is now maintained on GitHub /



In some cases, you need to display the callstack of the current thread or you are just interested in the callstack of other threads / processes. Therefore, I wrote this project.

The goal for this project was the following:

  • Simple interface to generate a callstack
  • C++ based to allow overwrites of several methods
  • Hiding the implementation details (API) from the class' interface
  • Support of x86, x64 and IA64 architecture
  • Default output to debugger-output window (but can be customized)
  • Support of user-provided read-memory-function
  • Support of the widest range of development-IDEs (VC5-VC8)
  • Most portable solution to walk the callstack


To walk the callstack, there is a documented interface: StackWalk64. Starting with Win9x/W2K, this interface is in the dbghelp.dll library (on NT, it is in imagehlp.dll). But the function name (StackWalk64) has changed starting with W2K (before it was called StackWalk (without the 64))! This project only supports the newer Xxx64-funtions. If you need to use it on older systems, you can download the redistributable for NT/W9x.

The latest dbghelp.dll can always be downloaded with the Debugging Tools for Windows. This also contains the symsrv.dll which enables the use of the public Microsoft symbols-server (can be used to retrieve debugging information for system-files; see below).

Using the Code

The usage of the class is very simple. For example, if you want to display the callstack of the current thread, just instantiate a StackWalk object and call the ShowCallstack member:

#include <windows.h>
#include "StackWalker.h"

void Func5() { StackWalker sw; sw.ShowCallstack(); }
void Func4() { Func5(); }
void Func3() { Func4(); }
void Func2() { Func3(); }
void Func1() { Func2(); }

int main()
  return 0;

This produces the following output in the debugger-output window:

[...] (output stripped)
d:\privat\Articles\stackwalker\stackwalker.cpp (736): StackWalker::ShowCallstack
d:\privat\Articles\stackwalker\main.cpp (4): Func5
d:\privat\Articles\stackwalker\main.cpp (5): Func4
d:\privat\Articles\stackwalker\main.cpp (6): Func3
d:\privat\Articles\stackwalker\main.cpp (7): Func2
d:\privat\Articles\stackwalker\main.cpp (8): Func1
d:\privat\Articles\stackwalker\main.cpp (13): main
f:\vs70builds\3077\vc\crtbld\crt\src\crt0.c (259): mainCRTStartup
77E614C7 (kernel32): (filename not available): _BaseProcessStart@4

You can now double-click on a line and the IDE will automatically jump to the desired file/line.

Providing Own output-mechanism

If you want to direct the output to a file or want to use some other output-mechanism, you simply need to derive from the StackWalker class. You have two options to do this: only overwrite the OnOutput method or overwrite each OnXxx-function. The first solution (OnOutput) is very easy and uses the default-implementation of the other OnXxx-functions (which should be enough for most of the cases). To output also to the console, you need to do the following:

class MyStackWalker : public StackWalker
  MyStackWalker() : StackWalker() {}
  virtual void OnOutput(LPCSTR szText)
    { printf(szText); StackWalker::OnOutput(szText); }

Retrieving Detailed Callstack Information

If you want detailed information about the callstack (like loaded-modules, addresses, errors, ...) you can overwrite the corresponding methods. The following methods are provided:

class StackWalker
  virtual void OnSymInit(LPCSTR szSearchPath, DWORD symOptions, LPCSTR szUserName);
  virtual void OnLoadModule(LPCSTR img, LPCSTR mod, DWORD64 baseAddr, DWORD size,
    DWORD result, LPCSTR symType, LPCSTR pdbName, ULONGLONG fileVersion);
  virtual void OnCallstackEntry(CallstackEntryType eType, CallstackEntry &entry);
  virtual void OnDbgHelpErr(LPCSTR szFuncName, DWORD gle, DWORD64 addr);

These methods are called during the generation of the callstack.

Various Kinds of callstacks

In the constructor of the class, you need to specify if you want to generate callstacks for the current process or for another process. The following constructors are available:

class StackWalker
    int options = OptionsAll,
    LPCSTR szSymPath = NULL,
    DWORD dwProcessId = GetCurrentProcessId(),
    HANDLE hProcess = GetCurrentProcess()
  // Just for other processes with
  // default-values for options and symPath
    DWORD dwProcessId,
    HANDLE hProcess

To do the actual stack-walking, you need to call the following functions:

class StackWalker
  BOOL ShowCallstack(
    HANDLE hThread = GetCurrentThread(),
    CONTEXT *context = NULL,
    PReadProcessMemoryRoutine readMemoryFunction = NULL,
    LPVOID pUserData = NULL

Displaying the callstack of an Exception

With this StackWalker, you can also display the callstack inside an exception handler. You only need to write a filter-function which does the stack-walking:

// The exception filter function:
  StackWalker sw;
  sw.ShowCallstack(GetCurrentThread(), pExp->ContextRecord);

// This is how to catch an exception:
  // do some ugly stuff...
__except (ExpFilter(GetExceptionInformation(), GetExceptionCode()))

Points of Interest

Context and callstack

To walk the callstack of a given thread, you need at least two facts:

  • The context of the thread

    The context is used to retrieve the current Instruction Pointer and the values for the Stack Pointer (SP) and sometimes the Frame Pointer (FP). The difference between SP and FP is in short: SP points to the latest address on the stack. FP is used to reference the arguments for a function. See also Difference Between Stack Pointer and Frame Pointer. But only the SP is essential for the processor. The FP is only used by the compiler. You can also disable the usage of FP (see: /Oy (Frame-Pointer Omission)).

  • The callstack

    The callstack is a memory-region which contains all the data/addresses of the callers. This data must be used to retrieve the callstack (as the name says). The most important part is: this data-region must not change until the stack-walking is finished! This is also the reason why the thread must be in the Suspended state to retrieve a valid callstack. If you want to do a stack-walking for the current thread, then you must not change the callstack memory after the addresses which are declared in the context record.

Initializing the STACKFRAME64-structure

To successfully walk the callstack with StackWalk64, you need to initialize the STACKFRAME64-structure with meaningful values. In the documentation of StackWalk64, there is only a small note about this structure:

  • The first call to this function will fail if the AddrPC and AddrFrame members of the STACKFRAME64 structure passed in the StackFrame parameter are not initialized.

According to this documentation, most programs only initialize AddrPC and AddrFrame; and this had worked until the newest dbhhelp.dll (v5.6.3.7). Now, you also need to initialize AddrStack. After having some trouble with this (and other problems), I talked to the dbghelp-team and got the following answer (2005-08-02; my own comments are written in italics!):

  • AddrStack should always be set to the stack pointer value for all platforms. You can certainly publish that AddrStack should be set. You're also welcome to say that new releases of dbghelp are now requiring this.
  • Given a current dbghelp, your code should:
    1. Always use StackWalk64
    2. Always set AddrPC to the current instruction pointer (Eip on x86, Rip on x64 and StIIP on IA64)
    3. Always set AddrStack to the current stack pointer (Esp on x86, Rsp on x64 and IntSp on IA64)
    4. Set AddrFrame to the current frame pointer when meaningful. On x86 this is Ebp, on x64 you can use Rbp (but is not used by VC2005B2; instead it uses Rdi!) and on IA64 you can use RsBSP. StackWalk64 will ignore the value when it isn't needed for unwinding.
    5. Set AddrBStore to RsBSP for IA64

Walking the callstack of the Current Thread

On x86 systems (prior to XP), there is no direct supported function to retrieve the context of the current thread. The recommended way is to throw an exception and catch it. Now you will have a valid context-record. The default way of capturing the context of the current thread is by doing some inline-assembler to retrieve EIP, ESP and EBP. If you want to use the documented way, then you need to define CURRENT_THREAD_VIA_EXCEPTION for the project. But you should be aware of the fact, that GET_CURRENT_CONTEXT is a macro which internally uses __try __except. Your function must be able to contain these statements.

Starting with XP and on x64 and IA64 systems, there is a documented function to retrieve the context of the current thread: RtlCaptureContext.

To do a stack-walking of the current thread, you simply need to do:

StackWalker sw;

Walking the callstack of Other Threads in the Same Process

To walk the callstack of another thread inside the same process, you need to suspend the target thread (so the callstack will not change during the stack-walking). But you should be aware that suspending a thread in the same process might lead to dead-locks! (See: Why you never should call Suspend/TerminateThread (Part I, Part II, Part III))

If you have the handle to the thread, you can do the following to retrieve the callstack:

MyStackWalker sw;

For a complete sample to retrieve the callstack of another thread, you can take a look at the demo-project.

Walking the callstack of Other Threads in Other Processes

The approach is almost the same as for walking the callstack for the current process. You only need to provide the ProcessID and a handle to the process (hProcess). Then you also need to suspend the thread to do the stack-walking. A complete sample to retrieve the callstack of another process is in the demo-project.

Reusing the StackWalk Instance

It is no problem to reuse the StackWalk instance, as long as you want to do the stack-walking for the same process. If you want to do a lot of stack-walking, it is recommended to reuse the instance. The reason is simple: if you create a new instance, then the symbol-files must be re-loaded for each instance. And this is really time-consuming. Also, it is not allowed to access the StackWalk functions from different threads (the dbghelp.dll is not thread-safe!). Therefore, it makes no sense to create more than one instance...


By default, a symbol-search path (SymBuildPath and SymUseSymSrv) is provided to the dbghelp.dll. This path contains the following directories:

  • The optional provided szSymPath. If this parameter is provided, the option SymBuildPath is automatically set. Each path must be separated with a ";"
  • The current directory
  • The directory of the EXE
  • The environment variable _NT_SYMBOL_PATH
  • The environment variable _NT_ALTERNATE_SYMBOL_PATH
  • The environment variable SYSTEMROOT
  • The environment variable SYSTEMROOT appended with "\system32"
  • The public Microsoft symbol-server: SRV*%SYSTEMDRIVE%\websymbols*


If you want to use the public symbols for the OS-files from the Microsoft-Symbol-Server, you either need the Debugging Tools for Windows (then symsrv.dll and the latest dbghelp.dll will be found automatically) or you need to redistribute "dbghelp.dll" and "smysrv.dll" from this package!

Loading the Modules and Symbols

To successfully walk the callstack of a thread, dbghelp.dll requires that the modules are known by the library. Therefore, you need to "register" each module of the process via SymLoadModule64. To accomplish this, you need to enumerate the modules of the given process.

Starting with Win9x and W2K, it is possible to use the ToolHelp32-API. You need to make a snapshot (CreateToolhelp32Snapshot) of the process and then you can enumerate the modules via Module32First and Module32Next. Normally, the ToolHelp functions are located in the kernel32.dll but on Win9x, it is located in a separate DLL: tlhelp32.dll. Therefore, we need to check the functions in both DLLs.

If you have NT4, then the ToolHelp32-API is not available. But in NT4, you can use the PSAPI. To enumerate all modules, you need to call EnumProcessModules, but you only get the handles to the modules. To feed SymLoadModule64, you also need to query the ModuleBaseAddr, SizeOfImage (via GetModuleInformation), ModuleBaseName (via GetModuleBaseName) and ModuleFileName(Path) (via GetModuleFileNameEx).


There are a couple of issues with dbghelp.dll.

  • The first is, there are two "teams" at Microsoft which redistribute the dbghelp.dll. One team is the OS-team, the other is the Debugging-Tools-Team (I don't know the real names...). In general, you can say: The dbghelp.dll provided with the Debugging Tools for Windows is the most recent version. One problem of these two teams is the different versioning of the dbghelp.dll. For example, for XP-SP1 the version is 5.1.2600.1106 dated 2002-08-29. The version 6.0.0017.0 which was redistributed from the debug-team is dated 2002-04-31. So there is at least a conflict in the date (the newer version is older). And it is even harder to decide which version is "better" (or has more functionality).
  • Starting with Me/W2K, the dbghelp.dll-file in the system32 is protected by the System File Protection. So if you want to use a newer dbghelp.dll, you need to redistribute the version from the Debugging Tools for Windows (put it in the same directory as your EXE). This leads to a problem on W2K if you want to walk the callstack for an app which was built using VC7 or later. The VC7 compiler generates a new PDB-format (called DIA). This PDB-format cannot be read with the dbghelp.dll which is installed with the OS. Therefore, you will not get very useful callstacks (or at least with no debugging information like filename, line, function name, ...). To overcome this problem, you need to redistribute a newer dbghelp.dll.
  • The dbghelp.dll version has a bug or at least a documentation change of the StackWalk64 function. In the documentation, you can read:

    The first call to this function will fail if the AddrPC and AddrFrame members of the STACKFRAME64 structure passed in the StackFrame parameter are not initialized.


    [The ContextRecord] parameter is required only when the MachineType parameter is not IMAGE_FILE_MACHINE_I386.

    But this is not true anymore. Now the callstack on x86-systems cannot be retrieved if you pass NULL as ContextRecord. From my point of view, this is a major documentation change. Now you either need to initialize the AddrStack as well, or provide a valid ContextRecord which contains the EIP, EBP and ESP registers!

  • See also comments in the Initializing the STACKFRAME64-structure chapter...


To do some kind of modification of the behaviour, you can optionally specify some options. Here is the list of the available options:

typedef enum StackWalkOptions
  // No addition info will be retrieved
  // (only the address is available)
  RetrieveNone = 0,

  // Try to get the symbol-name
  RetrieveSymbol = 1,

  // Try to get the line for this symbol
  RetrieveLine = 2,

  // Try to retrieve the module-infos
  RetrieveModuleInfo = 4,

  // Also retrieve the version for the DLL/EXE
  RetrieveFileVersion = 8,

  // Contains all the above
  RetrieveVerbose = 0xF,

  // Generate a "good" symbol-search-path
  SymBuildPath = 0x10,

  // Also use the public Microsoft-Symbol-Server
  SymUseSymSrv = 0x20,

  // Contains all the above "Sym"-options
  SymAll = 0x30,

  // Contains all options (default)
  OptionsAll = 0x3F
} StackWalkOptions;

Known Issues

  • NT/Win9x: This project only support the StackWalk64 function. If you need to use it on NT4/Win9x, you need to redistribute the dbghelp.dll for this platform.
  • Currently only supports ANSI-names in callbacks (of course, the project can be compiled with UNICODE...).
  • To open a remote thread, I used "OpenThread" which is not available on NT4/W9x. To have an example of doing this in NT4/Win9x, please refer to Remote Library.
  • Walking mixed-mode callstacks (managed/unmanaged) does only return the unmanaged functions.


  • 2005-07-27
    • First public release
    • Supports x86, x64 and IA64
  • 2005-07-28
    • Changed the description, so it does not make the impression that this is the only documented way to walk the callstack...
    • ShowCallstack(hThread, ...) now accepts a NULL CONTEXT (this forces to capture the context of this thread); it also was simplified (now only one function for all situations)
    • Added chapters: Symbol-Search-Path, Loading the modules and symbols and dbghelp.dll
  • 2005-08-01
    • Added VC7.0 project/solution files
    • Added more comment to the GET_CURRENT_CONTEXT define regarding the use of RtlCaptureContext function
    • Problem with uninitialized cnt variable solved
    • Workaround for wrongly defined GetFileVersionInfoSize and GetFileVersionInfo (on older PSDK-Version (VC7 and before), the first parameter was declared as LPTSTR instead of LPCTSTR)
    • Changed the used ContextFlags parameter from CONTEX_ALL to CONTEXT_FULL (this also works correctly and is supported in older PSDK-versions)
    • Now compiles on VC5/6 without installing a newer Platform-SDK (all missing declarations are now embedded)
    • Added VC6 project/solution files
    • Added a pUserData member to the ShowCallstack function and the PReadProcessMemoryRoutine declaration (to pass some user-defined data, which can be used in the readMemoryFunction-callback)
  • 2005-08-02
    • OnSymInit now also outputs the OS-version by default
    • Added example for doing an exception-callstack-walking in main.cpp (thanks to owillebo)
    • Correction in article about RtlCaptureContext. This function is also available starting with XP (thanks to Dan Moulding)
    • Added chapters: Initializing the STACKFRAME64-structure, Displaying the callstack of an exception
  • 2005-08-05
    • Removed some Lint issues... thanks to Okko Willeboordse!
    • Removed all warnings with /analyze switch from VC8
  • 2005-09-06
    • Fixed a small bug regarding VC5/6 and old PSDK version (OSVERSIONINFOEX is not present)
  • 2005-11-07
    • Detects an "endless-callstack" and terminates the stackwalking
    • Usage of RtlCaptureContext only on x64 and IA64 platforms


This article, along with any associated source code and files, is licensed under The BSD License

Written By
Software Developer (Senior)
Germany Germany
1982: My first computer (VC20)
1984: Finished to build my first own computer (Z80)
1993: Mission-Volunteer in Papua New Guinea
1998: Dipl. Inform. (FH)
... working, working, working....

Comments and Discussions

PraiseVote Of 5! Pin
simbakid13-Sep-22 20:38
simbakid13-Sep-22 20:38 
QuestionK32GetModuleBaseNameA could not be located Pin
saud_ad30-Jan-21 16:47
saud_ad30-Jan-21 16:47 
QuestionThe line number is wrong - How to fix it? Pin
Member 1451200629-Dec-20 2:45
Member 1451200629-Dec-20 2:45 
GeneralMy vote of 5 Pin
Member 1477007912-Mar-20 0:47
Member 1477007912-Mar-20 0:47 
GeneralMy vote of 5 Pin
Member 1477007912-Mar-20 0:46
Member 1477007912-Mar-20 0:46 
QuestionLoading symbols from .SYM files Pin
MikeBz28-Nov-18 23:38
MikeBz28-Nov-18 23:38 
Question[USE ERROR]SymGetLineFromAddr64, GetLastError: 487 Pin
Member 130971125-Apr-17 0:07
Member 130971125-Apr-17 0:07 
QuestionCannot be used for different process Pin
MyKetty12-Mar-17 21:58
MyKetty12-Mar-17 21:58 
AnswerRe: Cannot be used for different process Pin
MikeBz28-Nov-18 23:45
MikeBz28-Nov-18 23:45 
QuestionIs it possible to get the name of function without pdb info ,where exception occurred? Pin
Member 124566138-Jan-17 20:52
Member 124566138-Jan-17 20:52 
GeneralMy vote of 2 Pin
Member 1252487023-Dec-16 0:42
Member 1252487023-Dec-16 0:42 
General5 stars Pin
wakko4542-Mar-15 12:51
wakko4542-Mar-15 12:51 
BugMyStrCpy causes assertion with "Buffer is too small" Pin
pjosep26-Dec-14 12:54
pjosep26-Dec-14 12:54 
QuestionLine number off by "one" (at least in VS2012) Pin
JesseChisholm31-Oct-13 7:29
JesseChisholm31-Oct-13 7:29 
AnswerRe: Line number off by "one" (at least in VS2012) Pin
JesseChisholm31-Oct-13 8:21
JesseChisholm31-Oct-13 8:21 
QuestionUse of strcpy_s in StackWalker Pin
JesseChisholm31-Oct-13 7:08
JesseChisholm31-Oct-13 7:08 
Questionfirst parameter to FatalAppExit() wrong? Pin
Harold Bamford27-Sep-13 7:45
Harold Bamford27-Sep-13 7:45 
GeneralMy vote of 5 Pin
lakshmana_198031-Jul-13 22:41
lakshmana_198031-Jul-13 22:41 
QuestionIt's really great!! Pin
zhegaozhouji29-Mar-13 21:24
zhegaozhouji29-Mar-13 21:24 
Questionusage of sprintf in the StackWalker Pin
Martin081522-Feb-13 9:29
professionalMartin081522-Feb-13 9:29 
AnswerRe: usage of sprintf in the StackWalker Pin
Jochen Kalmbach [MVP VC++]22-Feb-13 10:04
Jochen Kalmbach [MVP VC++]22-Feb-13 10:04 
GeneralRe: usage of sprintf in the StackWalker Pin
Martin081525-Feb-13 1:01
professionalMartin081525-Feb-13 1:01 
GeneralRe: usage of sprintf in the StackWalker Pin
Jochen Kalmbach [MVP VC++]25-Feb-13 11:29
Jochen Kalmbach [MVP VC++]25-Feb-13 11:29 
GeneralRe: usage of sprintf in the StackWalker Pin
Martin081526-Feb-13 3:19
professionalMartin081526-Feb-13 3:19 
GeneralRe: usage of sprintf in the StackWalker Pin
Jochen Kalmbach [MVP VC++]26-Feb-13 9:27
Jochen Kalmbach [MVP VC++]26-Feb-13 9:27 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.