Resolve application and Windows Vista crashes

jjones | Guides | 07/10/2008 10:57am
3 Comments

We all wish that Windows Vista and all applications would work for ever without any issues, but the fact that there is an icon for Problem Reports and Solutions tells us that these things do happen. Sometimes they might be small problems with applications and sometimes it might be a catastrophic system failure that causes everything to stop and the blue error screen – a blue screen of death or BSOD – that requires the PC to be rebooted. Luckily, Windows Vista records information that can help you diagnose the problem and start resolving it.

The most common crashes you see are when an application shuts down unexpectedly and you get a message from the application or Windows telling you this has happened. On Windows Vista, system crashes or BSODs are rare, but still happen and are – in my experience – almost always caused by bad drivers or failing hardware. For either type of crash we need to start by enabling and examining the reporting tools and then using the information shared to get to the solution.

To get the information about a crash we need to ensure that your PC stores this information and that you know how to examine it. To confirm this, look at Problem Reports and Solutions for application error reporting, and enable Kernel memory dumps in the Write debugging information configuration controls. For the dump to work, you also need a page file on your system drive (normally your C drive) that is a few megabytes larger than your system memory, because this is where the crash dump is written in the event of a BSOD.

CRASH TEST You can see when and how often your machine is crashing using the Reliability Monitor.

Crash, no burn

When something crashes, notification of this can be seen in the Reliability and Performance Monitor as Application, Windows or Miscellaneous failures, marked with a cross. If you’re seeing regular crashes, go to Problem Reports and Solutions and select See problems to check > Check for new solutions to report the issue. Some of the issues are
diagnosed here and a solution recommended. In these cases, following the instructions will end your crashes.

If you are now in a situation where you still need to do more digging, we need to look at the problem history andsee if the crashes have anything in common. Failing hardware often causes random and disparate failures, so if the problems have a level of consistency, it is more likely to be a software problem. Looking in Problem Reports and Solutions, there is a Problem History section. Here you can see each crash and can examine it by double-clicking on it. By looking at the signatures, you should be able to see if the problems are consistent or not. If not, I would recommend a memory and disc scan.

Assuming that you now have a list of consistent, unresolved issues, you need to identify who owns the programs or drivers that are causing issues and see if they have been fixed. The information on a crash in Problem Report may only contain the application name and some basic information, but no crash dump files. In this case you can start by working out who produces the application and contact the support teams to request assistance. I often simply put a few items of the crash details into a search engine, and this gives a good idea about who to contact for support. While this is not 100 per cent certain, it is simple to start and others can offer good guidance.

IN A FIX Windows Vista can check for solutions and inform you if fixes are available

If the problem is still unresolved, we get to the hardest group – system failures and applications that have produced a crash or memory dump. To analyse these we need to download and install the debugging tools from Microsoft, at tinyurl.com/2zost. By using the WinDBG tool we can process the memory dump file and start to get pointers as to who owns the problem code and what went wrong. Where bad device drivers are causing system crashes, you can normally find out which driver is causing the problem, search to find out who owns it and then start talking to their support teams to get updates. In the worst case scenario, you should look to replace a piece of hardware whose drivers are causing problems with one that has a Windows Hardware Quality Labs approved driver. While application crash dumps can be found using the Problem and Solutions tool, the crash dump from a BSOD canbe found at C:\Windows\Memory.dmp.

We have only just begun examining the tools used for diagnosing crash dumps, but this is quite a complex area. Once again, I have more information on my site at davidoverton.com.

Ensure your PC captures failures

Only if your PC captures crashes can you do anything about them

1 REPORT A PROBLEM Ensure that problems are recorded and reported using Problem Reports and Solutions (Control Panel > System and Maintenance) then choose Change settings > Advanced settings. Make sure that problem reporting is on.

2 PICK A FILE SIZE Go to the System Settings and note how much memory you have. Open Advanced System Settings, then the Advanced tab, Performance settings > Change and ensure that the paging file size on your C drive is more than your system memory.

3 MAKE A MEMORY Save those settings and click OK to get back to the Advanced tab, and this time click Startup and Recovery Settings. From here you can ensure that a kernel memory dump is created in the event of a system error.

How to debug a crash dump file

Use the debug tools to learn more about system crashes

1 DOWNLOAD DEBUGGERS Go to tinyurl.com/2zost and download and install the latest debugging tools. If you have Windows Vista 64-bit edition you need the x64 tools, otherwise you need the x86 versions.

2 OPEN THE FILE Now you have the tools, you need to get a dump. Do this by finding debug data in an application crash report or, if a system crash, by loading C:\Windows\memory.dmp. Start WinDBG (from Start Search) and go to File > Open Crash Dump. If you’re opening the memory.dmp file, you need to start the program by right-clicking and selecting Run as Administrator.

3 ISSUE COMMANDS Once the dump file is open you need to issue three commands. The first command points to debug information on the internet, called symbols. The second command loads them and then the final command performs the first step of analysis. They are .symfi x, .reload and !analyze –v.

4 USING THE INFORMATION Once the analysis has finished, you should see the application and DLL names that have caused the problem. This gives you the ability to follow up with the company who owns it, remove the application or delete the programs associated with it.

5 SEARCH ONLINE Often, knowing exactly what to do with an error is difficult, in which case the simplest route is to search for the term online. In this example, it turns out that Microsoft has a patch out for the DLL that is causing me problems.

Add to del.icio.us | Digg This Article | Add to StumbleUpon

This entry was posted on Tuesday, October 7th, 2008 at 10:57 am and is filed under Guides. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a comment, or trackback from your own site.