This project provides you with two scripts:

 - rwindbg.ps1 - just calls `rwindbg.bat` passing all arguments it receives. It exists to help those that feel better using a PowerShell script
 - rwindbg.bat - where a temporary environment setup happens to be able to run WinDBG and get the most benefit from it.

Both of these scripts expect arguments which will tell WinDBG what process to start or attach to debug:

 - create a new process running under the debugger: target\debug\stack_overflow.exe
 - to attach to an already running program by PID:  -p PID
 - to attach to an already running program by name: -pn notepad.exe

The necessary environment for running WinDBG is a bit involved:

• where to find my source code during the debugging session
• where to find my debugging symbols
• where to find the system component symbols
• how to automatically download the missing ones
• where to cache them on my disk once downloaded
• where to download them from

If you are insterested in seeing how this environment is conveyed to WinDBG, you can edit rwindbg.bat and search for these line:

:: (if you want to see the arguments to WinDBG and Rust that are active, comment the next line by adding :: as first two characters)
goto :skip_over_show_env

Comment this "goto ..." line and rwindbg.bat now prints it's environment settings before it start the WinDBG session:

PS R:\repo\rust-windbg> .\rwindbg.ps1 .\target\debug\stack_overflow.exe
_NT_SOURCE_PATH=.\src;.\;C:\Users\opedr\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust;C:\Users\opedr\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust
_NT_SYMBOL_PATH=cache*c:\Symbols\ms;srv*https://msdl.microsoft.com/download/symbols;srv*target\debug;srv*target\debug\deps;srv*target\debug\build;srv*target\release;srv*target\release\deps;srv*target\release\build;srv*C:\Users\opedr\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin;srv*C:\Users\opedr\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib;srv*C:\Users\opedr\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin;srv*C:\Users\opedr\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib
start windbg -W Default -c "$><C:\Users\opedr\AppData\Local\Temp\rwindbg.windbg" .\target\debug\stack_overflow.exe
PS R:\repo\rust-windbg> 

• attach a new debugger instance to the notepad.exe you created and left running with "qd", this time using

PS R:\repo\rust-windbg> rwindbg.bat -pn notepad.exe

• notice that the font selection and the docked window settings have persisted

• let's look at what the script controled WinDBG last printed, which is the list of all modules loaded in the process. These are the dependent DLLs. If any of these is missing, the program cannot even be started.
  This is the output of the "lm" command. It shows each module start and end loading address, the module name, the symbol loading status ("deferred", "pdb symbols", "private pdb symbols") and the symbol filename (only if one is loaded):

  ========== lm - show the modules currently loaded to our process
  start             end                 module name
  00007ff6`320a0000 00007ff6`320fa000   notepad    (pdb symbols)          c:\symbols\ms\notepad.pdb\187DDA8685B2AE461B8B6C4FC32FA79C1\notepad.pdb
  00007ffb`1ec00000 00007ffb`1ee93000   COMCTL32   (pdb symbols)          c:\symbols\ms\comctl32.pdb\C6E036C1E6FB2D8A98B12D310EA28CFC1\comctl32.pdb
  00007ffb`28530000 00007ffb`28649000   gdi32full   (pdb symbols)          c:\symbols\ms\gdi32full.pdb\2D1A8910B950465BDEEA50628ECDE4EC1\gdi32full.pdb
  00007ffb`28650000 00007ffb`286ea000   msvcp_win   (pdb symbols)          c:\symbols\ms\msvcp_win.pdb\34CF737A2EC69D74A1E74342D39636281\msvcp_win.pdb
  00007ffb`286f0000 00007ffb`28716000   win32u     (pdb symbols)          c:\symbols\ms\win32u.pdb\CD69FD27F9D0EF5A15A38E7077C3DAC91\win32u.pdb
  00007ffb`28720000 00007ffb`28ac7000   KERNELBASE   (pdb symbols)          c:\symbols\ms\kernelbase.pdb\639BADC1F9F2D7F0F8AC2DA91D5CF7B71\kernelbase.pdb
  00007ffb`28d80000 00007ffb`28da8000   bcrypt     (pdb symbols)          c:\symbols\ms\bcrypt.pdb\973F82DD45767EBD629F2B5A6CC2A2C41\bcrypt.pdb
  00007ffb`28e20000 00007ffb`28f31000   ucrtbase   (pdb symbols)          c:\symbols\ms\ucrtbase.pdb\B3FB7E9697D3F52D70C3BEB2AF2B94821\ucrtbase.pdb
  00007ffb`29180000 00007ffb`29295000   RPCRT4     (pdb symbols)          c:\symbols\ms\rpcrt4.pdb\8D15D31D8F997167B2F6855E344D129D1\rpcrt4.pdb
  00007ffb`292a0000 00007ffb`292c9000   GDI32      (pdb symbols)          c:\symbols\ms\gdi32.pdb\483BD0A60FE0DF29F3C24BD5676A3AC31\gdi32.pdb
  00007ffb`29750000 00007ffb`29845000   shcore     (pdb symbols)          c:\symbols\ms\shcore.pdb\E409E489361AB65E9EF0EC8EB6A46F9B1\shcore.pdb
  00007ffb`29850000 00007ffb`29914000   KERNEL32   (pdb symbols)          c:\symbols\ms\kernel32.pdb\6EC59C2D4B03AACAA9235F9A61D88F121\kernel32.pdb
  00007ffb`2a5a0000 00007ffb`2a648000   sechost    (pdb symbols)          c:\symbols\ms\sechost.pdb\F418698994B8D7FF9F26BA221E68797B1\sechost.pdb
  00007ffb`2a680000 00007ffb`2a727000   msvcrt     (pdb symbols)          c:\symbols\ms\msvcrt.pdb\9DECB4CB0673A2630140316F80FCE4981\msvcrt.pdb
  00007ffb`2a730000 00007ffb`2a7e2000   advapi32   (pdb symbols)          c:\symbols\ms\advapi32.pdb\B733942119F6082791A28DBABA9F5E321\advapi32.pdb
  00007ffb`2a7f0000 00007ffb`2a99e000   USER32     (pdb symbols)          c:\symbols\ms\user32.pdb\AC05C27770E42DCA4E17EE8C8999268B1\user32.pdb
  00007ffb`2ac00000 00007ffb`2af88000   combase    (private pdb symbols)  c:\symbols\ms\combase.pdb\BEDF8B99DAE89EA8D41059D16C5BB39E1\combase.pdb
  00007ffb`2b210000 00007ffb`2b427000   ntdll      (pdb symbols)          c:\symbols\ms\ntdll.pdb\8D5D5ED5D5B8AA609A82600C14E3004D1\ntdll.pdb
  ========== type "k<ENTER>" to see our current stack
  

