This is true, but often it's because PC environments - being as complicated as they are - can often lead to conflicts where eliminating one element from it will resolve the symptoms, but the actual problematic code may still be residing there on the system, with the capacity of resurfacing at any time. AVs are typically blamed because they show up on crashdumps often due to their nature of using extensive filter drivers
, and while there are cases where they do genuinely cause a crash, a lot of spite towards them ends up being due to a lack of understanding on what exactly is going on. I'm just making an effort to try and avoid using a blanket explanation like that and try to assert the possibility that conflicts like this can - and often do - occur, and that it's best practice to try an ascertain exact cause before making immediate assumptions on a suspect.
Of course, without access to resources like a kernel dump, as well as the knowledge to utilize them efficiently, that endeavor becomes difficult or impossible. Should this happen, one will have to compromise.
Anyways, aside from the rant, a solution does look present. It's nice to know progress has been made on the diagnosis in which before it looked like a graphics card/driver
issue has been narrowed to a buggy filter driver. At least, so far that appears to be the case.