Partager via

Just-in-Time Debugging

  • Article

Microsoft Windows CE .NET supports just-in-time (JIT) Debugging. The ability to debug crashed code, at the moment where the OS would typically terminate the relevant process, is known as just-in-time debugging. This feature is useful in situations where an OS developer is faced with a halted OS on a stand-alone Windows CE–based device. If the OS has been set up for JIT debugging beforehand, the developer can respond to the system crash by connecting the device to a development workstation running the IDE, and debug the kernel or any running application.

In past versions of Platform Builder, there was only one way to debug an OS. The kernel had to contain the static library Kernel Debugger Stub (KdStub) in order to work with the kernel debugger. KdStub would require that there be a connection to a development workstation running the IDE. If no connection existed, the system would not boot. In order to debug a Windows CE–based device, an OS developer would have to have KdStub in their image, and they would have to have the device constantly connected to the development workstation. These requirements made it difficult to debug relatively rare system errors.

In addition, if the device was connected to a development workstation, all exceptions passed immediately to the debugger. Because of this behavior, applications were unable to handle their own exceptions. Exceptions that might have been handled routinely by the application's exception handler would pass to the kernel debugger, and would be indistinguishable from more problematic exceptions.

These debugging complications have been eliminated with the current version of Platform Builder. KdStub no longer requires a connection to another development workstation in order to boot the OS, and applications are now given an opportunity to handle their exceptions.

Exceptions are now handled as follows:

  • When KdStub encounters an exception, it immediately checks to see if there is currently a KITL debugger connection to a development workstation running the IDE.
    • If a connection exists, then the kernel debugger receives the exception.
    • If no connection exists, then this first chance exception is passed back to the application that generated it. The application's exception handler is given a chance to handle this exception.
  • If the application does not handle the exception, a second-chance exception passes to KdStub. This is an opportunity for JIT Debugging. Once KdStub receives the second-chance exception, it checks again for a KITL connection to the host.
    • If a connection now exists, then the kernel debugger takes the exception.
    • If there is still no connection, KdStub waits for a KITL connection to be made. At this point, the user can set up a KITL connection between the Windows CE–based device and the host; once this connection is made, the target device can be debugged.

In this JIT debugging scenario, the OS of the Windows CE-based device will freeze, as it waits for a KITL connection to be made. No message will be sent to signify this freeze to a user; indeed, in some situations, there may not even be a user interface. The nature of this response has implications for how the OS developer will want to set up JIT debugging.

See Also

Platform and Application Debugging | JIT Debugging Setup

 Last updated on Friday, October 08, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.