• enter the command "lmvM *.exe", which will display the full information for your process executable

  0:000> lmvM *.exe
  Browse full module list
  start             end                 module name
  00007ff6`320a0000 00007ff6`320fa000   notepad    (pdb symbols)          c:\symbols\ms\notepad.pdb\187DDA8685B2AE461B8B6C4FC32FA79C1\notepad.pdb
     Loaded symbol image file: C:\WINDOWS\SYSTEM32\notepad.exe
     Image path: notepad.exe
     Image name: notepad.exe
     Browse all global symbols  functions  data
     Image was built with /Brepro flag.
     Timestamp:        2800487F (This is a reproducible build file hash, not a timestamp)
     CheckSum:         0005E412
     ImageSize:        0005A000
     File version:     10.0.22621.3527
     Product version:  10.0.22621.3527
     File flags:       0 (Mask 3F)
     File OS:          40004 NT Win32
     File type:        1.0 App
     File date:        00000000.00000000
     Translations:     0409.04b0
     Information from resource tables:
         CompanyName:      Microsoft Corporation
         ProductName:      Microsoft® Windows® Operating System
         InternalName:     Notepad
         OriginalFilename: NOTEPAD.EXE
         ProductVersion:   10.0.22621.3527
         FileVersion:      10.0.22621.3527 (WinBuild.160101.0800)
         FileDescription:  Notepad
         LegalCopyright:   © Microsoft Corporation. All rights reserved.
  

