Normal view

There are new articles available, click to refresh the page.
Before yesterdayTimDbg

Writing a Debugger From Scratch - DbgRs Part 7 - Disassembly

18 January 2024 at 16:10
(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.

Writing a Debugger From Scratch - DbgRs Part 6 - Stacks

22 November 2023 at 17:40
(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.

Writing a Debugger From Scratch - DbgRs Part 5 - Breakpoints

27 September 2023 at 05:28
(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.

Run My Code! (code injection on Windows)

27 August 2023 at 22:13
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!

Writing a Debugger From Scratch - DbgRs Part 4 - Exports and Private Symbols

29 May 2023 at 22:28
(New to this series? Consider starting from part 1) At the end of the last post, we had the ability to read memory out of the target process, but we still had very little in the way of interpreting the data in that process. That changes in this post, where we will start grabbing useful information out of the target, including modules, exports, and even private symbols. The code for this post is in the part4 branch on github.

Writing a Debugger From Scratch - DbgRs Part 3 - Reading Memory

28 March 2023 at 17:14
(New to this series? Consider starting from part 1) At the end of the last post, we had the ability to launch a program, step through instructions, and examine registers. We’re still not quite at the point that we can call this a “debugger” but we’re getting pretty close. In this part, we’re going to start implementing functionality to examine the memory of the target process. You can see the full code for this post in the part3 branch on github.

Writing a Debugger From Scratch - DbgRs Part 2 - Register State and Stepping

6 March 2023 at 16:44
When we left off last time, we had a basic “debugger” that could launch a Windows process and monitor events that occur in that process, but it’s not yet something that you would really call a debugger. Two things that are missing are the ability to examine the state of the process and to control its execution. So that’s what we’re going to build next. The code for this part is on GitHub as the part2 branch.

Writing a Debugger From Scratch - DbgRs Part 1 - Attaching to a Process

13 February 2023 at 16:20
I’ve left the Microsoft Debugger Platform team twice, and each time I’ve started writing my own debugger. I must really like debuggers or something. This time, I have two reasons for writing a new debugger. The first is because I want to learn Rust better, and writing something I already understand pretty well seems like a good way to learn. The second reason is to make it easier for people to learn how a debugger works.

Weird things I learned while writing an x86 emulator

2 February 2023 at 07:54
If you’ve read my first post about assembly language, you might expect that this is another post on how to understand assembly language. I will write more about that at some point, but this post is not that. Instead, this post is going to talk about some of the weird things and random trivia I learned while writing an x86 and amd64 emulator. The emulator I wrote was for Time Travel Debugging.

The faker's guide to reading (x86) assembly language

3 January 2023 at 16:20
Assembly code scares people. There’s a good reason for that. For many people, writing code in assembly language seems equivalent to writing code in ancient dwarven runes, or calculating pi in roman numerals. The fact that Roller Coast Tycoon was almost completely written in assembly language sounds almost too amazing to be true. Many programmers view assembly language as some combination of ancient, arcane, inscrutable, useless, and complex. Despite all that, I have a secret to share with you.

What's a vtable? What's an IUnknown?

18 December 2022 at 15:30
Understanding vtables (also called VMT/Virtual Method Tables or VFT/Virtual Function Tables) is important for understanding how many C++ features work on any OS. They are even more important to understand on Windows, where vtables are used for communication between modules using COM. There are a few types of errors that can happen when things go wrong with them, and some of these will be extremely difficult to diagnose unless you understand how vtables actually work.

Recognizing patterns in memory

24 November 2022 at 15:30
Something I find frustrating is how hard it is to teach debugging skills. I think the biggest reason is because there are many things that can only be learned through experience. This is true for anything that requires pattern recognition. Our brains are great at recognizing patterns, but it often takes a large amount of practice to be able to identify useful patterns in data. I can’t instantly give you pattern recognition skills with a short blog post, but I can tell you about some of the patterns that I look for so you can start to train your brain to see these as well.

What's the Target Model? (And Why?)

3 October 2022 at 16:54
How do you teach an old dog new tricks? That’s the topic of today’s post. “WinDbg” is short for “Windows Debugger”, but lately that name seems a bit odd since the WinDbg of today knows about a lot more than just Windows. WinDbg now supports Linux and MacOS crash dump targets, as well as few things that are a bit of a hybrid, like Open Enclave debugging. The core “debug engine” behind WinDbg is called “DbgEng”, and it’s been a Windows-centric debugging engine for decades.

Why you should do printf debugging

24 September 2022 at 19:20
If you know who I am, you might think that this post title is clickbait. Maybe it is, a little. But the truth is, you should do printf debugging! Sometimes. Often not. But sometimes, you should! Let me explain. When most of us first started programming, we had one tool at our disposal. It was “printf debugging”. Sometimes just littering the code with printf("here"), printf("here2"), and my favorite, printf("why won't this code work?

What's the Debugger Data Model? (And Why?)

31 August 2022 at 06:26
If you follow me on Twitter, you have probably heard me talk about the “Debugger Data Model”. But unless you’ve spent a bunch of time reading our documentation or you’ve read articles such as this one by Yarden Shafir about the Data Model, you might have no idea what I’m talking about. Many of the ways that WinDbg is evolving to be more powerful are through the Debugger Data Model, and understanding it will help you use WinDbg more effectively.

Debugger Lies: Stack Corruption

21 August 2022 at 16:57
There are lots of reasons your debugger might be lying to you. Sometimes it’s because information is lost when compiling due to optimizations. Sometimes the symbolic debug information isn’t expressive enough. Other times it can be due to a bug in the debugger (although I hope that reason is rare). One frustrating case where the debugger sometimes “lies” to you is the stack walk. It’s the single most important piece of information to come out of a crash, so when the stack walk is wrong, it’s probably going to make analysis difficult.

Symbol and Binary Indexing

10 August 2022 at 15:30
Symbol indexing is one of those features of WinDbg that can make things “just work” in a way that seems like magic. But it can also be the most painful things when it goes wrong. Why should I index symbols and binaries? Most of us have tried to debug without symbols at one point, and it can quickly become an exercise in frustration. It’s much more productive to debug an executable where you have symbols because it gives you function names, variable names, type definitions, and source files.

Remote debugging

5 August 2022 at 14:00
A key feature of WinDbg and NTSD is the ability to debug a target “remotely” from a separate computer. For kernel debugging, this is often the only way to debug, since the entire OS is “frozen” when broken into a kernel debugger. Remote debugging is also available for usermode debugging, and is often just as useful. Sometimes it’s useful because the target that you are testing on is different from the one you are using for development.

Remote Debugging

5 August 2022 at 07:52
A key feature of WinDbg and NTSD is the ability to debug a target “remotely” from a separate computer. For kernel debugging, this is often the only way to debug, since the entire OS is “frozen” when broken into a kernel debugger. Remote debugging is also available for usermode debugging, and is often just as useful. Sometimes it’s useful because the target that you are testing on is different from the one you are using for development.

My new blog

4 August 2022 at 18:15
Hi everyone! Since I started tweeting about WinDbg and debugging, I’ve been thinking about some longer things I want to write that don’t really fit on twitter. I’ve done a few of these as videos on my YouTube channel, but those are time consuming to make and most people don’t seem to watch the whole video. So I think a lot of what I want to talk about is probably best suited for a blog format.

/about/

1 January 2001 at 00:00
Tim Misiak I’ve been working on debuggers and diagnostics for most of my professional career as a software engineer. For more than a decade, I’ve been working on the Microsoft Debugger Platform team, working on tools such as WinDbg and KD. I started the WinDbgNext project in 2016 that modernized WinDbg UI. I also wrote a chunk of the X86/X64 emulator used by Time Travel Debugging. YouTube: Tim Misiak Twitter: @timmisiak GitHub: TimMisiak
❌
❌