S

scope
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.

second-chance exception
The second opportunity to handle an exception. This opportunity is only provided if the exception was not handled on the first chance.

smart client
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.

specific filter
An event filter for an event for which the engine has a built-in filter.

software breakpoint
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.

stack
See call stack.

stack frame
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.

stop code
See bug check code.

stop error
See bug check.

stop screen
See blue screen.

subregister
A register that is contained within another register. When the subregister changes, the portion of the register that contains the subregister also changes.

suspended
A target, process, or thread is suspended if it has been blocked it from executing.

symbol
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.

symbol file
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.

symbol group
A group of symbols, typically representing all the local variables in a scope.

symbol type
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.

synthetic module
A region of memory that the engine treats like a module. A synthetic module may contain synthetic symbols.

synthetic symbol
A memory address that the engine treats like a symbol.

system crash
See bug check.