Project Overview Page?

May 2, 2008 at 5:48 PM
Edited May 2, 2008 at 5:52 PM
Could there be a page a bit more like the following? (Something with structure and encouriging questions and answers?)

Project Description

ODbgExt is an open source debugger extension for WinDbg that is intended to be developed by the debugging community. It is based on the Windows Debugger SDK Sample ‘exts’ and uses the COM Debugger interface IDebugControl. The primary objective of the project is to provide the debugging community a central location to share their debugger extensions that help to isolate common problems in the community and make debugging both live systems and dumps easier. The initial release will be the basic framework that we expect other developers to contribute to. There will be very basic functionality in the initial version. We, GES (Global Escalation Services) intend on doing a series of blogs to talk about writing debugger extensions over the coming year. As we blog about writing extension we will include the code in ODbgExt (This project). This is the same group that runs the blog. We encourage you to sign up and contribute your debugger extension ideas and or code to the project. Simply create a codeplex account and request access.

Things we would like to include

  • A Graphical representation of Kernel, and User mode execution time by process and thread, while correlating to idle / non-idle time
  • A Graphical representation of idle time for kernel and user mode.
  • A Graphical representation of pool resources used on a per process bases along with handle table counts.
  • Hang detection, scanning for various conditions that could cause hangs in a system or user mode process.
  • Detailed system information such as oldest and newest binaries.
  • Binary info based on vendor name
  • A better dissembler that colorizes calls, jumps and indents to show code flow
  • Extensive use of DML (Debugger Mark-up Language) to enable more point and click debugging within windbg.
  • Support for a SQL Database backend to allow storing information about debugging sessions or binaries in a SQL Database.
  • Warnings when critical thresholds are exceeded such as handle counts over 10,000, Low PTE Conditions, etc.
  • Simplified searching for pool tags in binaries.
  • Support for VBA for Windbg
  • Dump annotation, via dump streaming; the ability to embed data into a dump via the debugger extension and later retrieve it. (Imagine embedded debug notes)
  • Embedding a snapshot of performance data in the dump at the time the dump is taken, ie. CPU, IO etc.

Questions About Project

  • How will the source be controlled?
    • How will "Developers" for the project be choosen?
    • Will there be a ticket based system for "Logged-In" people to add their code/suggestions or should it be done on the discussion board?
  • How will changes be handled?
    • Developers will add what they want, or by ticket system?
    • What additions are allowed? (Macros, Libraries, etc.?)
    • What is the scope of the project? Debugging, Reversing, Programming

Basically something to organize the flow?
Discuss what is a good idea in discussion (Allows repeat additions to be filtered and simple project modifications to be found easier)
Issue Tracker should only be used for source code issues?
May 2, 2008 at 6:02 PM
Edited May 2, 2008 at 6:06 PM
Great Idea, I'll spend some time answering these questions and expanding on this. I really want this to be very open ended. As long as we are benefiting debuggers in the community I'm happy to see code added to the project.

I think if we have major functionality to add we should add another module CPP file. This will reduce the amount of collations in revision control.

I'll work on refining these ideas over the next few days.