• Sometimes we have a problem that only happen at a specific OS version. To find out exactly which OS version we are running, We can also get more detail about which specific version of the KERNELBASE we are dealing with:

  0:000> lmvM *KERNELBASE*
  Browse full module list
  start             end                 module name
  00007ffe`a95a0000 00007ffe`a9947000   KERNELBASE   (pdb symbols)          c:\symbols\ms\kernelbase.pdb\639BADC1F9F2D7F0F8AC2DA91D5CF7B71\kernelbase.pdb
      Loaded symbol image file: C:\WINDOWS\System32\KERNELBASE.dll
      Image path: C:\WINDOWS\System32\KERNELBASE.dll
      Image name: KERNELBASE.dll
      Browse all global symbols  functions  data
      Image was built with /Brepro flag.
      Timestamp:        83EFBEAB (This is a reproducible build file hash, not a timestamp)
      CheckSum:         003AFED9
      ImageSize:        003A7000
      File version:     10.0.22621.3527
      Product version:  10.0.22621.3527
      File flags:       0 (Mask 3F)
      File OS:          40004 NT Win32
      File type:        2.0 Dll
      File date:        00000000.00000000
      Translations:     0409.04b0
      Information from resource tables:
          CompanyName:      Microsoft Corporation
          ProductName:      Microsoft® Windows® Operating System
          InternalName:     Kernelbase.dll
          OriginalFilename: Kernelbase.dll
          ProductVersion:   10.0.22621.3527
          FileVersion:      10.0.22621.3527 (WinBuild.160101.0800)
          FileDescription:  Windows NT BASE API Client DLL
          LegalCopyright:   © Microsoft Corporation. All rights reserved.
  

  • from this output we can see that:
    • it comes from Windows 10.0, Build 22621, and it took 3527 revisions to get it all just right for delivery
      • File version: 10.0.22621.3527
    • where it lives
      • Loaded symbol image file: C:\WINDOWS\System32\KERNELBASE.dll
      • Image path: C:\WINDOWS\System32\KERNELBASE.dll
    • its symbol file (i.e. it's PDB) was downloaded by the debugger to c:\symbols\ms\kernelbase.pdb\639BADC1F9F2D7F0F8AC2DA91D5CF7B71\kernelbase.pdb
    • it is loaded into the notepad process between
      • begin address: 00007ffe`a95a0000
      • end address: 00007ffe`a9947000
      • notice that the module extents are always a multiple of 64 KiB (that also means that the smallest DLL one can have in Windows is 64 KiB)

So glad you asked. In Windows, all executables and DLLs are packaged using the PEFILE format.
The PEFILE (Portable Executable File) is a fundamental file format used by Windows operating systems for executable files (EXEs), dynamic link libraries (DLLs), and other types of files. It serves as a structured container that organizes code, data, and resources necessary for the execution and operation of programs. The PE format defines headers containing essential metadata like file type, machine architecture, entry point, and information about required libraries. It also divides the file into sections holding code, data, and resources such as icons, strings, and dialog boxes. PEFILE is critical for program loading, linking, and execution, allowing Windows to understand and manage the contents of executable files. Tools like dumpbin.exe, which is delivered with the SDK can be used to inspect it. Tools like editbin.exe from the SDK can be used to modify it.

Most of the information displayed by the "lm" command in WinDBG comes from the PEFILE for that module.

Execute the following command to take a look at the information it contains for our target executable: (On my system, I find it here "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\bin\Hostx64\x64\dumpbin.exe")

dumpbin /headers target\debug\stack_overflow.exe

Interesting tidbits from our executable:

But how are these used you might ask?

Execute the following command to take a look what dependencies our executable has: (On my system, I find it here "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\bin\Hostx64\x64\dumpbin.exe")

r:\repo\rust-windbg>dumpbin /imports target\debug\stack_overflow.exe | findstr /ir "\.dll$"
    api-ms-win-core-synch-l1-2-0.dll
    KERNEL32.dll
    ntdll.dll
    VCRUNTIME140.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll

Our executable can not start unless all these DLLs are found and mapped into our process memory.
By the way, this process is recursive. These DLLs will also have their PEFILE headers inspected and their dependencies loaded prior to themselves being loaded into our process.

On the command above, we only checked the filenames if printed out.
If you look at the actual printout, you will see that each DLL header is followed by the functions our program references from those DLLs. These have to be resolved and their addressed (after being mapped into our process) replaced in our process import table. That is how external functions referenced by our program are found during execution time.

Let's take a look at a single one of them, the VCRUNTIME140.dll:

    VCRUNTIME140.dll
             140026158 Import Address Table
             140032818 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                          1B __current_exception
                          1C __current_exception_context
                           8 __C_specific_handler
                           1 _CxxThrowException
                          3B memcmp
                          3D memmove
                          3E memset
                          3C memcpy
                           E __CxxFrameHandler3

It is interesting that although this is a Rust program, it depends on the C/C++ Runtime library being loaded.
From the name of the referenced functions (exception) seems like Rust is borrowing C/C++ exception handling mechanics.
It also seems to borrow these efficient memory copy, compare, and set functions that can handle overlapping arrays as well.

• let's look for the address of a Windows 32 API such as CreateFileW() which is how files are opened in Win32
• we know that we use CreateFileW in notepad.exe, so let's see if that symbol is defined in the executable module:

0:004> x notepad!*CreateFileW
00007ff7`50669de0 notepad!_imp_CreateFileW = <no type information>

• as you can see, the linker says we do use it, but that it is a import from some other module

Since we don't know where, we will try to find it from all the modules that are loaded for our process.
At this point of the process created, they are all already loaded, so we should be able to find it.

• enter the command "x *!CreateFileW", results which follows:

0:004> x *!CreateFileW
00007ffd`2eb149f0 KERNELBASE!CreateFileW (CreateFileW)
00007ffd`2f230460 KERNEL32!CreateFileW (CreateFileW)
00007ffd`2f3e54c3 combase!CreateFileW (CreateFileW)

• notice that the first column is the address associated with each symbol

• the name of an exported symbol follows the pattern "module!function_name"

• issue the command "lma 00007ffd`2eb149f0" which is the address of the first CreateFileW returned by the "x" command above

  • (you may have to enter the value your "x *!CreateFileW" printed out, since it might be different than mine)

0:004> lma 00007ffd`2eb149f0
Browse full module list
start             end                 module name
00007ffd`2eaf0000 00007ffd`2ee97000   KERNELBASE   (pdb symbols)          c:\symbols\ms\kernelbase.pdb\639BADC1F9F2D7F0F8AC2DA91D5CF7B71\kernelbase.pdb

Now that we know where the function actually is, we can set a breakpoint.
This can be done using the address or the name.

0:000> bp KERNELBASE!CreateFileW
0:000> bl
     0 e Disable Clear  00007fff`6e6149f0     0001 (0001)  0:**** KERNELBASE!CreateFileW

Notice that the first number printed is a zero. This is actually a sequential id for the breakpoints you create.
You can use them on commands affecting the breakpoint by specifying their id. The second, the letter 'e', indicates if the breakpoint is enabled or disabled.

If you want to disable the stopping at this location for now either click Disable or emit the command line for it. When I click on Disable, the command "bd 0" is executed. Typing the command "bc 0" will clear (delete) the breakpoint.

In general all the links on the WinDBG UI are accelerator to commands like that

0:000> bp KERNELBASE!CreateFileW
0:000> bl
     0 e Disable Clear  00007fff`6e6149f0     0001 (0001)  0:**** KERNELBASE!CreateFileW
0:000> bd 0
0:000> bl
     0 d Enable Clear  00007fff`6e6149f0     0001 (0001)  0:**** KERNELBASE!CreateFileW
0:000> bc 0
0:000> bl

I wanted this contrived example fail faster (not too many entries until it ran out of stack), so I am passing an array by value on the call to the factorial() function.
But Rust compiler is too smart and because I originally had no references into that array, it optimized it away and kept failing with still "too many" entries on the stack.
Only when I started accessing the array itself it finally failed as fast as desired since now the rust compiler had no choice but add the array manipulating steps to the generated code.

The final version we run this program with a stack of 4Kb, which is the minimum stack a Windows thread may have, since stacks are OS page size minimum.

Later on, we will also notice that stacks for multiple threads seem to coalesce in memory.

You can all see all other possible Windows errors and their associated message by inspecting this file delivered as part of the Windows SDK:
ntstatus.h

Another interesting file contains all possible results for the Win32 API GetLastError(), which is also part of the Windows SDK:
winerror.h

Using cargo run --release, we get a different, although still incorrect, result:

r:\repo\rust-windbg>cargo run --release --bin stack_overflow
   Compiling rust-windbg v0.1.0 (R:\repo\rust-windbg)
    Finished `release` profile [optimized] target(s) in 1.00s
     Running `target\release\stack_overflow.exe`
Hello from thread1!
Enter a non-negative integer: 100
The factorial of 100 is: 0

For now, we will make a record of that fact but decide to investigate it later.

0:000> .hh thread

windbg> .hh thread
0:000> |
.  0	id: 722c	create	name: stack_overflow.exe
0:000> ~
.  0  Id: 722c.206c Suspend: 1 Teb: 0000004e`3b1bc000 Unfrozen
   1  Id: 722c.2028 Suspend: 1 Teb: 0000004e`3b1be000 Unfrozen
   2  Id: 722c.7474 Suspend: 1 Teb: 0000004e`3b1c0000 Unfrozen
   3  Id: 722c.734 Suspend: 1 Teb: 0000004e`3b1c2000 Unfrozen

On the data shown above, we see that process index 0 is the current process and that thread index 0 is the current thread.
The "." as the first character indicates which is the current.
We also learn that we can change the current process "|0s" or the current thread "~3s" by adding their index and "s" after it.

We can also ask for a command to be executed on a specific thread context, such as asking what was the last error that happened on that thread.
That is, what was the last value someone called the Win32 API SetLastError() with, or what was the last status value of a kernel operation on this thread:

0:000> ~*e !gle
LastErrorValue: (Win32) 0xbb (187) - The specified system semaphore name was not found.
LastStatusValue: (NTSTATUS) 0 - STATUS_SUCCESS
LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
LastStatusValue: (NTSTATUS) 0 - STATUS_SUCCESS
LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
LastStatusValue: (NTSTATUS) 0 - STATUS_SUCCESS
LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
LastStatusValue: (NTSTATUS) 0 - STATUS_SUCCESS

We can also ask to see the stack for each thread to get an overall picture of what is happening in our process right now.
At this time, I don't expect anything very interesting since we are starting the process and not much has happened from the user program point of view.

0:000> ~*k

.  0  Id: 722c.206c Suspend: 1 Teb: 0000004e`3b1bc000 Unfrozen
 # Child-SP          RetAddr               Call Site
00 0000004e`3af7ed30 00007ffe`ac2ee99a     ntdll!LdrpDoDebuggerBreak+0x30
01 0000004e`3af7ed70 00007ffe`ac2da744     ntdll!LdrpInitializeProcess+0x1cfa
02 0000004e`3af7f140 00007ffe`ac283ea3     ntdll!_LdrpInitialize+0x56868
03 0000004e`3af7f1c0 00007ffe`ac283dce     ntdll!LdrpInitializeInternal+0x6b
04 0000004e`3af7f440 00000000`00000000     ntdll!LdrInitializeThunk+0xe

   1  Id: 722c.2028 Suspend: 1 Teb: 0000004e`3b1be000 Unfrozen
 # Child-SP          RetAddr               Call Site
00 0000004e`3b2ff768 00007ffe`ac24537e     ntdll!NtWaitForWorkViaWorkerFactory+0x14
01 0000004e`3b2ff770 00007ffe`abf0257d     ntdll!TppWorkerThread+0x2ee
02 0000004e`3b2ffa50 00007ffe`ac26aa48     KERNEL32!BaseThreadInitThunk+0x1d
03 0000004e`3b2ffa80 00000000`00000000     ntdll!RtlUserThreadStart+0x28

   2  Id: 722c.7474 Suspend: 1 Teb: 0000004e`3b1c0000 Unfrozen
 # Child-SP          RetAddr               Call Site
00 0000004e`3b3ffc18 00007ffe`ac24537e     ntdll!NtWaitForWorkViaWorkerFactory+0x14
01 0000004e`3b3ffc20 00007ffe`abf0257d     ntdll!TppWorkerThread+0x2ee
02 0000004e`3b3fff00 00007ffe`ac26aa48     KERNEL32!BaseThreadInitThunk+0x1d
03 0000004e`3b3fff30 00000000`00000000     ntdll!RtlUserThreadStart+0x28

   3  Id: 722c.734 Suspend: 1 Teb: 0000004e`3b1c2000 Unfrozen
 # Child-SP          RetAddr               Call Site
00 0000004e`3b4ff7a8 00007ffe`ac24537e     ntdll!NtWaitForWorkViaWorkerFactory+0x14
01 0000004e`3b4ff7b0 00007ffe`abf0257d     ntdll!TppWorkerThread+0x2ee
02 0000004e`3b4ffa90 00007ffe`ac26aa48     KERNEL32!BaseThreadInitThunk+0x1d
03 0000004e`3b4ffac0 00000000`00000000     ntdll!RtlUserThreadStart+0x28

0:000> gn

Note: I normally default to typing "gn" which official name is "Go with Exception Not Handled".
This command allows the application's exception handler to handle the exception.
Remember, you can always do ".hh gn" to read the details in the WinDBG Help.

Once "gn" is pressed, WindDBG shows that the debuggee is now running:

*BUSY* | Debuggee is running...

Change your focus to the terminal window and answer the question there:

Hello from thread1!
Enter a non-negative integer: 100

Look back at the WinDBG window and you see that the stack overflow event has happened:

0:000> gn
(722c.31fc): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
stack_overflow!stack_overflow::factorial+0x7:
00007ff7`1e218597 48894c2450      mov     qword ptr [rsp+50h],rcx ss:0000004e`3af86600=0000000000000000

If our source setup is correct and our code build did produce a PDB containing the symbol file, WinDBG will open the associated source file and display the line number where the event happened:
(I marked the first line with '>>>' to indicate which line WinDBG highlighted on my screen)

...
>>> fn factorial(arg: FactorialArgument) -> u64 {
    if arg.idx == 0 {
        1 // Base case: Factorial of 0 is 1
    } else {
        let mut new_arg = FactorialArgument { idx: arg.idx-1, array: [0;COUNT_ENTRIES]}; // wastes stack space on every call
        new_arg.array[new_arg.idx] = arg.idx;
        arg.idx as u64 * factorial(new_arg) // Recursive case: n! = n * (n-1)!
    }
}
...

I am curious to see what our other threads have been doing when this event took place that stop all threads.
So I execute "~" to see all our current threads:

0:004> ~
   0  Id: 722c.206c Suspend: 1 Teb: 0000004e`3b1bc000 Unfrozen "main"
.  4  Id: 722c.31fc Suspend: 1 Teb: 0000004e`3b1c4000 Unfrozen "thread1"

Interesting, seems like our original threads indices 1, 2, and 3 have since terminated and are no longer threads in our process.
There is a new thread, index 4, which is the one that we create in our source with a smallish stack to force the stack overflow.

I now execute a "~#" which tells me which thread caused the debug event that stopped the execution:

0:004> ~#
.  4  Id: 722c.31fc Suspend: 1 Teb: 0000004e`3b1c4000 Unfrozen "thread1"
      Start: stack_overflow!std::sys::pal::windows::thread::impl$0::new::thread_start (00007ff7`1e225050)
      Priority: 0  Priority class: 32  Affinity: ffffff

