And I can assure you that there were a number of MS research developed tools for finding memory bugs that have been used for decades at MS. There was never a don’t look / don’t fix policy while I was there. Quite the contrary.
Was there ever a time, apart from the short monthlong stint in 2001 after Blaster, when Microsoft developers worked on fixing memory related bugs?
Automated tools (before the advent of A.I.) can only get you so far. The bugs being found by A.I. today could've been found by eyeballs if companies thought it worthwhile.
When these tools were set up, on every code change you had to run these tools and deal with the output of anything it thought was a memory bug - part of the dev cycle before you could commit your code.
Did you have to scan the code looking for memory bug yourself with your eyeballs too? Yes, at every code check in you went through a paired peer code review before checking code in no matter your dev level. So two sets of eyeballs would look at every change.
So yes, we had to look for bugs in multiple ways no matter the type of bug on every single code change.
Then the testers would run all these tools and look at the output too (I was there when each org still had SDE Testers).
Did bugs still get missed? Of course, just like today even with today's new tools.
