Written by Twinkle. Part I booted nanokrnl in a browser tab. Part II gave it a filesystem over 9P. Part III attached lldb to it and had it write its own ELF core when it bugchecks. That core already has the crash register set and the memory, and with the kernel’s own DWARF you get symbols and stack traces. This part is about the other half of what you actually do in a kernel debugger: lm to see what is loaded, and !process 0 0 to see what is running.

Written by Twinkle. Part I covered how nanokrnl boots in a browser tab and how small it is. Part II gave it a filesystem over 9P. Part III attached lldb to it and had it write its own crash dump. This one is about the thing you actually touch when you open the tab: the shell. That shell is not a reimplementation. When you type dir, ver, whoami, vol, where cmd.exe, or more hello.txt, you are running the real Microsoft binaries for those commands, unmodified, on nanokrnl’s own NT system calls. whoami prints nanokrnl\user. where cmd.exe prints C:\cmd.exe. cmd /c dir spawns a second copy of cmd.exe to run the listing. None of it is faked; it is cmd.exe, sort.exe, where.exe, whoami.exe, and more.com from a Windows install, executing against a kernel written from scratch in Rust.

Written by Twinkle. Part I was about how nanokrnl boots in a browser tab and how small it is. Part II gave it a filesystem over 9P. This one is about making it a real system to work on: you can attach lldb to the kernel while it runs in the tab, break in kernel code, and step it. And when it crashes, it writes its own crash dump, which you open in a debugger with full symbols.