And finally we see what are the current stack traces for all threads:

0:004> ~*k

   0  Id: 722c.206c Suspend: 1 Teb: 0000004e`3b1bc000 Unfrozen "main"
 # Child-SP          RetAddr               Call Site
00 0000004e`3af7f248 00007ffe`a95d427e     ntdll!NtWaitForSingleObject+0x14
01 0000004e`3af7f250 00007ff7`1e225231     KERNELBASE!WaitForSingleObjectEx+0x8e
02 0000004e`3af7f2f0 00007ff7`1e2118c5     stack_overflow!std::sys::pal::windows::thread::Thread::join+0x21 [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library\std\src\sys\pal\windows\thread.rs @ 72] 
...
0c 0000004e`3af7f880 00007ff7`1e23349c     stack_overflow!main+0x19
0d (Inline Function) --------`--------     stack_overflow!invoke_main+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 
0e 0000004e`3af7f8b0 00007ffe`abf0257d     stack_overflow!__scrt_common_main_seh+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
0f 0000004e`3af7f8f0 00007ffe`ac26aa48     KERNEL32!BaseThreadInitThunk+0x1d
10 0000004e`3af7f920 00000000`00000000     ntdll!RtlUserThreadStart+0x28

#  4  Id: 722c.31fc Suspend: 1 Teb: 0000004e`3b1c4000 Unfrozen "thread1"
 # Child-SP          RetAddr               Call Site
