Looking for suggestions about the future of the DRT and other stuff

[usasma]

Recently we've seen that there are some specific conflicts between 3rd party drivers that could cause cause BSOD issues.
The most current one is here (between ESET and SandBoxie): http://windows7forums.com/blue-screen-death-bsod/84555-bsods-shortly-after-startup.html#post272422

I don't want to play the blame game here - but I do want to make sure that the DRT reflects enough information so that users can easily find out about these conflicts.

In the above case it's easy to just make a note on the SandBoxie drivers that it conflicts with ESET. We see far fewer instances of SandBoxie drivers in the memory dumps than we see ESET drivers. But this prevents those looking at ESET drivers from seeing the conflicts. I'm looking for some way to annotate this without overwhelming every driver with note about conflicts.

My immediate reaction is to ask for another column to be added to the Driver Reference Table - one labelled "Known Conflicts" with a large text field associated with it. But this brings up issues of how and when it's going to be displayed - and how we are going to populate it's entries.

So, what I'm looking for is suggestions on how to implement this within the DRT - and suggestions on how it should be structured (what information we should include).
*****************************************************
Next is, what should we do to proactively find these conflicts? There are many, many drivers that we know of as "bad", that continue to work flawlessly on a number of systems. In particular I note the infamous 2005 version of ASACPI.sys. Even though we associate it with BSOD's, it's been flawlessly operating on both my Win7 and Win8 systems since they first came out. Why do others have problems and I don't?

I suspect it's the same reason as the previous discussion - that there's conflicting 3rd party drivers.
So I'd like to figure out how to identify those other drivers.

My suggestion here is some sort of database that compares the incidence of a known problem driver with other drivers that appear in memory dumps. For example, the database would give us a % of incidents where both ESET and SandBoxie were involved in the same BSOD. A higher % would be a cause for concern (just as we note that older drivers are a cause for concern).

We could initially point this tool at the known BSOD causes that we've all spotted (Daemon Tools, Riva Tuner, AMD Overdrive, etc) and find out what programs seem to be associated with these crashes. This may give the user a choice as to which program to get rid of - but it would also increase our chances of success when trying to solve BSOD issues.


But this would involve collecting driver lists from memory dumps in large quantities - and then subjecting them to analysis. I'm way out of my depth here and would appreciate any discussion about this!

 

[Vir Gnarus]

I'd be wary about relying on generating basic mass analytical statistics in order to point blame at specific drivers, as people will attempt to self-diagnose just because two drivers listed happen to be on their system and they'll start cleaning house and not exactly fix the problem. My personal recommendation would be something similar to like file.net which offers user comments and rates based on them. Granted, that site has a lot of false positives because the comments are coming from inexperienced people and often based on bias or dubious speculation, but the comments afford a lot more than a simple rating metric or list of potential conflicts because they do add that element of description given by user experience.

Though it's flaw for that site because it often harbors user ignorance, if there's a way to set up something similar for DRT to only honor submissions from trust sources (tech supports from various forums), who can submit based on their resolutions by fixing such conflicts, then we'd have a reliable source to provide statistics based on reliable data and not from something as errant as module lists from crashdumps. Of course, this is quite a task to surmount and I'm not sure if it's feasible now especially given the politics between some of the larger tech support forums and here, but it's definitely worth noting.

So yes, the point you've made is well made, but just be careful what the source of the data is. We shouldn't provide a service that will cause people to reduce their own systems to a wreck by uninstalling and cleaning drivers and apps without fixing problems, as it runs contrary to the analytical service we provide through having a support forum with technical experts. Rather, the DRT should be a service that runs complimentary to the forum as it was originally set out to do, and if it means providing a repository on previous cases and solutions for drivers, all the better. Since the forum is fueled by technical knowledge, the DRT should reflect that knowledge in its entries, and not run contrary to it by being based on rudimentary statistics and data collection. I'm not really saying such collection is bad, but rather if it's the only element provided in the DRT.