The dreaded blue screen of death (BSoD) has been around since Windows 95. It is scary in a way that this blue screen can happen anytime without the user expecting it and there is no way to recover from this blue screen other than restarting the computer. Obviously the biggest problem is actually when you are working on something important and haven’t got a chance to save it. An unexpected blue screen will just cause you to lose all or some parts of your work depending on how often it is being saved. Other than that, the blue screen on an older Windows does look a bit scary with all the text and technical information on screen. Fortunately the blue screen on Windows 8.1 doesn’t look so frightening.
Anything can cause a blue screen in Windows. It can be from an unstable driver for a hardware device, 3rd party software such as an antivirus/firewall, or even a rootkit based malware. It can also be caused by an attacker exploiting or in another word “nuking” an unpatched Windows. Hardware such as memory, CPU and motherboards that are failing can also randomly cause blue screen.
Searched for 'load dump file mysql' and the first result was: After using mysqldump, how can I load dump file back to database server? How can I back up a MySQL database? May 25th, 2003 03:09 Read the manual on mysqldump, especially option -opt. Also, check the section 'Database backups', under 'Solving common problems with MySQL'. To change the folder location for the small memory dump files, type a new path in the Dump File box (or in the Small dump directory box, depending on your version of Windows). Tools to read the small memory dump file. You can load small memory dump files by using the Dump Check Utility (Dumpchk.exe).
If the blue screen is caused by software, an inexperienced computer technician will have to spend more time to determine the culprit by going through the process of elimination of disabling all 3rd party programs that startup automatically, enable them one at a time and test until they experience the blue screen. However with the right tools in hand, it can quickly reveal which software is possibly causing the blue screen so you can work towards fixing the problem. Here we have 3 free software that can do that.
1. BlueScreenViewBlueScreenView is a small and portable tool developed by NirSoft that is capable of quickly showing you which file caused the blue screen. All you need to do is download the program, run it and it will automatically analyze the minidump files that are created during the blue screen. The top pane shows the dump files while the lower pane shows the offending files that caused the crash. If the blue screen is caused by a third party program, the driver file should be listed in the lower pane.
The drivers that are found in crash stack will be highlighted and those are the files that you should pay attention to. Double clicking on the driver file listed at the lower pane will show every detail about the file such as the stack addresses, size, time stamp and etc. We can see that it was a system file driver belonged to “Resplendence WhoCrashed Crash Dump Test” that caused the blue screen.
It is also possible to generate an HTML report for sharing or logging purposes. Do take note that you’ll need to download a separate 64-bit version of BlueScreenView if you intend to run it on a 64-bit version of Windows.
Download BlueScreenView
2. WhoCrashed
WhoCrashed Home Edition also does pretty much the same thing as BlueScreenView except it tries to be more user friendly. You’ll need to click the Analyze button to start analyzing the minidump files and scroll down to see the crash dump analysis report. It shows you which file probably caused the blue screen and the bug check description helps the user to understand better. As you can see from the screenshot below, it says that the crash appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
The Home Edition is free for home use only. You’ll need to purchase the Pro version if there is a need to run WhoCrashed in a commercial environment and displaying dump details, kernel stacks and loaded modules. Although WhoCrashed comes in a setup installer, it can actually run as a portable program by simply copying the program’s folder to a USB flash drive and run the executable file.
Download WhoCrashed
3. Manually Analyzing Minidumps
Debugging a program to locate the bug so that the problem can be fixed is not an easy task and not something every IT person is capable of. The 2 tools mentioned above are made to be user friendly so that both beginner and expert can tell which offending driver might have caused the blue screen. Although there are quite a few good third party debuggers, WinDbg, a free debugging tool by Microsoft is commonly used to analyze the minidump file and it involves command line usage.
If you do not have WhoCrashed or BlueScreenView at hand, a simple solution is to analyze the memory dump file online. All you need is a web browser with an internet connection to visit the webpage, upload the .dmp file and wait for a few seconds for a report to be automatically generated. Follow the simple steps below to analyze minidump file online.
3a. Visit OSR Online webpage
3b. Click the “Browse” button and select the .dmp file which is normally located at C:WindowsMinidump. If UAC is enabled, you need to copy the .dmp file from the Minidump folder to another location such as Desktop otherwise you’ll receive an error message saying that “You don’t have permission to open this file.”
3c. Once you’ve selected the .dmp file to analyze, click the “Upload Dump” button. The file size of a minidump .dmp file is normally quite small at around 150KB to 300KB so the upload won’t take very long.
3d. On the analysis report, take note of the MODULE_NAME and IMAGE_NAME which shows the file or program that caused the crash in Windows.
Additional Notes: If it is a file from a third party program or a driver for a hardware device, updating or disabling it can stop the blue screen from happening. If it a file from Windows, there are chances that one of the hardware such as memory, CPU or mainboard is failing. You should run a memory test first since it is easy to do that by pressing the Start button and type mdsched which will run the Windows Memory Diagnostic program.
You might also like:
Download Sony Memory Card File Rescue Software for Free3 Ways to Test your RAM with Microsoft Windows Memory Diagnostic9 Automated Online Sandbox Services to Analyze Suspicious File’s Behavior2 Ways to Analyze Behavior of Sandboxed Application in Sandboxie5 Online Tools to Automatically Analyze the HijackThis Log File 17 Comments - Write a Comment
Raymond,
The command to run the Windows Memory app is mdsched
The update at end of article is missing the letter “c”
The update at end of article is missing the letter “c”
Thanks again for documenting your notes!!!
I’ve referred to your site for years.
ReplyI’ve referred to your site for years.
Thanks for pointing the typo out, it’s only been there about four years…
ReplyGood Job bro!
ReplyIt seems WhoCrashed does a better job than BlueScreenView.
ReplySadly, OSR Online is no longer available.
ReplyBlueScreenView is lightweight and easy to use. You just unpack it out of the zip and double click on the exe similar to sysinternal tools like process explorer.
ReplyWhoCrashed is not work if you are into Domain computer
ReplyHi Raymond,
Will this work on all Windows lappys/PCs?
You mentioned Windows 8 at the top, just wondering if it’ll work on Windows 7 as well?
Probably more to the point which Windows OS systems will it work on?
Thanks for all the info, greatly appreciated. :)
ReplyYes, it works on all Windows 7 computers and any Windows that produces a dump file, which is all versions in the last 15+ years (XP – 10).
ReplyThese softwares listed looks like they are from Windows 95 days! VERY ugly UI’s
ReplyDebugging software is not supposed to look pretty, their not for the average consumers….
ReplyThis user looks like he learned about computers after the introduction of the iPhone. VERY oblivious of what’s important.
Replythanksssssss so much….
you know microsoft and others want so big volume and money…
blue screenview…. simply and wonderful
Replyyou know microsoft and others want so big volume and money…
blue screenview…. simply and wonderful
Thanks for the useful share ;).
ReplyThanks for share
Replynice pick Raymond !
Replythanks.
didn’t knew about this stuff
Replydidn’t knew about this stuff
Leave a Reply
Author: Thomas Kejser
Reviewers and Contributors: Bob Ward, Michael Thomassy, Juergen Thomas, Hermann Daeubler, Mark Souza, Lubor Kollar, Henk van der Valk (Unisys) and Peter Scharlock
For advanced troubleshooting and understanding of SQL Server, you can sometimes benefit from creating a dump file of the sqlservr.exe process.
What is a dump? It is a file containing a snapshot of the running process – and parts or all of the memory space of that process. The snapshot also contains the call stack of every thread the process has created.
There are two major types of dump files:
- A full dump – this contains the entire process space. A full dump can take a VERY long time to run. If you are only interested in learning more about SQL Servers internal structures – do not use this type of dump.
- A minidump – this much smaller file contains the memory for the call stack of all threads, the CPU registers and information about which modules are loaded. If you are just curious about the internals of SQL Server, this is the type of dump you want to create.
Using a debugger, such as WinDbg, you can analyze a dump file. Remember that you are only looking at a snapshot in time of the process – but even then, just showing the call stacks can be quite enlightening. In WinDdg, the command to show all call stacks is: ~*kn. If you are the kind of person who likes to have a mental model of how a product works – minidump can help you deepen your understanding. A trick I often use is to take three minidumps in a row, waiting a few seconds between each one. By comparing the thread stacks of dumps, I can get a rough idea what threads inside the SQL Server process space are doing. But remember – these are the threads of the sqlservr.exe process itself – not the session_id that you see from the DMV.
If you should run into errors in SQL Server itself, minidumps help CSS support you and perform deep level investigation. CSS will sometimes request that you perform such a minidump of the process – the engineer in CSS can then use the dump to analyze the issue.
Minidump files have the extension *.mdmp. In rare cases, you may find some of these files in your SQL Server or Analysis Services directory. CSS may request these files from you if you have a case open with them.
There are several ways to generate a minidump. One way is to use the sqldumper.exe file that ships with SQL Server. You can read about sqldumper.exe in:
- KB 827690 – How to use Sqldumper.exe to generate dump files for Windows applications
in Windows 2008 Server there is an easy way to get dumps from the GUI. If you bring up task manager and right click on a process, you get this new option:
But watch out! In the default configuration of Windows 2008 Server you will get a full dump. For a large SQL Server installation with hundreds of GB of memory – generating such a dump can take hours. And while the dump happens, the SQL Server process is frozen.
If you only want the minidump, you can re-configure Windows 2008 Server to generate mini dumps instead of full dumps. This is documented in:
- KB 931673 – How to create a user-mode process dump file in Windows Vista
Now that you know how to create minidumps. Let me show you an example of a curious investigation using a minidump. A question we often get is: Why do I see such high waits for CXPACKET in sys.dm_os_wait_stats. CXPACKET is a wait that SQL Server uses to coordinate parallelism – and you can generally ignore it. But, for those of you curious to know more, minidumps gives you the ability to understand this elusive wait type better.
Recently, I was running an highly parallel INSERT…SELECT statement. I was using the new minimally logged heap operations and the SELECT statement was doing a lot of hash joining. After some time, I saw a lot of tasks blocked on CXPACKET in sys.dm_os_waiting_tasks. I decided to perform a minidump to learn a bit more about SQL Server Parallelism. After opening the dump in WinDbg and running ~*kn I could now see all the thread call stacks in the snahpshot. I saw a lot of threads with this call stack:
Thread: <Many> call stack
ntdll!ZwWaitForSingleObject
KERNELBASE!WaitForSingleObjectEx
sqlservr!SOS_Scheduler::SwitchContext
sqlservr!SOS_Scheduler::SuspendNonPreemptive
sqlservr!SOS_Scheduler::Suspend
sqlservr!EventInternal<Spinlock<153,1,0> >::Wait
sqlservr!EventInternal<Spinlock<153,1,0> >::WaitAllowPrematureWakeup
sqlservr!CXPacketList::RemoveHead
sqlservr!CXPipe::Pull
sqlservr!CXTransLocal::AllocateBuffers
sqlservr!CQScanXProducerNew::AllocateBuffers
sqlservr!CQScanXProducerNew::GetRowHelper
sqlservr!FnProducerOpen
sqlservr!FnProducerThread
sqlservr!SubprocEntrypoint
sqlservr!SOS_Task::Param::Execute
ntdll!ZwWaitForSingleObject
KERNELBASE!WaitForSingleObjectEx
sqlservr!SOS_Scheduler::SwitchContext
sqlservr!SOS_Scheduler::SuspendNonPreemptive
sqlservr!SOS_Scheduler::Suspend
sqlservr!EventInternal<Spinlock<153,1,0> >::Wait
sqlservr!EventInternal<Spinlock<153,1,0> >::WaitAllowPrematureWakeup
sqlservr!CXPacketList::RemoveHead
sqlservr!CXPipe::Pull
sqlservr!CXTransLocal::AllocateBuffers
sqlservr!CQScanXProducerNew::AllocateBuffers
sqlservr!CQScanXProducerNew::GetRowHelper
sqlservr!FnProducerOpen
sqlservr!FnProducerThread
sqlservr!SubprocEntrypoint
sqlservr!SOS_Task::Param::Execute
From the highlight, it does not take much to guess that this is probably the CXPACKET waiting tasks. Searching for a task that is not waiting, I found this:
Tate no yuusha no nariagari ost. Thread: 117 call stack
msvcr80!memcpy
sqlservr!RowsetBulk::InsertRow
sqlservr!CXRowset::InsertRow
sqlservr!CValRow::SetDataX
sqlservr!CEs::GeneralEval
sqlservr!CQScanUpdateNew::GetRow
sqlservr!CQScanProfileNew::GetRow
sqlservr!CQueryScan::GetRow
sqlservr!CXStmtQuery::ErsqExecuteQuery
sqlservr!CXStmtDML::XretDMLExecute
sqlservr!CXStmtDML::XretExecute
sqlservr!CMsqlExecContext::ExecuteStmts<1,0>
sqlservr!CMsqlExecContext::FExecute
sqlservr!CSQLSource::Execute
sqlservr!process_request
sqlservr!process_commands
sqlservr!SOS_Task::Param::Execute
msvcr80!memcpy
sqlservr!RowsetBulk::InsertRow
sqlservr!CXRowset::InsertRow
sqlservr!CValRow::SetDataX
sqlservr!CEs::GeneralEval
sqlservr!CQScanUpdateNew::GetRow
sqlservr!CQScanProfileNew::GetRow
sqlservr!CQueryScan::GetRow
sqlservr!CXStmtQuery::ErsqExecuteQuery
sqlservr!CXStmtDML::XretDMLExecute
sqlservr!CXStmtDML::XretExecute
sqlservr!CMsqlExecContext::ExecuteStmts<1,0>
sqlservr!CMsqlExecContext::FExecute
sqlservr!CSQLSource::Execute
sqlservr!process_request
sqlservr!process_commands
sqlservr!SOS_Task::Param::Execute
Now, you don’t really need source code access to guess what is going on here: SQL Server is inserting the rows and other threads are waiting to feed the insert thread. I can even see that the execution is using what looks like the bulk load function.
Dolan bikes for sale. If you are curious to learn more about analyzing minidumps there is an excellent article about it found here:
- KB 315263 – How to read the small memory dump files that Windows creates for debugging