00 0000004e`3af865b0 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x7 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 36] 
01 0000004e`3af87210 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
02 0000004e`3af87e70 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
03 0000004e`3af88ad0 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
04 0000004e`3af89730 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
05 0000004e`3af8a390 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
06 0000004e`3af8aff0 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
07 0000004e`3af8bc50 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
08 0000004e`3af8c8b0 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
09 0000004e`3af8d510 00007ff7`1e2186a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
0a 0000004e`3af8e170 00007ff7`1e215198     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 
0b 0000004e`3af8edd0 00007ff7`1e21a279     stack_overflow!stack_overflow::main::closure$0+0xc8 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 28] 
...
16 0000004e`3af8fe10 00007ffe`abf0257d     stack_overflow!std::sys::pal::windows::thread::impl$0::new::thread_start+0x4c [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library\std\src\sys\pal\windows\thread.rs @ 54] 
17 0000004e`3af8fea0 00007ffe`ac26aa48     KERNEL32!BaseThreadInitThunk+0x1d
18 0000004e`3af8fed0 00000000`00000000     ntdll!RtlUserThreadStart+0x28

So we can see that thread index 0 (the main thread) is waiting for the thread we created to complete its processing and return (rejoin): (I only copy here the detail of the three top entries on the stack for the main thread)

   0  Id: 722c.206c Suspend: 1 Teb: 0000004e`3b1bc000 Unfrozen "main"
 # Child-SP          RetAddr               Call Site
00 0000004e`3af7f248 00007ffe`a95d427e     ntdll!NtWaitForSingleObject+0x14
01 0000004e`3af7f250 00007ff7`1e225231     KERNELBASE!WaitForSingleObjectEx+0x8e
02 0000004e`3af7f2f0 00007ff7`1e2118c5     stack_overflow!std::sys::pal::windows::thread::Thread::join+0x21 [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library\std\src\sys\pal\windows\thread.rs @ 72] 

From this stack we can see that the last of rust source before it goes into the Windows Kernel is the call to fn Thread::join().
Sometimes I would like to see what takes place in these functions that I call (or that I called on my behalf), but don't know the implementation.
They just might give me some hints about their implementation that would help me understand why my code behaves as it does.

Go ahead and click on the 02, the very first two characters on this stack entry Or click on the original source path as shown after the function name on the same stack entry.
WinDBG will work its magic and translate from the address contained on the stack to the source file and line number on your disk and open the source file for your enjoyment.

Because the rwindbg script setup our source path and we did rustup component add rust-src during setup, you can click on the source path between the square brackets above and see what is the implementation of fn join():

    pub fn join(self) {
        let rc = unsafe { c::WaitForSingleObject(self.handle.as_raw_handle(), c::INFINITE) };
>>>        if rc == c::WAIT_FAILED {
            panic!("failed to join on thread: {}", io::Error::last_os_error());
        }
    }

So after our script setup, WinDBG knows how to translate the source filename contained in the PDB for std implementation and our current download location for the rust-src component. From:

/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library\std\src\sys\pal\windows\thread.rs

to

C:\Users\opedr\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\pal\windows\thread.rs

Notice that when we originally did our "~" the first time around this was the WinGDB prompt:

0:000> ~*k

and now, this is the prompt:

0:004> ~*k

In WinDbg, the command prompt numbers provide information about the debugging session context:

• First Number (System Number): This number indicates the system being debugged, and is only displayed when WinDbg is attached to multiple systems. If you're debugging a single system, this number is usually 0.
• Second Number (Process Number): This number represents the currently active process within the system. Processes are identified by unique numbers, and WinDbg displays the number of the process you're currently inspecting or manipulating.
• Third Number (Thread Number): This number identifies the currently active thread within the selected process. Threads are like smaller units of execution within a process, and WinDbg shows the number of the thread you're focusing on.

Since we our session did not start using more than one system, WinDBG defaults to using (process number):(thread number)> as prompt.

Next, let's take a look at our Thread Execution Block. The TEB keeps information like the values of the CPU registers, the last time the thread was interrupted, the stack limits, ...

0:004> .lastevent
Last event: 722c.31fc: Stack overflow - code c00000fd (first chance)
  debugger time: Sat May 25 15:35:47.056 2024 (UTC + 2:00)
0:004> !teb
TEB at 0000004e3b1c4000
    ExceptionList:        0000000000000000
    StackBase:            0000004e3af90000
    StackLimit:           0000004e3af81000
    SubSystemTib:         0000000000000000
    FiberData:            0000000000001e00
    ArbitraryUserPointer: 0000000000000000
    Self:                 0000004e3b1c4000
    EnvironmentPointer:   0000000000000000
    ClientId:             000000000000722c . 00000000000031fc
    RpcHandle:            0000000000000000
    Tls Storage:          000001a2802cefe0
    PEB Address:          0000004e3b1bb000
    LastErrorValue:       0
    LastStatusValue:      c000000d
    Count Owned Locks:    0
    HardErrorMode:        0
