windows CE

Editor's Notes

• #6: Standard architecture slide deck.
• #24: Let us begin with an overview of the device debugger. The core debugger functionality will be present, and on par with existing device tools. For the most part, this will be very similar to the desktop debugger experience. Native code disassembly will be available for all supported CPUs. Attach will be supported for both Native and Managed, through the attach to process dialog. //In eVC, the process EXE was required for attach. //For Whidbey, only the executable images for the code of interest are needed, to provide rich debugging. //When the executable and dlls are unavailable, the debugging experience degrades similar to the desktop. Process detach is new to both Native and Managed in Whidbey. Just In Time Debugging is also available for Native code only. JIT debug is an installable feature per device, via an option in the IDE JIT works much like attach to process when an exception occurs on the device. Now let us discuss the unsupported functionality. Interop debugging allows logical transition between native and managed code in the same application and debug session. Providing this type of debugging is difficult, due to the complex interactions between the native debugger and the managed runtime. Due to scheduling constraints and the magnitude of the problem, we will not ship an interop device debugger in whidbey. Driver Development will require Platform Builder Special consideration must be given to driver development, due to the implementation on CE. Suspending the driver process on CE also stops services critical to connectivity. Data Breakpoints, due lack of hardware support on CE targets, will be unavailable. Most x86 CPUs have special debugger support to trap memory accesses. However, most CE supported embedded CPUs do not provide this support. The biggest difference you’ll see however is the stability and performance improvements. Order of magnitude performance in stepping. Already the fastest debugger to enter break-mode. [Less than 1 second between debug-launch to step into Main across the USB wire.] The perf goal is to average less than 0.5 per step. [Already achieved!] eVC averages about 3 ~ 5 seconds per step. eVC could take more than 13 seconds to step-in in some, common scenarios. Order of magnitude performance in expression evaluations. Drag-and-Drop and Expansion of any expressions in and onto any debugger windows are nearly instantaneous. The number of debugger windows open would not degrade stepping performance. [eVC + Native Desktop Debugger have this problem] The way we’ve achieved this is by re-architechting the native device debugger, including: 1>     Maximize desktop CPU processing power whenever possible and applicable. (e.g., call-stack enumeration is performed on the desktop-side) 2>     Minimize device CPU compute-bound tasks whenever possible and applicable. 3>     Redesigned the desktop-device debugger protocol to reduce unnecessary chatting ness. 5>     Implementing a sophisticated remote layer in our debug engine to cache thread-contexts and memory on-demand.
• #31: <number> © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. 07/20/14 03:13
• #35: <number> © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. 07/20/14 03:13
• #37: <number> © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. 07/20/14 03:13