View RSS Feed



Rating: 2 votes, 4.50 average.
Just trying to firm up my "intent".........

My primary purpose/goal is to help users.
There is (IMO) a need for BSOD analysts to help users with their BSOD problems.
This differs from standard BSOD analysis in 2 ways:
- there is little need to disassemble instructions to see where a program/driver went wrong. It's enough (for our purposes) to know that the program was at fault. In most cases we don't even have the skills to repair the problem, relying instead on removal and reinstallation to "repair" the problem.
- There are problems that occur frequently in BSOD situations - but aren't collected anywhere. Things like the ASACPI.sys driver problem, or the Daemon Tools issues. They affect a relatively small proportion of the users of that program - but when they do, they are a real problem. The skills of a user-level BSOD analyst must contain a "record" of these problems.

That being said, there is a need for the user-level BSOD analyst to be familiar with disassembly, as some of it's tools are useful in determining sources of errors.

When I started user-level BSOD analysis, it was primarily guess-work. Reading a memory dump and it's !analyze -v output for clues. And then asking the user to attempt to fix the things associated with the clues.

As I became more familiar with this, I found out a couple of things:
- a consolidated reference for BSOD information was needed. was a good source, but it stopped being updated in 2007. So, in 2009, I created the [url][/url] page

Next was the lack of a place to put info about BSOD causes. That was (IMO) a major reason that there weren't many user-level BSOD analysts - too much stuff to remember, and you needed too much experience just to get to the point where you remembered it. So along came the Driver Reference Table (DRT).

Initially it was a simple thing, designed primarily to help users find drivers for their BSOD problems. It's precursor, the Drivers and Downloads page ( [url][/url] ) was too limited to be of any significant use. The DRT provided a place where we could link as close as possible to the download site for the program associated with an individual driver.

Early on we saw that there was also a need to store information that would help others research problems - so we added that as a second goal: Helping other user-level BSOD analysts to locate information on needed drivers.

As the project grew, so did the number of people involved. And thanks to jcgriff2, Laxer, and several others the input of drivers to the table (and accessing the data in the table) has become much easier.

But it still remains primarily a resource for users and for those helping users.

2 questions then:
- Where do we go from here with the current projects?
- What other direction(s) are there that we might want to consider going in?

Submit "Concepts" to Digg Submit "Concepts" to Submit "Concepts" to StumbleUpon Submit "Concepts" to Google Submit "Concepts" to Blogger



  1. MvdB's Avatar
    In my opinion, you've correctly summarised both the fact that (luckily) there are good people out there willing to freely help others, even people unknown to them. These projects also prove that collaboration can get you (us, or any group of people) a long way. I don't want to state this as something that is easy, but in a certain sense, these projects could be classified as collaboration with some additional tools (knowledgemanagement type of tools) that we design to make our work easier. That is also, imo, the answer to your last question. If I draw a parallel on how we [I]used to[/I] repair hardware like a TV: we would measure stuff on individual transistor level (yeah, i know, some will laugh at my age now :hysterical:) but nowadays we identify, quite easily, the faulty module and don't look any further but just replace the whole thing. Sometimes helped by the indicators in the modules themselves. I think we will see similar progression in the combination of computerhardware and the OS + drivers. For those of us who know something about the not so old theory of the OSI model... I think we'll see a growth of 'modular intelligence' in the functionally higher layers of that model.
    We already see examples of that in Telecoms for example. HW/SW elements in glassfiber comms are already capable of announcing, ahead of time, that they are about to fail...but in time for someone to take corrective measures. I think similar examples will be developed in our area of HW/OS/Driver area that account for most of the BSOD causes....
  2. usasma's Avatar
    Thanks MvdB!

    I grew up listening to Dad talk about vacuum tube technology at the dinner table. Transistors came about as I was entering the workforce - and Dad was one of the leaders in the field at that point. I have a picture of him holding up a circuit board about 12" x 8" that holds an amazing 8kB of information!

    Can you suggest some collaboration software that either contains the knowledge management tools, or can accept them as "plugins"?

    As for failure awareness - where can we take that at our level? I guess what I'm trying to say is that I'd like suggestions for how to proceed in the near-term. Those directions will (if properly implemented) help us focus the direction that the community takes.

    So, my restated intent is:
    - to help increase the usefulness of the Driver Reference Table, Blue Screen of Death Index page, and other resources that we manage for the community.
    - to develop vision and direction suggestions for the community in order to help ensure both it's near-term usefulness along with it's long-term growth and usefulness.

Log in

Log in