0:004> ? 000004e3af90000 - 0000004e3af81000
Evaluate expression: 61440 = 00000000`0000f000

So, from looking at the TEB, it tells me that my thread stack is actually 61440 bytes.
That is exactly 60 KiB. Remember that a stack is always [[committed stack][page guard] reserved stack]. That would make our stack be 64 KiB total size. Even though in code we asked for a (8 * 1024) stack.

    // Create a builder for the thread
    let builder = thread::Builder::new()
        .name("thread1".to_string()) // Set thread name
        .stack_size(8 * 1024);  // set for a small stack (default for Windows processes is 1 MiB, minimum is 4 KiB)

Another mistery.

Our stack minimum requirements can be gleamed by seeing what is our threads stack usage by the time we call factorial() the first time. Let's exit our current debugging session and start a new one:

rwindbg target/debug/stack_overflow.exe


0:000> * let's find out our factorial function's address to set a breakpoint
0:000> x stack*!*factorial*
00007ff6`25fa8590 stack_overflow!stack_overflow::factorial (struct stack_overflow::FactorialArgument *)


0:000> * set the breakpoint
0:000> bp stack_overflow!stack_overflow::factorial
0:000> bl
     0 e Disable Clear  00007ff6`25fa8590     0001 (0001)  0:**** stack_overflow!stack_overflow::factorial


0:000> * let the program run until brekapoint is reached
0:000> gn
Breakpoint 0 hit
stack_overflow!stack_overflow::factorial:
00007ff6`25fa8590 4881ec580c0000  sub     rsp,0C58h


0:000> * what is our stack at this point?
0:004> k
 # Child-SP          RetAddr               Call Site
00 0000003c`1e7aedd8 00007ff6`25fa5198     stack_overflow!stack_overflow::factorial [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 36] 
01 0000003c`1e7aede0 00007ff6`25faa279     stack_overflow!stack_overflow::main::closure$0+0xc8 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 28] 
02 (Inline Function) --------`--------     stack_overflow!core::hint::black_box [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\core\src\hint.rs @ 337] 
03 0000003c`1e7afb10 00007ff6`25fa27d9     stack_overflow!std::sys_common::backtrace::__rust_begin_short_backtrace<stack_overflow::main::closure_env$0,tuple$<> >+0x9 [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\std\src\sys_common\backtrace.rs @ 158] 
04 0000003c`1e7afb40 00007ff6`25fa4bc9     stack_overflow!std::thread::impl$0::spawn_unchecked_::closure$1::closure$0<stack_overflow::main::closure_env$0,tuple$<> >+0x9 [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\std\src\thread\mod.rs @ 529] 
05 0000003c`1e7afb70 00007ff6`25fa39bd     stack_overflow!core::panic::unwind_safe::impl$25::call_once<tuple$<>,std::thread::impl$0::spawn_unchecked_::closure$1::closure_env$0<stack_overflow::main::closure_env$0,tuple$<> > >+0x9 [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\core\src\panic\unwind_safe.rs @ 273] 
06 0000003c`1e7afba0 00007ff6`25fa3b33     stack_overflow!std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<std::thread::impl$0::spawn_unchecked_::closure$1::closure_env$0<stack_overflow::main::closure_env$0,tuple$<> > >,tuple$<> >+0x1d [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\std\src\panicking.rs @ 554] 
07 0000003c`1e7afbf0 00007ff6`25fa3926     stack_overflow!std::panicking::try::do_catch<core::panic::unwind_safe::AssertUnwindSafe<std::thread::impl$7::drop::closure_env$0<tuple$<> > >,tuple$<> >+0xc3
08 0000003c`1e7afc40 00007ff6`25fa265a     stack_overflow!std::panicking::try<tuple$<>,core::panic::unwind_safe::AssertUnwindSafe<std::thread::impl$0::spawn_unchecked_::closure$1::closure_env$0<stack_overflow::main::closure_env$0,tuple$<> > > >+0x26 [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\std\src\panicking.rs @ 516] 
09 (Inline Function) --------`--------     stack_overflow!std::panic::catch_unwind+0x5 [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\std\src\panic.rs @ 146] 
0a 0000003c`1e7afcb0 00007ff6`25fa61ae     stack_overflow!std::thread::impl$0::spawn_unchecked_::closure$1<stack_overflow::main::closure_env$0,tuple$<> >+0xfa [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\std\src\thread\mod.rs @ 527] 
0b 0000003c`1e7afde0 00007ff6`25fb509c     stack_overflow!core::ops::function::FnOnce::call_once<std::thread::impl$0::spawn_unchecked_::closure_env$1<stack_overflow::main::closure_env$0,tuple$<> >,tuple$<> >+0xe [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6\library\core\src\ops\function.rs @ 250] 
0c 0000003c`1e7afe20 00007ff8`7146257d     stack_overflow!std::sys::pal::windows::thread::impl$0::new::thread_start+0x4c [/rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library\std\src\sys\pal\windows\thread.rs @ 54] 
0d 0000003c`1e7afeb0 00007ff8`726aaa48     KERNEL32!BaseThreadInitThunk+0x1d
0e 0000003c`1e7afee0 00000000`00000000     ntdll!RtlUserThreadStart+0x28


0:004> * lets look at our thread environment block and our current stack point
0:004> !teb
TEB at 0000003c1e9ec000
    ExceptionList:        0000000000000000
    StackBase:            0000003c1e7b0000
    StackLimit:           0000003c1e7ac000
    SubSystemTib:         0000000000000000
    FiberData:            0000000000001e00
    ArbitraryUserPointer: 0000000000000000
    Self:                 0000003c1e9ec000
    EnvironmentPointer:   0000000000000000
    ClientId:             0000000000006488 . 0000000000006c84
    RpcHandle:            0000000000000000
    Tls Storage:          0000014ece8be3a0
    PEB Address:          0000003c1e9e3000
    LastErrorValue:       0
    LastStatusValue:      c000000d
    Count Owned Locks:    0
    HardErrorMode:        0


