The context that defines the local variables. The scope has three components: a stack frame, a current instruction, and a register context.
Sometimes referred to as local context or lexical scope.
The second opportunity to handle an exception. This opportunity is only provided if the exception was not handled on the first chance.
An instance of the debugger engine acting as a host. The smart client is connected to a process server. or a KD connection server.
specific exception filter
An event filter for an exception for which the engine has a built-in filter. Most specific exception filters refer to specific types of exceptions (identified by exception code), but the default exception filter also qualifies as a specific exception filter.
specific event filter
An event filter for an event which is not an exception. The specific event filters are listed in DEBUG_FILTER_XXX.
An event filter for an event for which the engine has a built-in filter.
A breakpoint that is implemented by the debugger engine temporarily modifying the target's executable code. The breakpoint is triggered when the code is executed. The code modification is invisible to users of the debugger or the debugger engine API.
See call stack.
The memory in the call stack containing the data for a single function call. This includes the return address, parameters passed to the function, and local variables.
See bug check code.
See bug check.
See blue screen.
A register that is contained within another register. When the subregister changes, the portion of the register that contains the subregister also changes.
A target, process, or thread is suspended if it has been blocked it from executing.
A unit of debugging information which provides interpretive information about the target in a debugging session. Examples of symbols include variables (local and global), functions, types and function entries. Information about symbols can include the name, type (if applicable), and the address or regisgter where it is stored, as well as any parent or child symbols. This information is stored in symbol files and is typically not available in the module itself.
The debugger engine can synthesize certain symbols when symbol files are not available (for example, exported symbols), but these symbols generally provide only minimal information.
A supplemental file created when an application, library, driver, or operating system is built. A symbol file contains data which is not actually needed when running the binaries, but which is very useful in the debugging process.
A group of symbols, typically representing all the local variables in a scope.
Descriptive information about a symbol's representation, such as its layout in memory. This is part of the information a compiler uses to generate code to manipulate the symbol. It is also used by the debugger engine to manipulate symbols. The symbol type is distributed in symbol files.
A region of memory that the engine treats like a module. A synthetic module may contain synthetic symbols.
A memory address that the engine treats like a symbol.
See bug check.