I just migrated my mastodon server to docker... so... anyone want to tell me if this is working?
| Blog | https://timdbg.com |
| Github | https://github.com/TimMisiak |
Tim Misiak
- 417 Followers
- 57 Following
- 91 Posts
Previously at Microsoft working on WinDbg and TTD.
I just published "Writing a debugger from scratch in Rust, part 8"! In this part DbgRs gains the ability to step through source code. Using symbols, we can map a code address to a source location and vice versa. That also gets us source-level breakpoints!
https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-8/
https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-8/
Writing a Debugger From Scratch - DbgRs Part 8 - Source and Symbols
(New to this series? Consider starting from part 1) At the end of the last post, DbgRs gained the ability to disassemble the code that it was debugging. While disassembly is critical for many debugging tasks, using source code to step through the code line by line is usually more convenient when it’s available. In this post we’ll start looking at how to use symbols (PDB files on Windows) so that we can display the source for the code that’s being debugged.
The Snippy assistant is just a demo of how to use CrabGrab, and I'd love to see other folks make a more fully feature assistant out of it. Contributions welcome on both Snippy and CrabGrab. Both repos are on GitHub.
You can use the CrabGrab crate with just a few lines of code to capture frames from a whole screen or individual applications. And it's cross-platform on macOS and Windows! There are a ton of gotchas with screen capture, and CrabGrab makes it easier.
New blog post! We just released a new Rust crate for cross-platform screen capture called CrabGrab, and the first thing we built was an AI assistant that can "see" your screen. Using Tauri, GPT-4, and CrabGrab we built Snippy!
Snippy: An AI Assistant With Eyes
While I no longer work on WinDbg, I still spend a lot of time thinking about how to make tools so people can build things faster. With WinDbg, I tried to do that by putting more debugging power at people’s fingertips in a way that was easier to use. Recently, everyone is looking for ways to use LLMs to build things faster. But for most people using something like ChatGPT means pasting text back and forth between your different tools.
New blog post about DbgRs, where I talk about adding a disassembler to the debugger! x86 instruction decoding is complex, but it's not as scary as you might think.
https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-7/
Writing a Debugger From Scratch - DbgRs Part 7 - Disassembly
(New to this series? Consider starting from part 1) At the end of the last post, DbgRs could display stacks, which is the single most powerful tool in the debugging arsenal. But once you have those frames to examine, you need to understand what that code was doing. Source code is one place to look at, but if you’re using a low level debugger like WinDbg or KD there’s a good chance you need to see the assembly code, which means we need a disassembler.
New blog post about DbgRs, where we finally get to stack walking! Want to understand how stack walking works in debuggers and profilers? This post explains how module unwind info is used to walk stacks and display a stack trace.
https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-6/
Writing a Debugger From Scratch - DbgRs Part 6 - Stacks
(New to this series? Consider starting from part 1) At the end of the last post, DbgRs could finally set breakpoints. That was the last really critical feature needed for controlling execution of a program. Now that it can stop on an arbitrary function or code location, the next step is to find more information about the state of the program. In my opinion, the single most useful piece of information is the call stack, so that’s what this post will be about.
New blog post up! This time we're adding breakpoints to DbgRs using debug registers.
https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-5/
Writing a Debugger From Scratch - DbgRs Part 5 - Breakpoints
(New to this series? Consider starting from part 1) At the end of the last post, we started to get some interesting functionality with the ability to resolve addresses to names in a module. This was the last functionality missing before we could implement breakpoints! This part adds the ability for DbgRs to set hardware breakpoints. The code for this post is in the part5 branch on github. You can also view the changes from part4.
New blog post up! Ever wondered how to get code running in another process? This post describes a few methods, and includes a sample that copies a function into a remote process address space.
Run My Code! (code injection on Windows)
The first time I realized it was possible to get a process to run some extra little code I had written, it felt like the ultimate cheat code. My first attempt was a little patch for Civilization 2 to fix some high CPU usage. Then I discovered that you could inject code at run-time. And when I discovered the ability to change how OS functions worked, it started to feel like I could do anything!
New episode of Stack Walk, where I talk with Andrew Richards about how Microsoft processes millions of crash dumps a day! Also: measuring solar flares with bit flips, a typo that led to a career, and the future of diagnostics!