0:004> * the 'r' command shows our CPU's registers for the current thread context; rsp is our stack pointer register
0:004> r
rax=0000003c1e7af670 rbx=0000000000000000 rcx=0000003c1e7af670
rdx=0000003c1e7af180 rsi=0000014ece8be350 rdi=0000000000000000
rip=00007ff625fa8590 rsp=0000003c1e7aedd8 rbp=0000003c1e7afc30
 r8=00000000000000f0  r9=0000000000000100 r10=00007ff85e3c0000
r11=00007ff85e3d1335 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
stack_overflow!stack_overflow::factorial:
00007ff6`25fa8590 4881ec580c0000  sub     rsp,0C58h


0:000> * let's calculate how many bytes we are using of our stack at this point (teb.StackBase - rsp)
0:004> ? 0000003c1e7b0000 - 0000003c1e7aedd8
Evaluate expression: 4648 = 00000000`00001228


0:000> * as you can see, we can even use the register name itself on the expression
0:004> ? 0000003c1e7b0000 - rsp
Evaluate expression: 4648 = 00000000`00001228

0:000> * final answer: when first called fn factorial(), our thread stack usage is 4_648 bytes

So when we first call factorial in our thread, this thread's stack usage is 4648 bytes, so it sounds reasonable to request a stack size that is twice as large.

0:004> ~0s
ntdll!NtWaitForSingleObject+0x14:
00007ffe`ac2af9d4 c3              ret
0:000> !teb
TEB at 0000004e3b1bc000
    ExceptionList:        0000000000000000
    StackBase:            0000004e3af80000
    StackLimit:           0000004e3af7c000
    SubSystemTib:         0000000000000000
    FiberData:            0000000000001e00
    ArbitraryUserPointer: 0000000000000000
    Self:                 0000004e3b1bc000
    EnvironmentPointer:   0000000000000000
    ClientId:             000000000000722c . 000000000000206c
    RpcHandle:            0000000000000000
    Tls Storage:          000001a2802c5590
    PEB Address:          0000004e3b1bb000
    LastErrorValue:       0
    LastStatusValue:      0
    Count Owned Locks:    0
    HardErrorMode:        0
0:000> ? 0000004e3af80000 - 0000004e3af7c000
Evaluate expression: 16384 = 00000000`00004000

Interesting, the TEB says that the stack for the main thread is just 16 KiB.

Researching further, I used the command dumpbin to inspect our executable: (On my system, I find it here "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\bin\Hostx64\x64\dumpbin.exe")

r:\repo\rust-windbg>dumpbin /headers target\debug\stack_overflow.exe | findstr /c:"size of stack" /c:"Dump of file"
Dump of file target\debug\stack_overflow.exe
          100000 size of stack reserve
            1000 size of stack commit

This means our thread index 0 must actually have a 1 MiB thread stack size, of which only 0x1000 bytes (16 KiB) are committed on startup.

So it seems that the TEB only reflects the committed stack in its data.
I am starting to believe that, once the guard page exception gets thrown:

• the kernel checks that the total reserved amount for the stack has not been reached
• commits the current guard page
• makes the next page the new guard page
• updates the TEB
• and finally resumes this thread's execution by marking it ready so the scheduler will pick it up next time a CPU is available

Checking the WinDBG help file with ".hh stack" takes us to the article titled "Debugging a Stack Overflow".
According to this article there are three reasons a user-thread can encounter a stack overflow condition:

• A thread uses the entire stack reserved for it. This is often caused by infinite recursion.
• A thread cannot extend the stack because the page file is maxed out, and therefore no additional pages can be committed to extend the stack.
• A thread cannot extend the stack because the system is within the brief period used to extend the page file.

The article also hints that the stack overflow is found when executing a function named _chkstk(). This function is supplied as part of the C/C++ Runtime.
The C++ compiler emits code that calls it_chkstk() at the top of every function it generates. It access the highest stack address known on entry, e.g. accessing the last defined local variable.
This will succeed or generate a page guard exception, which will force the stack to be extended prior to the function executing any of its code that depends on those local variables being there.

This article also has some techniques using WinDBG commands and offsets into the TEB data structure to calculate the actual stack extent, but the examples shown are for 32 bit OS and I am sure my 64 bit OS has different offsets. I prefer to write a function in Rust that can inquire the OS what is are the actual stack extents for the current thread.

r:\repo\rust-windbg>cargo run --release --bin stack_overflow_v2
    Finished `release` profile [optimized] target(s) in 0.49s
     Running `target\release\stack_overflow_v2.exe`
Hello from main!
print_stack_extents_win: Stack base address : 0x000000eeeb220000
print_stack_extents_win: Stack limit address: 0x000000eeeb320000
print_stack_extents_win: Stack extent       : 1_048_576  (0x100_000)
Hello from thread1!
print_stack_extents_win: Stack base address : 0x000000eeeb320000
print_stack_extents_win: Stack limit address: 0x000000eeeb330000
print_stack_extents_win: Stack extent       : 65_536  (0x10_000)
Enter a non-negative integer: 100
The factorial of 100 is: 0

r:\repo\rust-windbg>cargo run --bin stack_overflow_v2
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.15s
     Running `target\debug\stack_overflow_v2.exe`
Hello from main!
print_stack_extents_win: Stack base address : 0x00000025c94f0000
print_stack_extents_win: Stack limit address: 0x00000025c95f0000
print_stack_extents_win: Stack extent       : 1_048_576  (0x100_000)
Hello from thread1!
print_stack_extents_win: Stack base address : 0x00000025c95f0000
print_stack_extents_win: Stack limit address: 0x00000025c9600000
print_stack_extents_win: Stack extent       : 65_536  (0x10_000)
Enter a non-negative integer: 100

thread 'thread1' has overflowed its stack
error: process didn't exit successfully: `target\debug\stack_overflow_v2.exe` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)

Interesting that the results still differ slightly between --release and dev targets.
At least the stacks extents are the same for both cases.
It is also interesting to notice that the stacks are located next to each other.
For both targets, the stack for thread1 starts where the stack for the main thread ends.
They are contiguous in memory. We should not rely on this information but it is interesting to know that this takes place.

* set our current thread to be the faulting thread
~#s
* show the stack
~k

Notice first two characters on each stack entry. That is the frame index. Let's look at the first

0:004> * make frame 01 the current frame; we will be able to see the local variables at that point in time
0:004> .frame 1
01 00000014`63127180 00007ff6`25fa86a5     stack_overflow!stack_overflow::factorial+0x115 [R:\repo\rust-windbg\bug_samples\stack_overflow.rs @ 42] 


0:004> * what are out local variables? instead of the 'dv' command you can also use the 'Local Variables' icon on the toolbar (hover over to see their names)
0:004> dv
            arg = 0x00000014`63128638
        new_arg = struct stack_overflow::FactorialArgument


