Posts Tagged ‘Dump’
Posted by William Diaz on July 25, 2012
This is an XP workstation so likely the post-mortem default debugger is capturing the exception. I UNC-navigate to \\computername\Documents and Settings\All Users\Application Data\Microsoft\DrWatson. I grab both the drwtsn32.log and user.dmp files. They have recent time stamps of the day before which means that they were likely created as a result of the issue the user was experiencing. I start by examining the log file, starting from the bottom working my way up. The user’s initial complaint was the IE was crashing when going to various websites. I expected to find iexplore.exe process crashing in the log. A few searches in the text file later, I find IE crashing on that day:
|
Application exception occurred:
App: C:\Program Files\Internet Explorer\iexplore.exe (pid=6828)
When: 7/24/2012 @ 11:28:13.701
Exception number: c0000005 (access violation)
|
Read the rest of this entry »
Posted in Troubleshooting | Tagged: Crash, Dr Watson, Dump, Malware, Process Explorer | Leave a Comment »
Posted by William Diaz on July 14, 2012
Often times when doing some basic crash or hang analysis on a program, !analyze –v is not going to cut it because the heuristics engine is not going to reveal an interesting stack. Or maybe I don’t know what I’m looking for. Or maybe I don’t know advanced WinDbg debug techniques. Or … whatever. I define an “interesting” stack is one that contains unexpected components. If I don’t see it, I usually move on to some other techniques.
One of the things I try when a dump has nothing to offer me is to just take a look at the last error thrown. To do this, simply employ the get last error command, !gle. For example, an Outlook crash (which can be notoriously difficult to analyze even for the advanced Windbg enthusiast) I was asked to examine where the !analyze –v heuristics engine wasn’t telling me anything meaningful (at least to me) and where !gle might help:
Read the rest of this entry »
Posted in Troubleshooting | Tagged: Crash, Dump, WinDbg | Leave a Comment »
Posted by William Diaz on June 1, 2012
This was initially described as a log off each time the user opened Outlook. This was the first time I heard of Outlook logging someone off their system when it was opened. This sparked my curiosity, of course, so I asked the techs working on this to leave it alone until I had a chance to look after hours. I started by connecting remotely to the Windows Event Viewer for the problem workstation to see if anything obvious stood out. After about a minute, the MMC console became hung and I could no longer browse events. I thought maybe the workstation became disconnected from the network, so I waited and tried again a few minutes later. I resumed browsing the event logs … only to get disconnected again. Logging in via RDP or VNC was also a no go, as I was getting disconnected after about 2 minutes, barely enough time to get pass the initial desktop and application loading and analyze what was happening. My next approach was to query the workstation for all the running processes via PsList from SysInternals (using the Front End for PsTools); maybe something might stand out and allude to what was happening:
Read the rest of this entry »
Posted in Troubleshooting, Troubleshooting Tools | Tagged: Autoruns, Crash, Dump, Malware, WinDbg | 2 Comments »
Posted by William Diaz on May 18, 2012
Not all issues I troubleshoot are at work. Sometimes I might be sitting at home and then this somewhat buggy application starts up. It’s a random occurrence and trying to resolve its problems can be very taxing. The main reason for this is I don’t have the source code and trying to reverse-engineer it is nearly impossible because it’s data structures are not logical. But maybe we can look at its crash dump and find out what’s happening.
Looking at the dump:
Read the rest of this entry »
Posted in Troubleshooting | Tagged: Crash, Dump, WinDbg | 2 Comments »
Posted by William Diaz on May 7, 2012
One of our helpdesk technician’s in a remote office reached out to me recently and asked me to assist with an application that suddenly started crashing on him with the following error: “Microsoft Visual C++ Runtime Library. Runtime Error! This application has requested the Runtime to terminate it in an unusual way…”
Posted in Troubleshooting, Troubleshooting Tools | Tagged: Crash, Dump, Process Monitor, WinDbg | Leave a Comment »
Posted by William Diaz on May 7, 2012
I recently put together a quad core system from parts my brother was retiring from his home system. Soon after getting everything up and running, the new system would sometimes hard hang while working via VPN. A hard hang is when the OS becomes completely unresponsive but is still running. I had earlier prepared myself for the next instance of this encounter by enabling CrashOnCtrlScroll in the Windows registry so that the next time it happened I could manually crash the system from the keyboard and examine the memory dump with WinDbg for signs of the responsible culprit. You can read about how to enable this option in this earlier blog Forcing a System Crash on an Unresponsive PC.
Upon opening a kernel dump, the analyze –v command is a clickable hyperlink1.
Posted in Troubleshooting | Tagged: Crash, Dump, Hang, WinDbg | Leave a Comment »
Posted by William Diaz on May 2, 2012
A couple weeks ago a co-worker asked me if it was possible to recover text from a hung application. The user had spent a good amount of time typing into text field and upon trying to submit the information, IE became hung and would not recover. The user didn’t want to have to retype everything from scratch again. The short answer to this is yes. The long answer is “Yes, if you can be patient.” I have never actually needed to perform this myself because it’s not always that practical and, to be honest, the task can be somewhat tedious. But if you really need to recover text and Word didn’t auto-recover or Outlook lost the draft after you clicked send, or IE is in the process of a “GUI crash”, then turn to the power of the dump.
The idea here is if the application is still running but stalled, it still resides in memory, along with anything you typed into it. When you dump the process, you are dumping its presence in memory to a file that you can pick apart. Dumping a hung process is simple enough. On an XP system, open Process Explorer, right-click the process, and choose Create Dump. In Vista & Windows 7, this option is now built into the Task Manager. You can then copy the dump to a system where WinDbg is installed to open it.
Posted in Troubleshooting Tools | Tagged: Dump, Hang, WinDbg | Leave a Comment »
Posted by William Diaz on February 8, 2012
After loading up Word today, I noticed it would become hung each time I went to the Insert tab. I was able to reproduce the behavior after killing the process and starting it up again. To troubleshoot, I started by going to the Windows 7 Task Manager, right-clicking, and selecting Create Dump File from the context menu:
Read the rest of this entry »
Posted in Troubleshooting, Troubleshooting Tools | Tagged: Dump, Hang, WinDbg, Word | Leave a Comment »
Posted by William Diaz on January 9, 2012
The initial issue I was asked to look at started with Internet Explorer failing to gracefully exit. Instead, it would just hang and required manual intervention via the Task Manager to kill the iexplore.exe process. I connected remotely to the workstation and ran Process Explorer so I could examine IE’s threads for anything out of the ordinary. Sure enough, I saw the presence of a .tmp file:
Read the rest of this entry »
Posted in Troubleshooting | Tagged: Dump, Hang, Internet Explorer, Process Explorer, Process Monitor, WinDbg | 5 Comments »
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 »
