Partager via

What’s new in Windows CE Platform Builder’s System Debugger 6.0?

  • Article

Posted by: Greg Hogdal
 

Windows CE 6.0 introduces a new kernel with a new virtual memory model – offering a different address space for each process, enabling the support of more than 32,000 simultaneous processes, each with 2GB of VM space. A major effort was to modify the kernel debugger to support this new kernel.

In addition, here is a list of major system debugger features that were introduced with PB 6.0:

  • Hosting the system-level debugger in the Visual Studio 2005 shell, like the rest of platform builder. The debugger keeps the familiar experience of previous versions of PB, while integrating into a more modern shell (bringing “intellisense”, resource view…).
  • Adding Post-Mortem debugging and “On-The-Fly” system dump capture:
    Starting with Windows CE 5.0, a system can include Windows Error Reporting (WER), similar to the desktop OS. If this is the case, a user can opt to send reports of any crash happening on the device to Microsoft servers. During the development phase, developers can also capture those reports and analyze them. Previously, we offered a standalone application to visualize the content of .KDMP files. In PB 6.0, .KDMP files can now be opened as Windows CE projects. In that case the debugger provides the same views as with a live target.
  • Improving overall reliability.

The following smaller features were also introduced in the 6.0 release:

  • Supporting USB serial Kernel Independent Transport Layer (KITL) and OS image download.
  • Supporting the Device Emulator (running ARM instructions).
  • A common command-line interface for debugger extensions, target control shell (CESH) and advanced debugger commands.
  • Displaying thread’s name symbolically in the threads window (using the thread base function name).
  • Delaying loading of modules until an exception happens:
    With this feature, the user has the option of trading faster boot-time for the capacity to set user breakpoints as modules get loaded, until an exception or a user break happens. This is also important to debug real-time systems that would otherwise be briefly halted on every module load or unload. This option can be changed with an advanced debugger commands or in the connectivity configuration dialog - service status – settings.
  • Adding the possibility to filter the module list per process in the modules window.
  • Displaying the list of processes using a particular module:
    In previous version of the kernel, we had a bit-mask value for this called dwInUse. In the new 6.0 kernel, we can now have more than 32 processes, so users can display the list of processes referencing a particular module in the debug output, by bringing a context menu when right-clicking on a particular module in the module window.
  • Adding a process space or VM context “specifier” for watched variables and breakpoints:
    The context “specifier” previously allowed function name, source file name and module name. It now allows an additional parameter, the process space name. In the watch window, a variable can be context-casted by pre-pending {[function],[source],[module],[process]}.
  • Low-level data breakpoints:
    This is not a full support of data breakpoints. It requires specific BSP support (by default in CEPC for example), they are set in raw virtual address, exposed through the advanced debugger command, and are globally set, without any kind of context affinity, even across processes.
  • Changing the default behavior of the debugger to not force paging-in VM pages while in break state by default:
    It means that, while in break state, the debugger will not try to get the system to page-in a virtual memory page if needed anymore. This is a safer, less intrusive behavior, which can occasionally limit the information available to the user for debugging. This can still be changed by the fvmp advanced debugger command as previously.