0:004> * here it becomes easier to click on the `arg` link on WinDBG UI to see it's value, so I do it
0:004> * (by the way, the command that you would have to type to see the value gets displayed when you click the link)
0:004> dx -r1 ((stack_overflow!stack_overflow::FactorialArgument *)0x1463128638)
((stack_overflow!stack_overflow::FactorialArgument *)0x1463128638)                 : 0x1463128638 [Type: stack_overflow::FactorialArgument *]
    [+0x000] array            [Type: unsigned __int64 [127]]
    [+0x3f8] idx              : 0x5b [Type: unsigned __int64]
0:004> * seems like when it runs out of stack, we were processing 91 (0x5b)
0:004> * so we should have on the stack call with arg values 100, 99, 98, ... until 91

0:004> * next I click on `new_arg` link on WinDBG UI
0:004> dx -r1 (*((stack_overflow!stack_overflow::FactorialArgument *)0x14631271e0))
(*((stack_overflow!stack_overflow::FactorialArgument *)0x14631271e0))                 [Type: stack_overflow::FactorialArgument]
    [+0x000] array            [Type: unsigned __int64 [127]]
    [+0x3f8] idx              : 0x5a [Type: unsigned __int64]
0:004> * seems like when it run out of stack, we were preparing the argument to process 90 (0x5a)


0:004> * I also click on the `array` link on WinDBG UI
0:004> dx -r1 (*((stack_overflow!unsigned __int64 (*)[127])0x14631271e0))
(*((stack_overflow!unsigned __int64 (*)[127])0x14631271e0))                 [Type: unsigned __int64 [127]]
    [0]              : 0x0 [Type: unsigned __int64]
    [1]              : 0x0 [Type: unsigned __int64]
    [2]              : 0x0 [Type: unsigned __int64]
    ...
    [89]             : 0x0 [Type: unsigned __int64]
    [90]             : 0x5b [Type: unsigned __int64]
    [91]             : 0x0 [Type: unsigned __int64]
    ...
    [98]             : 0x0 [Type: unsigned __int64]
    [99]             : 0x0 [Type: unsigned __int64]
    [...]            [Type: unsigned __int64 [127]]
0:004> * WinDBG printed the first 100 entries and the last one has an index of '[...]'


0:004> * clicking on the link '[...]', it shows the next 100 entries (but we only have 26 more)
0:004> dx -r1  -c 100 (*((stack_overflow_v2!unsigned __int64 (*)[127])0xb36cb372d0))
(*((stack_overflow_v2!unsigned __int64 (*)[127])0xb36cb372d0))                 [Type: unsigned __int64 [127]]
    [100]            : 0x0 [Type: unsigned __int64]
    [101]            : 0x0 [Type: unsigned __int64]
    ...
    [125]            : 0x0 [Type: unsigned __int64]
    [126]            : 0x0 [Type: unsigned __int64]

Well there are some possibilities. The CPU normally has what is a called a hardware debug register, where an address can be loaded and when the instruction pointer has the same value of this register, it generates an interrupt which the debugger process handles and realizes that a location was reached. On the Intel architecture there are four of these registers.
But I can set many more than 4 breakpoints and the code still stops there.

What a debugger does is to replace the first byte of the instruction at the breakpoint location given with the one byte opcode "int 3" and it remembers the overwritten byte.
Once the code resumes running, it will stop when the "int 3" instruction gets executed, the debugger handler once again replaces the "int 3" it had inserted with the original byte code and return to the user prompt in the debugger UI.
If the user selects "g" to continue execution, the debugger will replace the next instruction first byte with an "int 3", resume execution (which will only execute a single instruction) and when when handling the next instruction's "int 3", re-replace at the breakpoint location the "int 3" (after the instruction was executed, therefore re-enabling that breakpoint), replace the current instruction on the current instruction with the original byte that was there and then resume execution once again. This time the program will resume and run until another debugger event happens.

As you can see this is also how the debugger can implement single step instruction execution as well, by replacing (and remembering) the first byte of the next opcode with "int 3" and resuming execution of the program. Rinse and repeat and you get single instruction stepping.

War Story:
An interesting side-effect of enabling LTO is that each function will be compiled to its own file and accompanying metadata. This allows, on the Windows platform, for one to use the LINK /ORDER:@filename to control the order that symbols are resolved during linking. This provides a subtle way to define the order functions will be loaded into the final executable. Combined with a trace of a scenario run, preferably with counts for how many times each function was called. This trace file will naturally be created with the traces in the order function are called. One can then divide the trace file in two parts, sort the entries in the first half by count in ascending order and the second half in descending order to have a final order file that provides the most optimal working set for an executable. All the high usage functions are close by other high usage functions in the center of the executable and therefore stay in the working set. Initialization functions are loaded first, used and then the OS working set trimming algorithm removes them from memory. Having a highly used neighboor function no longer forces a function that gets used once during startup to stay in memory because of its popular neighboor. This technique made a famous CAD program (millions of copy sold!) once be able to run on laptops where it was not possible before because of page trashing taking place during execution. I named this sort a Bell Curve Sort, since it provided a bell shapped curve result based on the function count traces.