Windows sysinternals

Chapter 2 Windows Core Concepts 27
A symbol file must be built at the same time as its corresponding executable or it will not be
correct and the debug engine might refuse to use it. Older versions of Microsoft Visual C++
created symbol files only for Debug builds unless the developer explicitly changed the build
configuration. Newer versions now create symbol files for Release builds as well, writing them
into the same folder with the executable files. Microsoft Visual Basic 6 can create symbol files,
but it does not do so by default.
Symbol files can contain differing levels of detail. Full symbol files (sometimes called private
symbol files) contain details that are not found in public symbol files, including the path to
and the line number within the source file where the symbol is defined, function parameter
names and types, and variable names and types. Software companies that make symbol files
externally available typically release only public symbol files, while retaining the full symbol
files for internal use.
The Debugging Tools for Windows make it possible to download correct symbol files on
demand from a symbol server. The server can store symbol files for many different builds of
a given executable file, and the Debugging Tools will download the one that matches the
image you are debugging. (It uses the timestamp and checksum stored in the executable’s
header as a unique identifier.)
Microsoft has a symbol server accessible over the Web that makes Windows’ public symbol
files freely available. By installing the Debugging Tools for Windows and configuring the
Sysinternals utilities to use the Microsoft symbol server, you can easily see what Windows
functions are being invoked by your processes.
Figure 2-5 shows a call stack for an event captured with Process Monitor. The presence of
MSVBVM60.DLL on the stack (frames 15 and 17–21) indicates that this is a Visual Basic 6
program because MSVBVM60.DLL is the Visual Basic 6 runtime DLL. The large offsets for
the MSVBVM60 frames suggest that symbols are not available for that module and that the
names shown are not the actual functions being called. Frame 14 shows a call into a function
named Form1::cmdCreate_Click in the main executable (LuaBugs_VB6.exe). This frame also
shows a source file path, indicating that we have full symbolic information for this third-party
module. This function then calls CWshShell::RegWrite in Wshom.ocx (frame 13), indicating
that this Visual Basic 6 program is using a Windows Script Host ActiveX to write to the registry.
CWshShell::RegWrite calls an internal function in the same module (frame 12), which calls
the documented RegCreateKeyExA Windows API in Kernel32.dll (frame 11). Execution passes
through Kernel32 internal functions (frames 8–10) and then into the ZwCreateKey native API
in Ntdll.dll (frame 7). So far, all of these functions have executed in user mode, as indicated by
the U in the Frame column, but in frame 6 the program transitions to kernel mode, indicated
by the K. The two-letter prefixes of the kernel functions (frames 0–6) identify the executive
components to which they belong. For example, Cm refers to the Configuration Manager,
which is responsible for the registry, and Ob refers to the Object Manager. It was during the
processing of CmpCallCallBacks (frame 0) that this stack trace was captured. Note that the
www.it-ebooks.info