Interview question of the week: How would you troubleshoot a blue screen of death?

We’ve all experienced the dreaded BSOD. If you’re applying for entry level IT work, you need to know how to diagnose and fix them. (Hint: guessing is not a good way to diagnose!)

Troubleshooting a BSOD is a hallmark of IT Support work. That’s why I’m always amazed at how few people I interview actually know the correct way to do it!

While asking this interview question, I’ve found that 95% of people use one of the following incorrect methods. (The other 5% troubleshoot correctly. They’re usually the ones that end up getting hired!)

  • The assumption method. Some folks assume they know the problem without needing to diagnose. They fix that and call it a day. “Oh, blue screens are always caused by the hard drive being corrupted. I’d swap it out. Done!”
  • The wild guess method. The person may not have any idea how to approach the problem, so they take random actions. “I’d replace the RAM. If that didn’t work, I’d swap out the hard drive.”
  • The overkill method. This involves a drastic measure such as re-installing Windows or issuing the user a new laptop.

I’ve gotten the above answers and their variations in scores of interviews I’ve conducted. But there’s really only one efficient way to fix a BSOD – you diagnose the problem and then fix it. There are many different tools you can use to do this, so try out a few and then pick the one you like. Type “BSOD analyzer” in your search engine of choice to get some ideas.

Once you’ve got your analyzer, dmp files, pronounced “dump” files, are your key finding out why a computer is blue screening. There are some things you should know about dump files. First, they’re timestamped, which is useful in getting a general sense of the scope of the problem. You may see more than one dump file per day for weeks in a row, for example, which is useful in letting you know how long an issue’s been going on. You also need to know that you’ll need to have admin rights to work with dump files. You also won’t be able to view them by simply opening them. (That’s what the dump analyzer is for.)

Once you’ve opened it, depending on your analyzer, you will see a lot of information. The error message is what you’re looking for. Some error messages are a bit misleading – for example, a memory leak may be caused by a bad driver; that’s not always intuitive. The dump file will include a file path, if applicable, to the file that’s causing your crash.

Oh look, it’s a driver issue! As the old GI Joe cartoons used to say: “Now you know, and knowing’s half the battle!”

So what’s a good answer to give during an interview? Here’s a sample answer:

“The first step I’d take is to look at the .dmp files. I’d go to c:\windows\minidump to find them. I’d then open them with a dump analyzer. From there, I’d find the crash info that Windows dumped at the moment it was crashing. Some error messages are obvious, but if it’s one of the less obvious ones I’d use Google to help me troubleshoot.”

I like this answer because it’s simple, to the point, and shows you know everything you need to know to effectively troubleshoot a blue screen of death.

Now go get that job!

With each post, I cover a new topic to help you get your start (or keep progressing) in your IT career with the ultimate goal of achieving financial independence. If it’s your first time visiting this blog, start here. Or, see all my posts about interview questions you should definitely be prepared for.

Author: Silicon Wanderer

I'm a merry wanderer on the path to financial independence through IT. I'm doing it, and I want to show you how you can to!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s