\nA debugger is the tool that facilitates that. It's like turning an application into a fish bowl, giving you some sort of control over the fish as well:<\/p>\n
- \n
- Exploit developers<\/strong> tend to look at memory corruptions, look at the state of registers, memory contents and layouts. They search for certain instructions, gadgets, primitives and essentially build an exploit step by step, using the debugger as their companion.<\/li>\n
- Malware analysts<\/strong> may use a debugger to unpack malware, bypass anti-analysis tricks, dump content from memory, and so on.<\/li>\n
- Reverse engineers<\/strong> use debuggers to follow execution paths, understand logic, confirm static analysis hypotheses. It tells you what actually happens.<\/li>\n<\/ul>\n
(Of course, tools such as Ghidra<\/a>, IDA Pro<\/a> and Binary Ninja<\/a> play an important role in the world of malware analysis, reverse engineering and exploit development as well, but I'll stick to the debugger for now.)<\/p>\n
Debuggers are powerful utilities, because they allow us to see what is going on, they allow us to intervene, inspect registers, memory and execution state, and basically slow down the execution of an application all the way to a single-CPU-instruction-level. Once you have a debugger connected to an application, far fewer things remain invisible. There might still be obfuscation and anti-debugging or other things that can make your life difficult. But at least you're closer to seeing what happens under the hood.<\/p>\n
Unlike what some people believe, a debugger is not an application that is inserted between the CPU and the application, and it's not a proxy.
\nA debugger is typically a separate process that interacts with the OS debugging subsystem, which delivers debug events and allows the debugger to influence execution of the target process. <\/p>\nAn application runs because its threads are scheduled by the kernel to execute on the CPU.
\nUnder normal circumstances, execution proceeds uninterrupted. However, when certain events occur\u2014such as exceptions, breakpoints, or thread creation\u2014the kernel generates debug events.
\nIf a debugger is attached to the process, these events are delivered to the debugger instead of being handled immediately by the application. The debugger can then inspect the process state (registers, memory, stack) and decide how execution should continue.
\nIn this model, the debugger does not sit between the application and the CPU. Execution still happens natively on the processor. The debugger operates by reacting to events and controlling execution through the operating system.<\/p>\nA debugger gives you two core capabilities: visibility<\/strong> (seeing state) and control<\/strong> (influencing execution). Everything else builds on that.<\/p>\n
Anyway, the more fluent you become at operating a debugger, the closer you'll get to thinking in the language of the machine, and the easier (crash) analysis, debugging, vulnerability research and exploit development process will become.<\/p>\n
In today's post, I'm going to walk you through the basics of using Microsoft's free debugger: WinDBG (Classic) and WinDBGX. We're basically going to learn how the Debugger works<\/em> and how we can use it. We'll cover how to install and configure them and how to perform basic elementary tasks using a simple demo application. In later posts, we'll go over some more advanced features, basically learning how to make the Debugger work for us.<\/em><\/p>\n
Maybe you got here because you're preparing to take a Corelan class<\/a>. Or maybe you're here because you're just learning stuff on your own. Whatever it may be, welcome! We'll take this slowly, one step at a time.<\/p>\n
If you have any questions, feel free to join our Discord server<\/a> and reach out.<\/p>\n
Why WinDBG?<\/h2>\n
WinDBG(X)<\/a> is not the only debugger out there, and it's not necessarily the best one.
\nIts default GUI is rather \"basic\", and if you're new to the craft, you may end up fighting the debugger as well as the application\/memory corruption.
\nWinDbg is powerful, but it does have a learning curve, and out of the box it may not be the easiest debugger for beginners.<\/p>\nNevertheless, it does have a few interesting features that make the learning curve worth while:<\/p>\n
- \n
- It has extensions\/plugins that will assist with examining the Windows heap, amongst others.<\/li>\n
- It has powerful scripting and automation capabilities<\/li>\n
- It has the ability to open crash dump files<\/li>\n
- You can use it to debug the Windows Kernel as well as applications<\/li>\n
- It has native support for symbols. (I'll explain what symbols are in a moment).<\/li>\n
- Through its symbol support and availability of extensions, it provides insight in certain Windows internals.<\/li>\n
- WinDBGX, the newer version of WinDBG, has a neat feature called Time Travel Debugging (TTD), which records execution of an application and it allows you to step backwards in time. For complex bugs and root cause analysis, this can be pretty powerful.<\/li>\n<\/ul>\n
Symbols?<\/h3>\n
Symbols are generated during the build process (typically at link time). A symbol file (with extension
.pdb<\/mono>) contains human-readable elements from the source code, mapped to addresses and structures in the compiled binary. For example: function names, variable names, data types, and so on.
\nThere are 2 main types: 'Public' and 'Private' Symbols. Private symbols provide more details than public symbols (for instance, local variable names).
\nSymbols are not required to run the application, but it is very useful to have when you are debugging an application.<\/p>\nWhen you have the source code of an application, it makes sense to generate the corresponding symbols yourself. If WinDBG is able to locate the matching
.pdb<\/mono> file (for example, because it's found in the same folder, or it is retrieved via the symbol path configuration), it will automatically parse it, giving you names (of functions etc) as opposed to numbers\/addresses.
\nMicrosoft decided to release (public) symbols for some of its software, including the Operating System itself, Office Products, web browser, etc.
\n(And some other developers did the same - Mozilla, Chromium, etc).<\/p>\nIf you're a bit familiar with Visual Studio, you may have noticed already that a symbol .pdb file is created automatically for Visual C++ projects. You can find the debug information options in the project properties, under the \"Linker\" - \"Debugging\" settings. The default setting is \/DEBUG, but you can change it to \/DEBUG:FASTLINK and \/DEBUG:FULL. The latter will create full (or 'private') symbols.\n<\/p><\/blockquote>\n
Installing WinDBG Classic and WinDBGX<\/h2>\n
I'm going to use a Windows 11 Virtual Machine, but you can use Windows 10 as well.
\nWinDBG Classic has versions that work on older Windows versions as well, the newer WinDBGX debugger only runs on newer Windows versions. (Win10 and up).<\/p>\nWhy do we need both?<\/h3>\n
WinDBG Classic does not get updated automatically, WinDBGX is under active development.
\nThat's great, but I have noticed that some updates introduce features or change behaviour of existing commands.
\nSome of the commands I rely on in WinDBG Classic no longer work in WinDBGX. Likewise, there are features in WinDBGX that simply don't exist in Classic WinDBG.
\nThat's why I usually install and use both on my research virtual machines. I basically switch back and forth based on the task I'm trying to do. I know that WinDBG Classic will behave consistently (because it won't get updated mid-session)
\nAt the same time, it means it may have outdated logic.<\/p>\nLuckily, we can run both debuggers on the same machine. They're fundamentally different applications and don't overwrite one another. That said, I don't think it's a good idea to connect both of them to the same application at the same time.
\nIf you would like to have a debugger for certain tasks, and you want some other tool to monitor or trace things, then you may want to consider a instrumentation platform such as Frida<\/a>.
\nAnyway, I digress, maybe I'll talk a bit about Frida in another post.<\/p>\nlet's start by installing both WinDBG Classic and WinDBGX on our system.<\/p>\n
Scripted\/automated installation<\/h3>\n
Students that are taking one of the Corelan classes<\/a> are requested to bring a few Virtual Machines that contains some applications and configurations. In order to streamline the installation & configuration process, I decided to create a PowerShell script that will download and install most of the required components, including WinDBG Classic and WinDBGX. The script includes installers for other components as well, such as Python, Visual Studio Express Edition, etc.<\/p>\n
If you're a fan of automation and don't mind installing those other components as well (or if you are preparing for class), feel free to open our CorelanTraining repository on GitHub<\/a> and download CorelanWin11VMInstall.ps1<\/span> to your system.<\/p>\n
Next, open a PowerShell Terminal, with administrator privileges:<\/p>\n
- \n
- Click on the \u201cStart\u201d icon, start typing powershell<\/span>. The \u201cBest match\u201d section should show \u201cWindows PowerShell\u201d.<\/li>\n
- Right click \u201cWindows PowerShell\u201d and choose \u201cRun as administrator\u201d<\/li>\n<\/ul>\n
![\"PowerShell\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/PowerShell.png\" "\\"PowerShell.png\\"")
<\/p>\nIn the administrator PowerShell Terminal, first run the following statement to allow the downloaded PowerShell script to execute:<\/p>\n
Set-ExecutionPolicy RemoteSigned<\/cmd><\/pre>\n (if that doesn't work, you may have to open it even further)<\/p>\n
Set-ExecutionPolicy Unrestricted<\/cmd><\/pre>\n Next, just to be sure, verify that your VM has a working internet connection.
\nAlso, please make sure your laptop is connected to a power supply, and is not installing Windows updates or any other software installers at this point.<\/p>\nIn the administrator PowerShell Terminal, navigate to the folder that contains the downloaded PowerShell script, run the script and lean back:<\/p>\n
.\\CorelanWin11VMInstall.ps1<\/cmd><\/pre>\n The script will download and run various installers (including WinDBG Classic and WinDBGX). The last application in the list will be Visual Studio Express Edition. This step requires a bit of manual user interaction (such as clicking \u201cContinue\u201d and \u201cInstall\u201d). The Visual Studio Express Edition installer will download a few Gigabytes of components, so please be patient.<\/p>\n
![\"corelanvminstall\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/corelanvminstall.png\" "\\"corelanvminstall.png\\"")
<\/p>\nFinally, check the output of the CorelanWin11VMInstall.ps1<\/span> script for errors and, after verifying that everything looks ok, reboot your VM.
\nWait for Windows updates to install (if needed).<\/p>\nYou're all set, you can continue with \"Verify if both versions work\"<\/p>\n
Of course, if you prefer to just install WinDBG Classic and WinDBGX by hand, following the steps below:<\/p>\n
Manual Installation<\/h3>\n
Classic WinDBG<\/h4>\n
- \n
- Download the Windows 10 SDK from https:\/\/developer.microsoft.com\/windows\/downloads\/windows-10-sdk<\/a>. (version 10.0.183621 is known to work well)<\/li>\n
- Launch the installer with administrator privileges (right-click on the file and choose \u2018Run as administrator\u2019)<\/li>\n
- During installation, only select \u201cDebugging tools for Windows\u201d. Deselect the other options<\/li>\n
- Install in the default path. (C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\...)<\/span><\/li>\n<\/ol>\n
WinDBGX<\/h4>\n
- \n
- Open a PowerShell terminal with administrator privileges<\/li>\n
- Run the following command<\/li>\n<\/ol>\n
winget install Microsoft.WinDbg --silent --accept-package-agreements<\/cmd><\/pre>\n Once installed, you can check for updates via the following command:<\/p>\n
winget upgrade Microsoft.WinDbg<\/cmd><\/pre>\n Microsoft Symbol Server<\/h3>\n
Since we're working on Windows, we'll go ahead and already configure our system to connect to Microsoft's Symbol Server, which contains the .pdb files for Operating System components, Office Products, etc.<\/p>\n
There are a few ways to configure WinDBG(X) to connect to the right server, but I prefer to use the following system-wide configuration.
\nFrom an administrator command prompt, run the following command:<\/p>\nsetx \/m _NT_SYMBOL_PATH \"srv*c:\\symbols*https:\/\/msdl.microsoft.com\/download\/symbols\"<\/cmd>\n<\/pre>\n This will create a Systemwide environment variable _NT_SYMBOL_PATH<\/span>
\nIts value is then set to \"srv*c:\\symbols*https:\/\/msdl.microsoft.com\/download\/symbols\"<\/span>.
\nWinDBG(X) and other applications that rely on the same system environment variable, will now connect to Microsofts Symbol Server, and download relevant .pdb files to folders inside c:\\symbols<\/span>.
\n(Of course, feel free to change the local folder\/ path as you wish. WinDBG(X) will create the folder if needed).<\/p>\nFrom this point forward, make sure your machine has an active internet connection, as that is required to download symbols from Microsoft's Symbol Server.<\/p>\n
Verify if both versions work<\/h3>\n
Open an administrator command prompt and navigate to the folder that contains the WinDBG Classic installation:<\/p>\n
\n
c:<\/cmd>\n cd \"C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\"<\/cmd>\n<\/pre>\n Inside that folder, you'll find a bunch of folders, including some folders that correspond with the 4 architectures that are supported by WinDBG Classic: x86, x64, arm and arm64
\nLet's run the version for 32-bit. Enter the x86 folder and run the windbg.exe in that folder<\/p>\n\nC:\\Program Files (x86)\\Windows Kits\\10\\Debuggers>
cd x86<\/cmd>\nC:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x86> windbg.exe<\/cmd>\n<\/pre>\n I'll refer to this folder as the \"WinDBG Program Folder\" from this point forward.<\/p><\/blockquote>\n
If all goes well, you should see something like this:<\/p>\n
![\"WinDBG](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/WinDBG-Classic.png\" "\\"WinDBG")
<\/p>\nGreat! The GUI itself feels a bit \"empty\", but at least WinDBG is running.<\/p>\n
Please take note of the fact that WinDBG Classic has a separate executable for each architecture. Make sure to run the binary that matches with the architecture of the application you're going to work with<\/p>\n<\/blockquote>\n
Close WinDBG.<\/p>\n
From the same command prompt, run windbgx.exe<\/span> (just add an 'x' after 'windbg').<\/p>\n
\nC:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x86>
windbgx.exe<\/cmd>\n<\/pre>\n Although WinDBGX is installed inside its own folder structures, you can actually launch it from any location. If WinDBGX was installed correctly, you'll see something like this:<\/p>\n
![\"WinDBGX\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/WinDBGX.png\" "\\"WinDBGX.png\\"")
<\/p>\nWe see that the GUI has a bigger ribbon bar and 3 panels. But it's all still very empty.<\/p>\n
Anyway, we now know how to launch WinDBG Classic and WinDBGX.
\nThat's great, but they won't do much just running by themselves.
\nThey're designed to operate, attached to another process.
\nLet's see what that looks like next.<\/p>\nConnecting to a process<\/h2>\n
There are a few ways to have a debugger connect itself to another process. The 2 most important techniques are:<\/p>\n
- \n
- 'Opening'<\/strong> or 'launching'<\/strong> an executable. The debugger will then create that application, and it will be connected to it from the start, leaving it paused before it executes application logic.<\/li>\n
- 'Attaching'<\/strong> to an already running process. In this case, it will \"intervene\" and pause the application, regardless of where it was\/is.<\/li>\n<\/ol>\n
Both can be done from within the debugger, as well as from the command line.<\/p>\n
What is the difference between these 2 techniques, which one should you use, and how do we \"open\" and \"attach\" in WinDBG(X)?<\/p>\n
Open executable vs Attach<\/h3>\n
Both techniques ('opening\/launching' or 'attaching') ultimately rely on the use of the Windows debugging subsystem. A debugged process has a debug object associated with it. The process' Kernel structure EPROCESS<\/span> includes a DebugPort<\/span>, which points to a DebugObject<\/span>, etc. If non-null, it means the process is actively being debugged.
\n(Check out the Vergilius Project<\/a> website for more information about this kind of Kernel Structures - f.i. this Windows 11 version of EPROCESS<\/a>)
\nThe Kernel has a few routines that are accessible via System calls:
\nNtCreateDebugObject, NtDebugActiveProcess, NtWaitForDebugEvent, NtDebugContinue<\/span>
\nThe Userland side of the Operating System has wrappers functions to use them. <\/p>\nIf all of this is too much detail for you at this time, don't worry. You don't need to remember all of this to use the debugger. It's just here FYI.<\/p><\/blockquote>\n
Nevertheless, there are still differences between 'opening' and executable and 'attaching' to a process, related with: <\/p>\n
- \n
- The \"initial break\" - the place\/moment during the execution of the application when the debugger is \"attached\" to the process, and takes control<\/li>\n
- The effect to \"Debug Flags\"<\/li>\n<\/ol>\n
Lets have a quick look at what these difference are:<\/p>\n
Initial break:<\/h4>\n
Opening\/Launching<\/h5>\n
When 'opening\/launching'<\/strong> an executable, the process will be created from the start, with the debugger attached to it. You're technically able to see everything from process creation, the initialization routines, TLS Callbacks, etc.
\nThe process will be created with a special flag DEBUG_ONLY_THIS_PROCESS<\/span>, telling the kernel to route all debug events to the debugger. I.e. the debugger has control right away. The debugger now enters a loop involving WaitForDebugEvent()<\/span> and ContinueDebugEvent()<\/span>
\nThe process will be paused at the so-called \"initial breakpoint\", which is triggered by the Windows Loader routines.<\/p>\nAttaching<\/h5>\n
When \"attaching\"<\/strong>, the debugger needs to connect itself to a process that already exists. Technically, there is an invasive<\/strong> and non-invasive<\/strong> way for a debugger to attach itself. By default, debuggers use the \"invasive\" method. It means that it uses DebugActiveProcess(pid)<\/span>, which is a routine that will call the NtDebugActiveProcess<\/span> system call to: <\/p>\n
- \n
- Associate the debugger with the debug port of that process<\/li>\n
- Suspend all threads in the process<\/li>\n
- Some synthetic debug events (simulating the events that the debugger would have received if it was attached from the start, so it can catch up with the environment)<\/li>\n
- Finally, cause a break-in exception, so the debugger has control.<\/li>\n<\/ul>\n
With an invasive attach, the debugger gets full debugging control, allowing you to: <\/p>\n
- \n
- set breakpoints (INT3)<\/li>\n
- single-step execution<\/li>\n
- receive exceptions<\/li>\n
- suspend\/resume threads<\/li>\n
- modify registers<\/li>\n
- control execution flow<\/li>\n<\/ul>\n
The
DebugActiveProcess()<\/mono> technique involves creating a new thread inside the process, thus technically modifying it, and running code inside the process that performs the steps listed above. If you let the process continue running (after it paused initially), you'll see that it \"begins\" by exiting\/cleaning up the thread that it used to \"attach\" itself. In other words, don't freak out if you see that a thread gets terminated. You didn't break anything, it's just cleaning up itself.
\nWhen attaching to a process, the \"initial break\" happens wherever the program currently is the moment of attach.<\/p>\nAttaching: invasive vs non-invasive<\/h5>\n
An invasive attach<\/strong> means that the debugger will become the process's official debugger in the Windows debugging subsystem. Windows only allows one debugger to own the DebugPort of the process.<\/p>\n
A non-invasive attach<\/strong> means the debugger does not register itself as the process debugger. Instead of using DebugActiveProcess()<\/span>, it uses OpenProcess()<\/span> - just like other tools would do when it wants to connect to a process and look\/analyse things. You can watch, but you cannot set breakpoints, perform single-step execution, intercept exceptions or control execution. Because it's not really acting as a \"debugger\", but more as a \"spectator\", it's not often used. In fact, not all debuggers support the non-invasive attach to begin with.<\/p>\n
Debug Flags<\/h4>\n
Opening\/Launching<\/h5>\n
When you open\/launch an executable in the debugger, the debugger will automatically (and without telling you) activate a certain flag, a value that is part of a broader set of 'Global flags' (NTGlobalFlag<\/span>) that, amongst others, affect how the Windows heap manager operates.
\nWhen the Debugger does this, it basically updates a field in the Process Environment Block (PEB). <\/p>\nTechnically, you could also set GlobalFlags up front by creating a GlobalFlag key with a value that corresponds with the flag(s) that you wish to activate.
\nLet's say you're working with an application called corelanapp1.exe<\/span>, then you'd have to set the following key:<\/p>\n\nHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\corelanapp1.exe\\GlobalFlag\n<\/pre>\n
That registry will affect any new instance of the corelanapp1.exe process, regardless of whether you're opening it in the debugger or running it outside a debugger. The key persists across reboots, so be careful when you make this type of changes.<\/p>\n
Anyway, when you open an executable in WinDBG Classic, it activates the following 3 flags:<\/p>\n
- \n
- FLG_HEAP_ENABLE_TAIL_CHECK (0x10)<\/span><\/li>\n
- FLG_HEAP_ENABLE_FREE_CHECK (0x20)<\/span><\/li>\n
- FLG_HEAP_VALIDATE_PARAMETERS (0x40)<\/span><\/li>\n<\/ul>\n
The values get summed up, so if the GlobalFlag indicates 0x70, it means those 3 options are active.
\nSome popular GlobalFlag options include:<\/p>\n\nFlag\t\t\t\t\t\t\t\tValue\t\tDescription\nFLG_HEAP_ENABLE_TAIL_CHECK\t\t\t0x10\t\tDetect overwrite past allocation\nFLG_HEAP_ENABLE_FREE_CHECK\t\t\t0x20\t\tDetect use-after-free\nFLG_HEAP_VALIDATE_PARAMETERS\t\t0x40\t\tValidate heap calls\nFLG_HEAP_VALIDATE_ALL\t\t\t\t0x80\t\tAggressive heap validation\nFLG_APPLICATION_VERIFIER\t\t\t0x100\t\tEnables AppVerifier\nFLG_HEAP_PAGE_ALLOCS\t\t\t\t0x02000000\tFull page heap\n<\/pre>\n
Note: WinDBG doesn't create the registry key, it just updates the NtGlobalFlag field in the PEB directly.<\/p><\/blockquote>\n
'Opening' an executable in a debugger also activates certain flags in the PEB that make it obvious that the process runs with a debugger attached to it.
\nBoth features (heap and debug flags) may affect your debugging session:<\/p>\n- \n
- It would be trivial for anti-debugging logic to detect that the application is being debugged.<\/li>\n
- Furthermore, key core features in the heap will behave differently, changing sizes, layouts, relative distances etc. You're essentially running in an environment that does not resemble reality, and you may end up building an exploit that is based on behaviour and calculations made in a 'debugging' context.<\/li>\n
- Even if all of that doesn't play a role for your exploit, the application developer may have taken the decision to take a different code path when it detects it is being debugged. For instance, it may print out debug information, and the fact that it runs additional or different code, may have an impact on when\/where\/how the application processes your input. <\/li>\n<\/ul>\n
Long story short, running an executable in a debugger is not the same thing as running it outside a debugger.<\/p>\n
We'll look at an example in a moment, and I'll also explain how to overrule this default behaviour at that time. Let's look at the effect of \"attaching\" first.<\/p>\n
Attaching<\/h5>\n
When attaching to a process, the process will use whatever Global Flags were present already (none by default). In other words, the application will behave just like it would without a debugger, because there was no debugger present at process creation.
\nFrom an anti-debugging perspective, the fact that some obvious flags won't be present, doesn't mean the application won't be able to detect that it is being debugged. There are many anti-debugging and anti-anti-debugging techniques, but I rarely see those being used in commercial 'productivity' software. In my personal experience, these techniques are more frequently found present in malware and games. <\/p>\nConnecting to a process: exercises<\/h3>\n
Let's do a few exercises to practice connecting a debugger to a process, either by opening it or by attaching.<\/p>\n
Go to https:\/\/github.com\/corelan\/blogposts<\/a>, open the \"debugging\" folder, then open the \"corelanapp1\" folder and download the corelanapp1.exe binary from inside the \"Release\" folder.
\nYou can access the .exe file directly here<\/a>
\nFrom the same folder, please download the corelanapp1.pdb<\/span> file and store it next to the .exe file.<\/p>\nWhen running the application outside of a debugger, you'll see something like this:<\/p>\n
\nWelcome to CorelanApp1!\nwww.corelan.be\nAlloc 1 : 0x00F6DE20\nAlloc 2 : 0x00F72E28\nThe distance from Alloc 1 to Alloc 2 is 0x5008 bytes\n<\/pre>\n
The application will pause, waiting for you to press return, and then terminate.
\nThe values printed after 'Alloc 1' and 'Alloc 2' may be different, that's ok. Under normal circumstances (and unless the Heap manager had to take a different decision), the distance between Alloc 1 and Alloc 2 will be 0x5008 bytes. Remember that number.<\/p>\nLet's see if we can connect WinDBG and WinDBGX to this sample application, by \"opening\" and \"attaching\", both through the GUI and the command line.<\/p>\n
WinDBG Classic, 'Open executable'<\/h4>\n
Open an administrator command prompt and launch windbg classic from within the WinDBG Program Folder:<\/p>\n
\nMicrosoft Windows [Version 10.0.26200.7623]\n(c) Microsoft Corporation. All rights reserved.\n\nC:\\Windows\\System32>
cd \"C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x86\"<\/cmd>\nC:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x86> windbg.exe<\/cmd>\n<\/pre>\n From the menu, choose 'File' and then click 'Open Executable'. <\/p>\n
Navigate to the folder that contains the corelanapp1.exe<\/span> binary:<\/p>\n
![\"Open](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbgclassic-openexecutable.png\" "\\"windbgclassic-openexecutable.png\\"")
<\/p>\nIf the application would require command line argument(s), you can enter them in the \"Arguments\" field. (Not needed in this case).
\nClick 'Open' to start the debugging session.
\nThe process gets created, the WinDBG \"Command\" window appears and shows some text output<\/p>\n![\"WinDBG](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-openexecutable-started.png\" "\\"windbg-openexecutable-started.png\\"")
<\/p>\nIt is showing what modules (.exe and .dll) were loaded, it shows the state of registers, and it finally shows this:<\/p>\n
\n(13a8.5f4): Break instruction exception - code 80000003 (first chance)\neax=00000000 ebx=00000000 ecx=e02a0000 edx=00000000 esi=00e22d28 edi=00be8000\neip=77bf80c8 esp=00cff66c ebp=00cff698 iopl=0 nv up ei pl zr na pe nc\ncs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246\nntdll!LdrpDoDebuggerBreak+0x2b:\n77bf80c8 cc int 3\n<\/pre>\n
Right below the \"Command window\", we can see an input field. This is WinDBG's Command line. It is enabled (i.e. we can enter text), which indicates that the process exists, the debugger is attached to it, but the application is not in an active running state. The debugger is now waiting for our input to do something.<\/p>\n
![\"windbg](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-command-line.png\" "\\"windbg")
<\/p>\nIn other words, when we open an executable in a debugger, it creates the process but - by default - it will end up in a paused state.
\nNone of the application code has run at this point. We're right at the end of the OS logic that creates the process, but before any of the application logic itself has executed. <\/p>\nWe can now issue WinDBG commands, for instance to allow the process to continue running.
\nThe command g<\/span> (or shortkey F5<\/span>) will do that.<\/p>\n![\"windbg-running\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-running.png\" "\\"windbg-running.png\\"")
<\/p>\nThe command line indicates \"Busy\" and \"Debuggee is running...\" and we can no longer type commands. If we open the Window for corelanapp1.exe, we can see that it has executed code and is now waiting for a key press before it terminates.<\/p>\n
For example:<\/p>\n
\nWelcome to CorelanApp1!\nwww.corelan.be\nAlloc 1 : 0x00C3D000\nAlloc 2 : 0x00C42018\nThe distance from Alloc 1 to Alloc 2 is 0x5018 bytes\n<\/pre>\n
Note that the distance from Alloc 1 to Alloc 2 is now 0x5018 bytes instead of 0x5008. When we ran the application outside the debugger, it was showing a distance of 0x5008 bytes.
\nThis is one of the effects of the NtGlobalFlags. The relative position of the heap allocations is different now. If you wouldn't be aware of this, you might be building an exploit that is based on calculations made in a modified context.<\/p><\/blockquote>\nJust like most command line statements, the \"g\" (F5) command works the same in both WinDBG Classic and WinDBGX<\/p>\n
We can \"break\" the process (basically pause the application regardless of where it is) and give control back to the debugger by opening the \"Debug\" menu and choosing \"Break\".
\nIf you happen to have a \"Break\" button on your keyboard, you can also press the CTRL+Break combination.<\/p>\n![\"windbg-break\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-break.png\" "\\"windbg-break.png\\"")
<\/p>\nLast but not least, we can also click the tiny little \"pause\" button in the toolbar:<\/p>\n
![\"windbg-pause\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-pause.png\" "\\"windbg-pause.png\\"")
<\/p>\nRegardless of the method you decided to use, it will trigger a \"break\" instruction, the process will pause and you'll be able to issue WinDBG command line statements again.<\/p>\n
\n(13a8.2370): Break instruction exception - code 80000003 (first chance)\neax=00a02000 ebx=00000000 ecx=77badcb0 edx=77badcb0 esi=77badcb0 edi=77badcb0\neip=77b5b400 esp=0113f964 ebp=0113f990 iopl=0 nv up ei pl zr na pe nc\ncs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246\nntdll!DbgBreakPoint:\n77b5b400 cc int 3\n<\/pre>\n
We can now invoke an extension that shows the NTGlobalFlag value for the current process. Running a plugin\/extension requires an exclamation point followed by the extension name, in this case !gflag<\/span>:<\/p>\n
\n0:001>
!gflag<\/cmd>\nCurrent NtGlobalFlag contents: 0x00000070\n htc - Enable heap tail checking\n hfc - Enable heap free checking\n hpc - Enable heap parameter checking\n<\/pre>\n This confirms that some GlobalFlags have been activated. Not by us, but by the debugger.
\nAs explained earlier, these flags are stored in the PEB. We have 2 ways to query the PEB for a process, either by using the !peb<\/span> extension, or by asking WinDBG to dump the contents of memory at the location of the PEB and organizing the bytes based on its understanding of the PEB datastructure.<\/p>\nHere we can see the !peb extension at work. I truncated the output, but you should be able to see the contents of the NtGlobalFlag field:<\/p>\n
\n0:001>
!peb<\/cmd>\nPEB at 00be8000\n InheritedAddressSpace: No\n ReadImageFileExecOptions: No\n BeingDebugged: Yes\n ImageBaseAddress: 00750000\n NtGlobalFlag: 70<\/high>\n NtGlobalFlag2: 0\n Ldr 77c17340\n Ldr.Initialized: Yes\n Ldr.InInitializationOrderModuleList: 00e244e8 . 00e37b28\n Ldr.InLoadOrderModuleList: 00e245f0 . 00e37b18\n Ldr.InMemoryOrderModuleList: 00e245f8 . 00e37b20\n...\n<\/pre>\n We can also perform a typed dump (dt) of the PEB using the following command:<\/p>\n
\n
dt nt!_PEB @$peb<\/cmd>\n<\/pre>\n (The output will show that the NtGlobalFlag field sits at offset +0x68)<\/p>\n
If we're only interested in one specific field (for instance, the NtGlobalFlag), we can get its contents right away using the following command:<\/p>\n
\n0:001>
dt nt!_PEB @$peb NtGlobalFlag<\/cmd>\nntdll!_PEB\n +0x068 NtGlobalFlag : 0x70\n<\/pre>\n Finally, to terminate the WinDBG session (which will also terminate the process it is attached to), use the \"q\" command and press return.
\nThe \"Command\" window will close, WinDBG itself will continue running. I do recommend closing it as well in between debugging sessions, as it may be caching some extension related stuff.<\/p>\nWe can automate creating a process in WinDBG Classic from the command line as well. WindBG takes a bunch of command line options, one of which is the full path to the executable you'd wish to \"open\" in the debugger. You can also specify some command line flags to modify windbg behaviour, as well as command lines arguments to the binary you're trying to run.
\nThe basic syntax is<\/p>\n\n
windbg.exe [windbg args] path\/to\/application.exe [app arguments]<\/cmd>\n<\/pre>\n Let's keep this simple for now, we'll simply run windbg.exe, followed by the path to the corelanapp1 binary.
\nOn my system, the corelanapp1.exe is stored under g:\\blogposts\\debugging\\corelanapp1\\Release<\/span>,
\nOpen an administrator command prompt, go to the folder that contains windbg.exe and run the following command <\/p>\nwindbg.exe g:\\blogposts\\debugging\\corelanapp1\\Release\\corelanapp1.exe<\/cmd>\n<\/pre>\n This will open WinDBG and then open the executable as if you have selected it from the \"File\" - \"Open executable\" menu option yourself.
\nThe process is paused and you can now type commands at the WinDBG Command Line. For instance, if you run !gflag<\/span>, you'll see that the 3 NTGlobalFlags have been activated again.
\nYou can execute \"g\" to let the process run, you can execute \"q\" to make it stop.<\/p>\nWhat if you don't want the NtGlobalFlag to be set? There is a WinDBG command line flag -hd<\/span> that allows you to overrule this behaviour, but it only works if you run windbg.exe from the command line and specify the application to run as well.
\nRunning windbg.exe -hd<\/span> without specifying the application .exe and then selecting it yourself from \"File\" - \"Open executable\" won't actually turn off the NTGlobalFlags.<\/p>\nSo, the correct syntax on my system would be<\/p>\n
\n
windbg.exe -hd g:\\blogposts\\debugging\\corelanapp1\\Release\\corelanapp1.exe<\/cmd>\n<\/pre>\n The output of !gflag will now indicate that none of the flags were activated:<\/p>\n
\n0:000>
!gflag<\/cmd>\nCurrent NtGlobalFlag contents: 0x00000000\n<\/pre>\n WinDBGX, 'Launch executable'<\/h4>\n
With WinDBGX, Microsoft has made substantial changes to the end-user experience. The GUI now features a larger ribbon bar with easy-to-use buttons. The menu layout has changed as well.
\nTo open an executable in WinDBGX (or to start a debugging session in general), we can simply click \"File\". WinDBGX will automatically open the \"Start debugging\" submenu. <\/p>\n![\"windbgx-start\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbgx-start.png\" "\\"windbgx-start.png\\"")
<\/p>\nFrom the \"Start debugging\" submenu, we can now choose \"Launch executable\" or \"Launch executable (advanced)\". With the former, you simply select the executable. With the latter, you get the option to specify command line arguments to the executable you're trying to launch.<\/p>\n
For the sake of this exercise, feel free to try both options. Select the corelanapp1.exe file and click \"debug\" to start the process with the debugger attached to it.<\/p>\n
![\"windbgx-startproc\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbgx-startproc.png\" "\\"windbgx-startproc.png\\"")
<\/p>\nAlthough the GUI is slightly different, the basic principles still apply. The process is created but is paused, the Command window shows output, and we get the opportunity to issue commands using the WinDBGX Command Line input box. Similarly to WinDBG Classic, we can now type \"g\" and press return, or use F5 to let the process continue running.<\/p>\n
Interrupting (breaking) a running process can be done by clicking the larger \"Break\" (pause) button at the left hand side of the \"Home\" tab of the ribbon. <\/p>\n
Unlike WindBG Classic, WinDBGX only activates one NTGlobalFlag:<\/p>\n
\n0:003>
!gflag<\/cmd>\nCurrent NtGlobalFlag contents: 0x00000010\nCurrent NtGlobalFlag2 contents: 0x00000000\n htc - Enable heap tail checking\n<\/pre>\n We can launch the executable from the command line as well. The -hd flag serves its purpose as well, it allows us to overrule the debuggers default behaviour related with activating NTGlobalFlags.<\/p>\n
\n
windbgx.exe -hd g:\\blogposts\\debugging\\corelanapp1\\Release\\corelanapp1.exe<\/cmd>\n<\/pre>\n WinDBG Classic, 'Attach'<\/h4>\n
I usually recommend my students to attach to an already running process (unless you won't get the chance to attach to it without triggering a vulnerability).
\nThis avoids having to consider NTGlobalFlags, and any initial anti-debugging checks may have passed already before your debugger is \"invading\" the process and attaching itself to it.<\/p>\nWe can \"attach\" using the GUI, or using the command line (by either providing the process ID or the prooces name if there is only one process with the same name).<\/p>\n
Attaching using the GUI works as follows:<\/p>\n
- \n
- Start the application you'd like to debug<\/li>\n
- Launch WinDBG<\/li>\n
- Click \"File\" - \"Attach to a process\" or use F6<\/li>\n
- WinDBG will show a list of processes, sorted in the order that they were created. (Old to new). This default sort order may be a bit annoying, because you're quit likely going to attach to one of the last processes that was created, which means you'll have to scroll down almost every time)<\/li>\n
- Select the process you would like to debug. Note: WinDBG provides the ability to perform a non-invasive attach.<\/li>\n<\/ol>\n
![\"windbg-processes\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-processes.png\" "\\"windbg-processes.png\\"")
<\/p>\nClick \"OK\" to start the debugging session.
\nThe Command window now appears, and the process will be paused. The debugger has created a new thread in the process and told it to run the required code for the debugger to be connected to the process, pause all the threads, and give the debugger control.
\nAfter attaching to a process, it will be paused (wherever it was executing code from).
\nFrom this point forward, everything works exactly the same as if you had opened the executable in the debugger. Of course, there won't be NtGlobalFlags set by the debugger, but you can now interact with the process in the same way. You can let the process continue running with g<\/span>or F5. You can break, you can look at memory contents, and so on.<\/p>\nAttaching to an already running process from the command line requires a bit of interaction first. You'll have to either find the PID (process ID) of the process you'd like to attach to. If there is only one instance of the application running, then you may be able to attach to it using its process name as well.
\nLet's say I launched corelanapp1.exe already, and there's only one instance of an application running with that image name (corelanapp1.exe). I can use something like tasklist to get the PID:<\/p>\n\n
tasklist \/FI \"IMAGENAME eq corelanapp1.exe\"<\/cmd>\n\nImage Name PID Session Name Session# Mem Usage\n========================= ======== ================ =========== ============\ncorelanapp1.exe 11016 Console 1 5.132 K\n<\/pre>\n And then I can attach WinDBG to it using the reported PID:<\/p>\n
\nC:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x86>
windbg.exe -p 11016<\/cmd>\n<\/pre>\n Or, if there is only one process running with that image name, I can tell WinDBG to connect to it:
\nFirst, let's confirm there is only one:<\/p>\n\n
tasklist \/FI \"IMAGENAME eq corelanapp1.exe\"<\/cmd>\n\nImage Name PID Session Name Session# Mem Usage\n========================= ======== ================ =========== ============\ncorelanapp1.exe 11016 Console 1 5.156 K\n<\/pre>\n and then connect to it:<\/p>\n
\nC:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x86>
windbg.exe -pn corelanapp1.exe<\/cmd>\n<\/pre>\n If there was more than one process with this process name, you'd get something like this:<\/p>\n
![\"windbg-multiple\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-multiple.png\" "\\"windbg-multiple.png\\"")
<\/p>\nWinDBGX, 'Attach'<\/h4>\n
In WinDBGX, attaching to an already running process can be done by clicking the \"File\" menu and then choosing \"Attach to process\", or by simply pressing F6 (just like WinDBG Classic).
\nWinDBGX lists the processes in the order that they are created, but with the newest on top. In other words, you usually won't have to scroll down to find the application that you just launched.
\nSelect the process from the list, and click \"Attach\" to start the debugging session.<\/p>\nAttaching from the command line can be done using the same CLI arguments:
\n-p<\/span> and -pn <\/span> <\/p>\n Interestingly enough, if you're trying to attach to a processname that isn't unique, the resulting error message in WinDBGX won't be as clear as the one we got earlier in WinDBG Classic:
\n![\"windbgx-multiple\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbgx-multiple.png\" "\\"windbgx-multiple.png\\"")
<\/p>\nRunning WinDBG(X) - Command Line Arguments<\/h2>\n
We've used WinDBG to open an executable and to attach to a process using the -p<\/span> flag. I've demonstrated how to use the -hd<\/span> flag to disable activating the NTGlobalFlags.
\nThose are just a few of the available command line options. Of course, you can find the full list of available options in the WinDBG Help, but I'll take a moment to discuss the ones I use the most:<\/p>\n- \n
- -g<\/span> \u2192 Do not break on initial execution. This flag allows you to automatically run the process once the debugger attaches or creates the process. It's useful when scripting<\/li>\n
- -G<\/span> \u2192 Exit WinDBG when the process terminates. Similar to -g, it's a useful CLI option when scripting<\/li>\n
- -Q<\/span> \u2192 WinDBG Classic only - Do not ask to save the workspace. Similar to -g and -G, it's a useful CLI option when scripting<\/li>\n
- -o<\/span> \u2192 Follow child processes<\/li>\n
- -logo path\/to\/logfile<\/span> \u2192 Write the output of the entire debugging session into a log file<\/li>\n
- -xd sov<\/span> \u2192 Ignore \"StackOverflow\" exceptions<\/li>\n
- -xi eh<\/span> \u2192 Ignore C++ EH exceptions<\/li>\n
- -WF path\/to\/workspacefile<\/span> \u2192 WinDBG Classic only - make WinDBG load a \"workspace\" file, which allows you to customize the GUI. We'll talk more about this in the next chapter<\/li>\n
- -c \"windbg commands\"<\/span>: Execute the commands (semi-colon separated) between the double quotes the moment the debugger breaks. You can use this to either execute commands at WinDBG startup (and by adding ;g<\/span> at the end, WinDBG will mimic what command line option -g does.) Or you can use it in combination with -g to have WinDBG run certain commands when the debugging session stops (which is typically when it hits an access violation.<\/li>\n<\/ul>\n
Customizing the GUI<\/h2>\n
Customizing the WinDBG Classic GUI<\/h3>\n
The WinDBG Classic Workspace<\/h4>\n
WinDBG Classic's GUI is a bit ... basic. You'll get to see text based output in Command Window and you'll need to instruct WinDBG to show you what you want to see.
\nPeople coming from visual debuggers such as x64dbg, Immunity, etc might feel a bit frustrated by the lack of visuals. People new to exploit development may not know yet what to look for, so the lack of visuals is not exactly helping either.<\/p>\nWe have the option to customize the look & feel. We can open some additional windows\/views and arrange them in such a way that it feels more intuitive (for those that come from x64dbg\/...), by kind of mimicking a layout that would be similar to the majority of visual debuggers.
\nThat means, showing:<\/p>\n- \n
- A disassembly view, showing CPU instructions around EIP<\/li>\n
- The general purpose registers<\/li>\n
- The stack, showing pointers instead of bytes (little-endian)<\/li>\n
- The output in the Command window<\/li>\n
- An window that allows us to see any location in memory<\/li>\n<\/ul>\n
The look&feel of WinDBG Classic is called a \"Workspace\". It includes what windows are visible, their position, the font & font sizes, colors used for certain things, the process it is attached to, etc. <\/p>\n
The active workspace can be stored in a workspace file, and we can tell WinDGB (from the GUI or via a CLI argument) to load a workspace from file.<\/p>\n
Saving the workspace to a file requires a bit of attention. As explained, it contains the process it's attached to. If you were to save the active workspace (i.e. save the workspace from your active debugging session) to a workspace file, and your session is attached to a process, that information will be included in the file. Consequently, WinDBG will automatically try to attach itself to the process in that workspace file next time you open the workspace file, yes even if you were already attached to another process.
\nThat's probably not what we want.
\nOn the flipside, in order to see the effect of the changes that you're making, it helps if WinDBG is actually attached to something.
\nIn other words, right before saving a workspace to file, we should detach WinDBG from the process it is connected to and then save the workspace.<\/p>\nOr, alternatively, you can customize the workspace, save it to file, and use a second debugger to load the workspace, attach itself to a process and see what the updated workspace looks like. That's what I usually do. That way, I won't forget to detach, and I can still see the effect of the changes I made in real time using the second debugger instance. Make changes in the empty (non-connected) debugger, and use a real session on the side to see the effect.
\nWhatever scenario. you do, please be careful not to save the workspace when WinDBG is actively debugging a process.\n<\/p><\/blockquote>\n
- -G<\/span> \u2192 Exit WinDBG when the process terminates. Similar to -g, it's a useful CLI option when scripting<\/li>\n
- -g<\/span> \u2192 Do not break on initial execution. This flag allows you to automatically run the process once the debugger attaches or creates the process. It's useful when scripting<\/li>\n
- FLG_HEAP_ENABLE_FREE_CHECK (0x20)<\/span><\/li>\n
- FLG_HEAP_ENABLE_TAIL_CHECK (0x10)<\/span><\/li>\n
- 'Attaching'<\/strong> to an already running process. In this case, it will \"intervene\" and pause the application, regardless of where it was\/is.<\/li>\n<\/ol>\n
- 'Opening'<\/strong> or 'launching'<\/strong> an executable. The debugger will then create that application, and it will be connected to it from the start, leaving it paused before it executes application logic.<\/li>\n
- Right click \u201cWindows PowerShell\u201d and choose \u201cRun as administrator\u201d<\/li>\n<\/ul>\n
- Click on the \u201cStart\u201d icon, start typing powershell<\/span>. The \u201cBest match\u201d section should show \u201cWindows PowerShell\u201d.<\/li>\n
- Malware analysts<\/strong> may use a debugger to unpack malware, bypass anti-analysis tricks, dump content from memory, and so on.<\/li>\n
![\"windbg-darkwew\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-darkwew.png\" "\\"windbg-darkwew.png\\"")
<\/p>\n![\"windbg-corelanwew\"](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/windbg-corelanwew.png\" "\\"windbg-corelanwew.png\\"")
<\/p>\n