CVW recognizes several commands for Windows debugging in addition to the Command-window commands recognized by CV.
These commands allow you to inspect objects in the Windows global and local heaps, list the currently loaded modules, trace and set breakpoints on the occurrence of Windows messages, and terminate the currently executing task.
The Windows Display Global Heap (WDG) command lists the memory objects in the Windows global heap.
WDG [[ghandle]]
If ghandle is specified, WDG displays the first five global memory objects that start at the object specified by ghandle. The ghandle argument must be a valid handle to an object allocated on the global heap.
If ghandle is not specified, WDG displays the entire global heap in the Command window.
Global memory objects are displayed in the order in which Windows manages them, which is typically not in ascending handle order. The output has the following format:
handle address size PDB locks type owner
Any field may not be present if that field is not defined for the block.
| Field | Description |
| handle | Value of the global memory block handle. |
| address | Address of the global memory block. |
| size | Size of the block in bytes. |
| PDB | Block owner. If present, indicates that the task's Process Descriptor Block is the owner of the block. |
| locks | Count of locks on the block. |
| type | The memory-block type. |
| owner | The block owner's module name. |
The Windows Display Local Heap (WDL) command displays the entire Windows heap of local memory objects. This command's syntax takes no arguments.
WDL
The output has the following format:
handle address size flags locks type heaptype blocktype
Any field may not be present if that field is not defined for the block.
| Field | Description |
| handle | Value of the global memory block handle |
| address | Address of the block |
| size | Size of the block in bytes |
| flags | The block's flags |
| locks | Count of locks on the block |
| type | The type of the handle. |
| heaptype | The type of heap where the block resides |
| blocktype | The block's type |
The Windows Display Modules (WDM) command displays a list of all the DLL and task modules that Windows has loaded. To see a list of known modules, type the WDM command in the Command window.
WDM
Each entry in the list is displayed with the following format:
handle refcount module path
| Field | Description |
| handle | The module handle |
| refcount | The number of times the module has been loaded |
| module | The name of the module |
| path | The path of the module's executable file |
You can trace the occurrence of a Windows message or an entire class of Windows messages by using the Breakpoint Set (BP) command. You can stop at each message, or you can execute continuously and display the messages in the Command window as they are received.
To trace a Windows message or message class, set a breakpoint using the following options:
BP winproc /M{msgname|msgclass} [[/D]]
winproc
Symbol name or address of a window function.
msgname
The name of a Windows message, such as WM_PAINT. The msgname is case sensitive.
msgclass
A case-insensitive string of characters that identifies one or more classes of messages to watch. Use the following characters to indicate the class of Windows message:
| Class | Type of Windows Message |
| m | Mouse |
| w | Window management |
| n | Input |
| s | System |
| i | Initialization |
| c | Clipboard |
| d | DDE |
| z | Nonclient |
/D
When specified, CodeView displays the message in the command window, but your program continues executing. The message is displayed similar to the following example:
HWND:lc00 wParm:0000 lParm:000000 msg:000F WM_PAINT
For each matching message that is sent to the specified winproc, CVW lists the hexadecimal values of the window handle (HWND), word parameter (wParm), long parameter (lParm), and message (msg) arguments, along with the name of the message.
You can also specify a pass count and commands to be executed when the breakpoint is taken. For details on the full Breakpoint (BP) command syntax, see “BP (Breakpoint Set)” on page 429. Note that you can also use the Breakpoint Set command from the Data menu to set all types of breakpoints.
The Windows Kill Application (WKA) command terminates the currently executing task by simulating a fatal error. Since a fatal error terminates the application without performing any of the normal program exit processing, use WKA with caution.
To terminate your application, type the following command in the Command window:
WKA
As a result of the simulated fatal error, Windows displays an Unexpected Application Error message box. After you close this message box, Windows may not release subsequent mouse input messages from the system queue until you press a key.
If this happens, the mouse pointer moves on the Windows screen but Windows does not respond to the mouse. After you press any key, Windows responds to the queued mouse events.
The currently executing task is not necessarily your application, so you should use the WKA command only when your application is the currently executing task. You can be sure that your application is the currently executing task when CVW shows the current location at a breakpoint in your application.
For more information on using the WKA command, see “Terminating Your Program” on page 387.