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:
Or at least it was trying to. Read the rest of this entry »
Posts Tagged ‘Crash’
Dealing With An Un-Killable Process
Posted by William Diaz on February 9, 2012
Posted in Troubleshooting, Troubleshooting Tools | Tagged: Crash, Dr Watson, Hang | 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: Crash, Process Monitor | 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:
Read the rest of this entry »
Posted in Troubleshooting | Tagged: Crash, Hang, IE, Word | 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: BSOD, Crash, Dump, Hardware, WinDbg | 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: Crash, Outlook, WinDbg | 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:
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: Crash, Dr Watson, Printing | Leave a Comment »
Don’t Dismiss That Error
Posted by William Diaz on April 28, 2011
Instead, click the click here:
Read the rest of this entry »
Posted in Office, Troubleshooting | Tagged: Crash, Dump, Office | 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: Crash, Dump, WinDbg | 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: Crash, Outlook | Leave a Comment »
Deleting the Word "Data" Key–What Does It Mean, Anyway?
Posted by William Diaz on November 19, 2010
The term corruption gets thrown around way too-often without actually knowing what it means or how it happens. If you troubleshoot Word often, all of us at one time or another have had to delete the Word Data key from the Windows Registry in an attempt to correct some problem. But what are you actually doing when you delete this key? To get an idea, visit the Word MVP site and read this: http://word.mvps.org/faqs/customization/DataKeySettings.htm
You should also familiarize yourself with the following Microsoft KB Article that covers the Word data key and a few other keys: http://support.microsoft.com/kb/921541
If you bother to look at the registry values you will see they are unreadable,but if you open the Settings REG_BINARY and scroll down you will see readable text, which contains, among other things, data to Word .dot files.
When we say that the Word data key is or may be "corrupt" this could mean that information here is referencing non-existent/moved data or problem add-ins, like templates. In fact, to demonstrate what a corrupted Word data key can do, I opened both REG_BINARY types and edited the data by typing gibberish into them. When done, I opened Word and produced the following:
Posted in Troubleshooting | Tagged: Crash, Word | Leave a Comment »
