Benefits of eXDI Hardware-Assisted Debugging (Windows CE 5.0)
Hardware-assisted debugging extends the debugging capabilities of Platform Builder beyond the potential of traditional software debuggers. Because hardware-assisted debugging is independent of the OS, you can:
- Isolate low-level problems that may arise in drivers and OAL code.
- Gain access to more powerful debugging logic such as advanced breakpoint conditions.
You can also use hardware-assisted debugging to debug other kinds of code, such as drivers and applications with the same ease of use as with the Platform Builder kernel debugger, the software probe solution for system-wide debugging or with native application debuggers.
The following table shows the differences between eXDI hardware-assisted debugging and kernel debugging with a kernel debug stub.
| eXDI hardware-assisted debugging | eXDI hardware-assisted debugging with OS Access | Kernel debugging |
|---|---|---|
| Does not rely on target-side debug routines.
Has no access to OS-generated information. Can debug in every situation, just out of reset. Operates non-intrusively, and independently of the kernel state. |
Combines capabilities of hardware-only and kernel debugging.
Can debug in any situation. Allows developer to select which routines to use in different situations. |
Relies on kernel debugging services to
Operates relatively intrusively and dependently. |
| Has no knowledge of where symbols are loaded at run time.
By default, Platform Builder loads only one Nk.exe module, which means that only Nk.exe can be debugged with sources and symbols. |
Accesses symbol information programmatically through the IMiniSH interfaces.
Gets process, thread, and module information through the OS Access component. |
Finds the location of symbols dynamically, at run time through kernel-generated load and unload notifications. |
| May be able to read or write memory, registers, or breakpoints while running, depending on the type of target device and probe being used. | Can read and write memory and registers, and can determine virtual-to-physical memory mapping. | Cannot read or write memory, registers, or breakpoints while running. |
| Choosing Break from the Debug menu results in an asynchronous break at the exact location of current execution. | Choosing Break from the Debug menu results in an asynchronous break at the exact location of current execution. | Choosing Break from the Debug menu results in calling DebugBreak() in Shell.exe, a process on the target device.
DebugBreak() contains a software breakpoint that is trapped by the Windows CE kernel and invokes the kernel debugger. |
| When the target device is running, the Process window and the Thread window can be populated by querying the Shell.exe process on the target device.
When the target device is halted, the Process window and the Thread window are not available. |
The Process window and the Thread window are always available.
When the target device is running, these windows can be populated by querying the Shell.exe process on the target device. When the target device is halted, these windows can be populated by querying the OS Access component. |
The Process window and the Thread window are always available.
When the target device is running, these windows can be populated by querying the Shell.exe process on the target device. When the target device is halted, these windows can be populated by querying the kernel debugger services. |
| The debugger cannot always read or write memory, or set software breakpoints, on locations of a process space that has page-on-demand enabled. | The debugger can always read and write memory and can always set breakpoints.
Access to virtual memory pages is available through the OS Access component. |
The kernel debugging module, Kd.dll, calls kernel routines, even when halted, to page-in any virtual memory pages it needs to access. |
See Also
Debugging Resources Overview | Configuring eXDI Hardware-Assisted Debugging | Using the eXDI Hardware-Assisted Debugger
Send Feedback on this topic to the authors