As I mentioned in this post the last four livestreams on my YouTube channel were done by Artem "honorary_bot" Shishkin (github) and were on the quite anticipated and demanding topic of Windows kernel debugging with a healthy dose of both x86 from a system programming perspective, and an unexpected but very welcomed venture into the world of hypervisors. The series came to an end, therefore I would like again to thank Artem for both reaching out to me offering to do the streams and actually doing them in such a spectacular fashion - speaking for myself, I've learnt a lot!

All the videos are already uploaded on YouTube (links below), so in case you've missed them, nothing is lost (well, maybe for the ability to ask question, but I guess one can always reach out to Artem on Twitter). Please note that the links that Artem visited during the livestream are available for your convenience in each of the video descriptions on YouTube (if I missed anything please let me know).

• Windows Kernel Debugging - Part I, in which Artem shows how to configure your kernel debugging environment in several different ways, both including a virtual machine (with/without VirutalKD) and a second PC (controlled using Intel AMT and connected using various means, e.g. USB, Firewire or ethernet).

• Windows Kernel Debugging - Part II, during which Artem shows how to work with and configure WinDbg.

• Windows Kernel Debugging - Part III, in which Artem goes through the meanders of virtual memory and navigating through it using WinDbg. He also goes into the details of what's in a process and kernels virtual memory.

• Windows Kernel Debugging - Part IV, in which Artem showcases the physical memory and explains why a physical address is not always equal to RAM address, as well as ventures into the land of ACPI tables (if you're thinking about OSDev, you should check out this part regardless of whether you're interested in Windows kernel debugging or not). Artem also demos a hypervisor-level system debugger of his making.

On a more technical note, this was the first stream I've done with someone in a remote location (both the streams I've done with Carstein and lcamtuf were at my place), so at the initial concept phase it was a technical riddle that needed to be solved. There were two factors that came into play:

• First, I did not want to go the route of catching skype's/hangout's/your-favorite-video-conference-tool's window / sounds and restreaming that. I do believe that it may work rather well, but it seems to have many unnecessary steps in the middle. And the user has usually very little to say about the quality, codecs, etc. Though it must be noted that the capture→transmit→display lag is pretty small as these tend to be real-time communication tools.

• Second, Artem was already used to Open Broadcast Software, so we wanted to take that into account.

In the end what worked (and what surprisingly was also the first idea) was to use an RTMP restreaming server, i.e. Artem would connect to the RTMP restreaming server as the broadcaster and upload his OBS generated livestream there, and my OBS (using the Media source aka VLC plugin) would download it and embed into one of my scenes (so, to answer one of the questions that appeared on chat, no, Artem did not have to stream from my basement). This worked surprisingly well with about 2-5 second lag between Artem's action and me seeing it in OBS (where my OBS+YouTube added another 3-10 seconds before viewers saw the effect of an action).

However, given the total lag mentioned above (going into the 15 second territory in the worst case scenario) we also used a voice chat for synchronizing scene switches, so that Artem would know when his stream is live immediately as I switch the scene (and not after 15 seconds when he sees it on YouTube; it was a little easier for me as I did see the video signal he broadcasted in OBS preview with a much smaller lag).

All in all thanks for these streams, apart from learning quite a lot of cool tricks / details about WinDbg/kernel debugging/x86, I've also learnt a couple of useful tricks when doing live video broadcasting - this should give me more options to do livestreams with guests in the future. And I also can say that 4 displays which I'm currently using were barely enough to see all important windows (video previous, chats, OBS, music, voice+chat with Artem, etc) at the same time - I guess I've learnt first handed why real pro broadcasting crews have more monitors than NASA's space center ;).

So once again: thanks and kudos go to Artem! Having the opportunity I would also like to thank my livestream crew (especially foxtrot_charlie and KrzaQ) for their usual and irreplaceable help.

And that's it.