Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
engextcpp and dbgeng debugger extensions
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?
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Internals & Software Drivers | 19-23 June 2023 | Live, Online |
| Writing WDF Drivers | 10-14 July 2023 | Live, Online |
| Kernel Debugging | 16-20 October 2023 | Live, Online |
| Developing Minifilters | 13-17 November 2023 | Live, Online |
Comments
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.
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