Fixing BlueScreens in Vista
UPDATE Jan 8, 2008: v1 of this content is now published here . You can continue to provide feedback here on the blog, or via the KB comments. We'll update the content as needed.
My team is working with Dell support on some content to help consumers fix BlueScreen errors in Vista. We'd like your feedback!
You can review the draft content and comment there, or leave your comments and questions here in this post.
Keep in mind that this content is intended for a beginning user (maybe your mom, or your grandmother) or an intermediate user (maybe your 15 year old gamer son, or your cell phone geek daughter). So please don't recommend typing "!analyze -v" at the kd> prompt in the Windows Debugger! Dell already has that topic covered here for the real geeks! ;-)
Comments
- Anonymous
December 11, 2008
Best options are as follows in my mind:
- Just dont do this, its not a topic you can lightly scratch.
- If you're going to try and hit that group of people without leveraging the debuggger, then the best thing to do would be to leverage good troubleshooting techniques like clean booting, memtest, etc. Make sure they have steps to send the dump to OCA and know that if they do get a hit from OCA that it IS the fix for their issue.
- Show someone how to search our KB for common bugcheck codes.
- Make sure you mention for them to ask themselves "What changed?" and "When did this last work, or has it ever?" These are basically an add-on to number 2, but I thought they should be called out.
- I would consider something along the lines of having them install the debugger and search the .chm for the bugcheck code and the parameters so they might be able to narrow it down. Thats probably to deep though, even for PC Gamer kid.
- Anonymous
December 11, 2008
Thanks Joscon! Agree #5 is too deep for my mother! ;-) But note that you don't have to install Debugging tools to get the .chm info on bugcheck codes. Here's the MSDN link: http://msdn.microsoft.com/en-us/library/ms789516.aspx But I wouldn't refer my mother there either ;-) I'm also skeptical of #3 as a general troubleshooting tip for consumers. KBs typically document very specific root causes, so the chance of them finding a KB on a STOP 0xA error that applies to their particular Stop OxA error is probably remote. And it's not really possible for a consumer to verify that the issue documented in any particlar Stop 0xA KB actually applies to them. That's why Step 1 is Windows Error Reporting (let us match your error to a specific KB, update, etc and give you the direct link). Keep the feedback coming folks! This is great stuff!