Windows 7 went on sale today.
I’m enormously pleased about this because for the last two and a half years I’ve been working as a Software Development Engineer in Test (SDET) on the Windows Fundamentals Reliability team. I joined the team (and Microsoft) right as Windows 7 development was getting underway and have been immersed in our work on it ever since.
Throughout the development cycle the Reliability team was responsible for driving reliability improvements across Windows as a whole. We tackled this with a range of approaches, one of which was implementing new reliability-related features within Windows. I owned the testing responsibilities for three of these. All three are low-level infrastructure features that won’t be mentioned in an ad campaign, but each has been given some level of exposure as Windows 7 architecture has been discussed and reviewed in the run-up to its release.
RADAR – Automatic memory leak detection
RADAR automatically detects memory leaks in processes running on a Windows 7 system. Most of the public documentation about this feature is an interview that three of my colleagues and I gave to MSDN’s Channel 9. We got to dive into RADAR’s architecture and the impact it has had on Windows 7 throughout its development. The C9 page for the interview has a nice summary of RADAR:
RADAR is a memory leak detection technology built into Windows 7 and integrated with Watson (error reporting) and AutoBug (automatic bug filing). It allows Microsoft product teams and third parties to discover and fix memory leaks early in the product cycle and after release. Since RADAR runs on customer machines, leaks can be caught during public betas, after release, and by third parties, thus ridding the entire ecosystem of memory leaks. RADAR-shipped components are highly optimized to have no appreciable performance impact.
The talk is archived here: Inside Windows 7: RADAR – Windows Automatic Memory Leak Detection.
Fault Tolerant Heap (FTH)
Fault Tolerant Heap (FTH) was, in a lot of ways, the most fascinating of all three features to work on. FTH monitors application crashes on a Windows 7 system. When it thinks it can help FTH applies mitigations on a per-application basis to try to prevent future crashes. The development lead for the project, Silviu Calinoiu, did a great interview with C9 that went into detail about how exactly FTH goes about its crash prevention.
Silviu’s talk is archived here: Silviu Calinoiu: Inside Windows 7 – Fault Tolerant Heap.
One potential complication for FTH is that developers who are working on a new app may not want FTH’s help – they want their test app to crash so that they can find the problem and fix it. MSDN has a page that discusses how devs can check whether FTH has been enabled for a particular app and, if they choose, disable FTH entirely on a test machine. See here: Fault Tolerant Heap (Windows).
Process Reflection
Process reflection is a way for a monitor application to clone, or reflect, some target process. Once the operation is complete the clone, or reflection, process has a complete copy of the original target process’s address space which can then be analyzed or dumped to disk for later analysis. Even better, the target process doesn’t have to be suspended or terminated to be reflected which makes process reflection tremendously useful for gathering data from long-running processes like background services or the user shell. Mark Russinovich briefly discusses process reflection and shows a nice demo of it in action in another C9 talk that just went up today: Mark Russinovich- Inside Windows 7 Redux. He starts talking about process reflection at around the 31:00 mark. He also updated his SysInternals procdump tool to optionally use reflection for creating dumps. The updated procdump is available here.
It’s been a tremendously satisfying and humbling two and a half years working on Windows 7 together with a great set of colleagues from all over the world. I can’t wait to see what the next two and a half years will bring!