The blog “Snow White’s Poison Apple” describes how to test the most common suspend/resume hang. Other suspend/resume issues can be debugged over a “Passive KITL” connection. A standard KITL connection (a.k.a. “Active KITL”) gets dropped when a device suspends, however, Passive KITL doesn’t suffer from this problem.
To enable passive KITL on a device, build a KITL image but change OEMInit() so it calls KitlInit(FALSE). The FALSE parameter will tell the kernel to initialize the KITL structures without initializing the hardware. Since the hardware isn’t initialized, KITL won’t be affected when the suspend path powers off the hardware. Check out the CE6.0 documentation for more information about implementing KITL and enabling active or passive KITL.
Once passive KITL is enabled, a trigger is needed to activate KITL and break into the debugger when an issue occurs. The best way to do this is to modify the keyboard driver so that it calls DebugBreak() when a specific key is pressed. With the device configured and the trigger in place, a tester can suspend/resume the device repeatedly until the device hangs, then press the specific button and connect to the device in Platform Builder. From this point on, the hang can be debugged using Platform Builder’s debugging tool’s just like any other system hang.