Are there certain things that one should keep in mind before making a choice between engextcpp and dbgeng while developing debugger extensions?What advantages or disadvantage one has over the other?Can we still use wdbgexts interface with these?
Fortunately, you won’t suffer from lack of debug extension framework choices. In addition to the ones you’ve mentioned, there’s an even newer way to build extensions: write javascript. https://blogs.msdn.microsoft.com/windbg/2017/06/30/script-debugging-walkthrough/
Javascript isn’t as corny as it sounds – you actually have access to most of the debugger engine. You can write fairly sophisticated debugging tools in it. The advantage to Javascript over all the other frameworks is that you can edit/tweak the scripts on-the-fly as you are debugging something. It makes it a lot easier to build up a library of useful snippets.
That being said, the Javascript engine is still pretty new, so there are a few known gaps. And if you’ve already invested in a compiled debugger extension, it might not be worth it to convert it now.
The same dll can use wdbgexts and engextcpp, but (roughly speaking) the same function can’t call both. They’re not very interoperable. You should stay away from wdbgexts for new code – just keep it around for any existing code that you don’t want to refactor.
EngExtCpp is just a C++ wrapper around IDebugXxx interfaces. For the most part, you can mix and match EngExtCpp with IDebugXxx. The abstraction provided by EngExtCpp is pretty leaky, so it’s easy to reach through it and directly manipulate its internal IDebugXxx state when you want.
You *can* build a full-featured extension using only IDebugXxx. But EngExtCpp does handle some of the tedious boilerplate, so I’d suggest you use it when making a compiled DLL extension. Also, EngExtCpp uses some IDebugAdvanced calls that are not otherwise well documented (particularly the Typed Data interfaces, and “known structure” API). So if you want to be able to walk through expression trees like “Get the global variable foo!bar, dereference it, then access the field named ‘xxx’”, you’ll want to use EngExtCpp’s wrapper over IDebugAdvanced. (The alternative is to printf that expression into a string, then ask the masm or c++ expression evaluator to parse it, which is kind of fragile.)
FWIW, !ndiskd started out with EngExtCpp. At some point, I ended up forking EngExtCpp, because I wanted to meddle with its type system in a fairly fundamental way. At some point, I plan to start converting parts of ndiskd to javascript… but that could take a while.
engextcpp is a wrapper around dbgeng
so engextcpp just needs to declare EXT_DECLARE_GLOBALS
and simply use m_debugxxx->methods
whereas with dbgeng you need a boilerplate
create , query , call , release codes
dbgeng is powerfull raw access
engextcpp is easy access
with dbgeng you can write standalone executables without
the need for windbg like myfancydbg.exe
whereas engextcpp is tied to windbg
wdbgexts as is kinda deprecated
and is not recommended for use
though you can use it with dbgeng or engextcpp