analyzing dumps

So I got some great help but looking at these files is tough. How do you go about analyzing one of these to figure out where the issue is? Is there a utility out there that helps or something that tells you where to look in the file? if you find the specific code on the blue screen it seems like there are a ton of articles on that 0000000x0x00 error or whatever it is and they are often different.

 

Learn assembly
Read Windows Internals until you understand it
Learn C
Get a copy of the intel developers reference
Write kernel drivers
Read Windows NT Device Driver Development

Practice for years by blowing your own machine up with your crappy code.

Nothin to it

Seriously, there is a lot of reading out there, but its mostly voodoo. The stop code and the 4 parameters means stuff, sometimes you can search on it, but at the end of the day, unless you are a programmer, you will never be good at it, the best you can hope for is !analyze telling you what to do

 

Is there anything that will actually analyze these dump files and give you an idea as to what it is? Other than coming here or searching google?

 

The debugger is always getting better, every new release has way more stuff in it, if you guy knew what i used to have to debug with, you would understand how advanced the software is now. The old debugger came with an oscilliscope and alligator clips In win95, you literally had to stick a paperclip in an ISA bus to short a pin set to use the debugger. rofl.

The two big things out there is !analyze -v and OCA, which my tool does for you automatically. If you had good knowladge of windows internals, and a little intel knowladge, !analyze can give you lots of advice. Sometimes its wrong, sometimes its close, and sometimes its dead on. In win2003 (and xp) the stop codes are pretty descriptive.

OCA is a MAJOR innovation. Otherwise known as Windows Error Reporting, or project bluescreen. When you machine crashes, it takes a minidump and sends it to microsoft. Those go into giant buckets sorted by unique mnemonics. Developers who own the component it crashed in, sift through these dumps and build logic, identifying solutions where appropriate, and modifying OCA behavior to collect the right things for analysis. As this evolves and gets more and more data, you will be more likely to get a solution, or at least guidance on how or what to troubleshoot. Read more about it here: http://oca.microsoft.com/en/welcome.aspx

What should I expect from the analysis?

Microsoft actively analyzes all error reports and prioritizes them based on the number of customers affected by the Stop error covered in the error report. We will try to determine the cause of the Stop error you submit, categorize it according to the type of issue encountered, and send you relevant information when such information is identified. You can check the status of your error report for 180 days after the date it was originally reported. However, because error reports do not always contain enough information to positively identify the source of the issue, we might need to collect a number of similar error reports from other customers before a pattern is discovered, or follow up with you further to gather additional information. Furthermore, some error reports might require additional resources (such as a hardware debugger or a live debugger session) before a solution can be found. Although we might not be able to provide a solution for your particular Stop error, all information submitted is used to further improve the quality and reliability of Windows.