4 ms·
windbg used to offer scripting capabilities that teams could use to trigger validation of any number of internal data structures essentially at every breakpoint
by coderatlarge 1y ago
windbg used to offer scripting capabilities that teams could use to trigger validation of any number of internal data structures essentially at every breakpoint or watchpoint trigger. it was a tremendous way to detect subtle state corruption. and sharing scripts across teams was also a way to share knowledge of a complex binary that was often not encoded in asserts or other aspects of the codebase.
- bpye 1y agoThis still exists? You can also use JavaScript to script/extend and there is a native code API too. Note: I do work at MSFT, I have used these capabilities but I’m not on the debugger team. https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/javascript-debugger-scripting https://learn.microsoft.com/en-us/windows-hardware/drivers/d... https://www.timdbg.com/posts/whats-the-target-model/ https://www.timdbg.com/posts/whats-the-target-model/ https://github.com/microsoft/WinDbg-Samples/tree/master https://github.com/microsoft/WinDbg-Samples/tree/master
- coderatlarge 1y agothanks for the pointers glad to hear it’s all still there i haven’t seen this type of capability used in too many companies tbh and it seems like a lot of opportunity to improve stability and debugging speed and even code exploration/learning (did i break something ?)
- delta_p_delta_x 1y agoWinDbg also has time-travel/record-replay debugging.
- coderatlarge 1y agothat sounds like a super-powerful feature especially for multithreaded debugging though i’ve never used anything like it.