Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Posts Tagged ‘Crash’

Unraveling and Resolving An Outlook Crash with Process Monitor

Posted by William Diaz on March 2, 2012


While trying to import documents into our document management system via Outlook, Outlook would just abruptly close on the user. I started the initial troubleshooting by disabling a couple 3rd party add-ins in HKLM and HKCU\Software\Microsoft\Office\Outlook\Addins that were not part of the normal image. This can be done by modifying the load behavior of the add-in (see this MSDN article for details), but this had no effect on correcting the behavior. I thought about capturing a crash dump of Outlook but decided to not waste any time there because, at this point, with the add-ins disabled, I likely was not going to see anything but the document management modules in the dump.

Instead, I turned to Process Monitor; perhaps it might reveal what Outlook was doing just before it crashed and give me some important clues. I set a filter to monitor only outlook.exe, dragged an item into the document management space in Outlook and waited for it to crash after clicking Save. Afterwards, I scrolled to end of the log, working my way up. I also added a filter to only include registry activity and then process and thread activity so I could quickly see where Outlook was crashing: Read the rest of this entry »

Advertisements

Posted in Office, Troubleshooting | Tagged: , , | Leave a Comment »

Dealing With An Un-Killable Process

Posted by William Diaz on February 9, 2012


The other day while trying to remove some add-ons from Internet Explorer, Windows DEP was kicking in and closing the IE Setting control panel box (rundll32.exe process) for whatever reason:
image
Or at least it was trying to. Read the rest of this entry »

Posted in Troubleshooting, Troubleshooting Tools | Tagged: , , | Leave a Comment »

When A Process Does Not Exit Normally

Posted by William Diaz on November 28, 2011


i.e., it crashes.

When processes exit, they should exit with a status code that indicates whether or not it exited gracefully or abnormally. This comes in helpful when you need to examine large Process Monitor logs and want to isolate the time of the crash. Simply filter for Process Exit:
Read the rest of this entry »

Posted in Inside Windows | Tagged: , | 1 Comment »

Resolve That Application Crash The Easy Way

Posted by William Diaz on October 14, 2011


Sometimes Microsoft applications do a a good job at identifying the problem module when they crash. For example, in the Windows Vista/7 OS IE crashes with “Internet Explorer has stopped working”. Simply click the Details chevron to and look at the Fault Module Name:
SNAGHTML1b8ce9d
Read the rest of this entry »

Posted in Troubleshooting | Tagged: , , , | Leave a Comment »

Your Hard Disk is Failing

Posted by William Diaz on October 5, 2011


Sometimes a BSOD is not a sign of a software issue but instead points to a hardware problem and might help explain the symptoms of bad system performance. That was the case recently when a user complained that she was having troubles trying to logon. The workstation was amazingly slow (can slow be amazing?) and then blue-screened on her randomly. My co-worker was handling this but he happens to sit right next to me and I jumped in when I heard the words “blue screen”. I unkindly interjected with “Lets get a minidump.” While he chatted her up, I went about getting her IP, connected via the UNC, went into C:\Windows\Minidump and grabbed the last two mini dumps for that day.

Minidumps excite me. To understand why, you need to have come across a great amount of support calls that usually end up trumping first tier technical support. Often times, these issues are too vague to narrow down if you don’t know how to handle a BSOD, and the incident remains open longer than it needs because it can’t be explained or reproduced immediately. The mini dump provides a means to sometimes quickly resolve what might otherwise become an unexplained system problem.

Minidumps are small, too. Between 64 and 256KB, they only record the smallest set of useful information that could help identify why the system stopped unexpectedly so there would be no problem copying from over a WAN. Once copied over to my workstation, I opened with WinDbg, clicked the !analyze -v  hyper command. Both dumps produced identical results: Read the rest of this entry »

Posted in Troubleshooting | Tagged: , , , , | Leave a Comment »

Dumping A Thread to Find An Exception

Posted by William Diaz on August 3, 2011


Before any basic crash analysis, I always turn to the Windows Event view to find signs of problem. In the case here, the problem manifested itself as Outlook crashing when the user opened a particular Outlook form. Looking at the Windows Event Viewer, we see an application event for Outlook:
Read the rest of this entry »

Posted in Office, Troubleshooting | Tagged: , , | Leave a Comment »

Associating a Crashing Print Driver to a Printer

Posted by William Diaz on May 12, 2011


In Windows XP, if you have Dr Watson set as your post-mortem default debugger (by default it is) it usually does a good job at catching exceptions when the Windows print spooler, spoolersv.exe, crashes*. Most print spooler crashes are the result of a print driver. Finding the problem print driver is a simple matter of going into the drwtsn32.log and finding the thread that contains the FAULT, literally:
image_thumb_3215244D
A user.dmp is also created in the DrWatson folder. This dump file offers more details and confirms it is a print driver but requires the Windows Debugging Tools to analyze. Resort to the user.dmp if the log is not revealing enough: Read the rest of this entry »

Posted in Troubleshooting | Tagged: , , | Leave a Comment »

Don’t Dismiss That Error

Posted by William Diaz on April 28, 2011


Instead, click the click here:
MOOErr1 Read the rest of this entry »

Posted in Office, Troubleshooting | Tagged: , , | Leave a Comment »

Out With the Old, In(stall) With the New

Posted by William Diaz on April 12, 2011


It’s not uncommon for outdated drivers to have a negative impact on user applications. Without knowing how to do some basic crash analysis, finding an outdated problem driver can be quite daunting when you consider how many drivers there are on the average system. However, you can simplify this by looking for or obtaining a crash dump of the application.

In the case here, we have a user complaining of frequent crashes while working in Adobe Photoshop. This is an XP system so I am hoping that Dr Watson, the default post mortem debugger*, is capturing the crash. I ask for the computer name and UNC to the location where the drwtsn32.log and user.dmp files are written when an exception is caught; this can be found in \Documents and Settings\All Users\Application Data\Microsoft\Dr Watson. Both files are there and have a recent modify date-time, and I copy both of these to my system for analysis.

Because Photoshop is primarily graphics, I am guessing we might find a graphics driver somewhere in either file along with an exception. I start by opening the drwtsn32.log, a plain text file that records a history of all the crashes it captured. The file is read from the bottom since this is where the latest information is added. From there, I do a text search going up for the word application to verify that Photoshop is the crashing application:
Read the rest of this entry »

Posted in Troubleshooting | Tagged: , , | Leave a Comment »

A Faulting Module Is Not A Broken Module

Posted by William Diaz on January 14, 2011


It is not usually the case that a “faulting” module is the actual cause of an application error, crash, or hang. Take this example where Outlook was crashing each time after the user opened Outlook: Read the rest of this entry »

Posted in Troubleshooting | Tagged: , | Leave a Comment »