What WINDOWS CE debugging tools would you like to see?

Just an informal survey -- I use some of our tools all the time, some rarely.  I have my own nitpicks I'd like fixed and features I'd like to see added.  But there's no guarantee I see the world the way you do.  What are your opinions?

Here are some ideas of my own, to get the conversation started:

  • Remote regedit: Export/import data under a key.  Track and report changes under a key.
  • Remote performance monitor: More counters!
  • Kernel profiler: UI in the remote tools menu in addition to the on-device control we already have.
  • Remote kernel tracker... don't even get me started, I love this tool but have lots of features I want added.  What would YOU ask for?
  • Does anybody use Remote Heap Walker??
  • I'd say we need to add a memory visualization tool that shows you what parts of the VM space are used -- something like "mi full" from the target control window.
  • I also think we need to add a handle enumerator -- eg. to find out what file handles are open (and by whom), window handles, etc.

Tell me what you think is most important!  What's the #1 debugging tool you wish you had?  What's the #1 feature our existing tools are missing?

Comments (7)
  1. Anoymous says:


    Really, with the amount of 3rd-party device driver development I do, as well as the Microsoft-mandated "resolution" for the process limit of moving you applications into service DLLs, I think the need to attach to a process on the device for debugging is absolutely critical to ISV developers like myself who don’t have the ability to generate our own platforms.

  2. Have you tried the "File>>Connect Network Registry" in the current regedit? It won’t track and report changes but you should export /import remote keys.

    Certainly a tool that shows who has a file handle open would be useful (and even better if it has a choice to forcibly close the file). For finding who is locking a file I’m currently using Winternals’ Process Explorer and doing searches but a tool that shows the files directly would be better.

  3. two words. SoftIce and IDA. SoftIce so you guys can learn how to write a debugger independent of windows (ala windows crashes debugger still runs) and IDA so you guys can learn about interactive disassembly.

  4. Sue Loh says:

    I guess I should have specified, I’m most interested in hearing about tools FOR WINDOWS CE, and OTHER THAN the debugger. (Yeah, asking about "debugging tools" without clarifying was pretty stupid.)

    Though I’ll certainly pass CE debugger / tools comments on to our tools team. I can’t do much about comments about *desktop Windows*.


  5. Mike Dimmick says:

    I’ve used Remote Heap Walker a bit – it does help you find where your heap corruption bug is, if you keep refreshing it after stepping the code (if you overrun a heap block the CE 3.0 heap eventually goes crazy and starts giving you pointers to uncommitted virtual addresses, leading to a crash). Unfortunately it seems to need a thread in the process to be responsive, so you can’t refresh when currently stopped in the debugger.

    I’d like you to build PDBs as part of the SDK build process, so that third-party developers can have a chance of working out what the heck happened if there’s an unhandled exception in a system function. Trying to walk an ARM stack backwards is not fun.

    Don’t lock up the device if I accidentally try to step into a system function!

  6. I would like to have the following features when debuging applications in Windows CE:

    1. Something like NT’s TaskManager. We have developed two apps to achieve this, but there is a performance issue when getting the counters (as you could guess, we are making use of CreateToolHelp32Snapshot(), and the related APIs). Although it would be good to have a graphical app that shows the desired data, i’m talking about the kernel storing all these USEFULL data. This way, we could develop our custom "TaskManager" applications, that would talk with the kernel in order to get all those counters and values that are being stored by the kernel (so the performance issue to get the counters dissapears, because the kernel is doing that job periodically).

    2. Another feature I would LOVE to be added, is a new kernel mode where the crash of an application is dumped with all the data related to the crash. I mean, right now we get the following information regarding the exception caused:

    – ProcessName and ProcessId

    – ThreadId

    – AKY (Permission flags of the process)

    – PC : Virtual address being executed

    – Exception number

    The problem with the virtual address, is that it is only valid when the exception ocurrs within the code of your app (ie, if the parameters passed to a function call are invalid, the displayed address is unknown for the app programmer). So, as the PB’s debugger is able to show us the entire "Call stack" of an exception when the debugger is running; it would be very helpfull to get all that data WITHOUT having to be attached to the device with PB. In other words, when an exception occurs I would like to have the entire call-stack in the process (or in the different processes involved), and also the different values that had the parameters in those function calls.

    I don’t know if the features I’m asking for are dammed difficult to be developed. But I think they would be very helpfull in order to decrease the amount of time needed to develop applications (specially low level applications).

    Best regards,

    Roberto Bernardo

Comments are closed.

Skip to main content