Lazybit

Earlier I explained how blue screens of death can be countered, today I will describe an alternative approach, which achieves the same result using different means.

Normally, the blue screen of death contains a driver name, and some addresses; if you're lucky, removing that driver will do the trick. But what if there is no driver name on the BSoD? And what if you don't have all the skills to play with crashdumps and debuggers?

In this case, Autoruns comes to the rescue. This is a graphical tool that allows you to disable/enable drivers in a very easy way.

The strategy:

1. Boot into safe mode (since the system is crashing when you attempt to boot normally);
2. Start Autoruns, and switch to the Drivers tab;
3. Go through the list, and uncheck the drivers that are suspicious;
4. Close the program, restart and boot normally

The steps above will be repeated until the system is able to boot correctly.

When that happens, remember what were the last changes you applied, and try to enable some drivers back - until you figure out which one of them was causing the issue.

The advantage of this method is that you can keep unchecking drivers without knowing what they do, because undoing any change is as easy as checking an item back (this is one of the coolest things about Autoruns).

What makes a driver suspicious?

When temporarily disabling a driver, you are not yet sure whether the driver in question is the culprit, so an educated guess is your best option. Start by unchecking:

• Non-Microsoft drivers (see the info in the Publisher column);
• Drivers that have a description that sounds like something you don't need;
• Drivers that don't have a publisher name, nor a description;
• Drivers the path to which points to an unknown location.

In the example above, I highlighted Private Disk's drivers, you can see the description and the vendor name - this illustrates how one can easily spot the modules related to an application.

Note: if you have a driver from 'Micr0soft' or "MlCROSOFT" (i.e. something that mimics the name of a well-known vendor), it is most likely a piece of malware, so you should not only disable it, but also figure out how it got in your system in the first place.

How to find the blue screening driver faster?

Usually one's technical knowledge provides sufficient data for a good guesstimate, but what if you have no clue where to start, and there are a lot of suspect items? In this case, try the binary search:

• Disable half of the items in the list of suspects;
• Reboot; if the problem persists - it is caused by an item in the other half;
• Go back, undo the previous changes and uncheck the items in the other half instead;
• Reboot; if the problem is gone - one of the disabled items was the problematic one;
• Go back, enable half of the half back;
• Reboot... repeat the previous steps.

The trick is in narrowing down the problem to as few items as possible. At each step the list of suspects is cut in two, so eventually you are left with one single item.

How to tune my Windows performance with Autoruns?

If you switch to the other tabs, you'll see a lot of other stuff that loads automatically when the system boots (drivers, services, applications in the registry, various shell extensions, etc). You can go ahead and uncheck the items that look suspicious - this will cut boot times, and make the system faster once it is loaded (since less stuff is loaded into RAM).

Beware of the fact that if you uncheck the wrong stuff, certain functionality will be lost, and the system may become partially unusable. Therefore be careful with the changes you apply:

• If not sure what an item means, look it up on the Internet;
• If something went wrong and you cannot boot, boot into Safe Mode and use Autoruns to check the item back.

Sometimes things go wrong, Windows crashes with a blue screen of death (also known as a BSoD), resetting the computer.

The blue screen contains some information about the cause of the error, often that information can help you solve the problem almost immediately. However, most systems are configured to restart automatically when a blue screen occurs, thus there is not enough time to actually read the text on the blue screen.

You're missing a great deal of data - the name of the faulty driver, the code of the error itself, and some addresses which might be useful later.

To prevent that from happening, Windows can be configured not to restart the system automatically when such a crash occurs. This gives you enough time to analyze the data on the blue screen and figure out whether something can be done about it.

To do that:

1. Open the System properties dialog (you can get there by pressing Win+Pause)
2. Go to Advanced\Startup and recovery
3. Press Settings
4. Uncheck Automatically restart

From now on, you'll have plenty of time to enjoy the view of the blue screen, it will be displayed until you press the reset button (laptop owners beware: if you don't have a reset button, you'll have to turn the system off, then turn it back on).

Basic troubleshooting steps

• If you're lucky, the blue screen will contain the name of the faulty driver, the one that caused the problem. Usually it is a *.sys file. Copy the name of that file and see if you can find any info on it on the Internet. Usually the first results will point you to pages which explain which program the driver belongs to, so now you know that you can boot into Safe Mode and remove the offending application.
• Alternatively, you may figure out that the blue screen started to occur after you've installed a particular program or a device driver - so obviously the first thing to do is try to remove that program and install a newer version.
• Microsoft provides a list of errors shown on the blue screen, as well as their detailed descriptions. It's a good idea to take a look at that list and find out the meaning of PAGE_FAULT_IN_NONPAGED_AREA or IRQL_NOT_LESS_OR_EQUAL

Minidump - what do I do with it?
By default Windows will create a minidump, and store it to %windir%\minidump. The minidump contains information about the state of the system before the crash; these data can be used to understand what caused the error, and how to fix it (once you find the offending driver, it's a good idea to contact the authors of that module and give them the minidump as well).

Note that interpreting a minidump is not easy if you are not an experienced developer. You are more likely to have a positive result if you try the tips described above. If nothing helps, get hold of the created minidump and send it to someone who knows what to do with it.

If you want to give it a try yourself, use Microsoft's Debugging tools for Windows. Once you run the debugger, go to File\Open crash dump, and then you're on your own.

How to enable minidumps
Some may choose to disable the creation of minidumps (to save space perhaps?), but they are very important when troubleshooting a problem. To enable the minidumps:

1. Press Win+Pause to start the System Properties dialog;
2. Go to Advanced\Startup and recovery;
3. Ensure that Write debugging information is set to Small memory dump (64 kb).

Happy troubleshooting!