SoftICE uses symbolic names to label memory object if symbol table is
Many of the SoftICE commands display in-memory objects with
symbolic names if relevant symbol tables are loaded in the reserved
SoftICE symbol memory. There can be as many as 256 symbol talbes loaded
unless it reaches to the limit of reserved memory.
There are three primary types of symbolic information (debug
information) that SoftICE can use if available.
- Public symbols - global variables and functions
- Line number information - source file information for source
- Type information - required for local variable and structure
variable viewing support
In addition, all dynamic link libraries usually export a type of
symbolic information called "exports". Exports are very similar to "public
symbols". It is a set of functions exported by a DLL, and its symbolic
information (symbol:offset information) is available through DLL's "export
table". It does not have to come with a debug information. SoftICE's
loader utilities (e.g. Loader32) can load "exports" of any DLL including
system DLLs like kernel32 and user32.
Trouble shooting tips
Sometimes, you encounter problems with
loading symbol information into SoftICE. There are many different
scenarios, but it is probably one of the following cases.
- Symbol table is correctly loaded (verified with "TABLE" command),
but no source files are loaded. SoftICE "FILE" command produces no
- Both symbol talbe and a set of source files are correctly loaded
(verified with "TABLE" and "FILE" command), but when the execution
enters a function scope, there is no local variable displayed in the
Local Window - "TYPES" command produces no output.
- Everything is loaded correctly (symbol table, source files, and type
information), but when I load the executable program, SoftICE does not
stop at WinMain (main)
- This is usually caused by building your program without "line number
information". Check your compiler's option and use the switch that
generates "full debug information" (e.g. /Zi or /Z7 for Microsoft
compiler). You should also check linker options. Unless you specify
it, linker may fail to collect debug information from object files.
Also, another possibility is that even though appropriate "line number
information" was correctly generated by your build tools, NuMega symbol
loader (e.g. LOADER32, NMSYM, SymbolLoader, etc.) failed to pull source
files. This may be caused by having an option - prompt for missing
files - off and source search path not pointing to correct directories.
Try to force loader utility to prompt for missing files in order to
find out if this is the case.
- This is mostly caused by building your program without "type information".
Check your compiler's option and use the switch that generates "full
debug information" (e.g. /Zi or /Z7 for Microsoft compiler). Note
that this problem is often caused by having compulier debug switches
that are obsolete. It includes /Zd, /Zl, etc. for Microsoft compiler.
- This is normally caused by symbol table not being correctly mapped
to the load address of the target module. For detail, refer to
"Symbol Table" - the most important thing for source level debugging