Quick Steps need to be taken

1. capture the BSD error / Read the error message

2.Reboot the server

3. Check if the server is booting properly or not

* if server has booted up then check the event logs/IML log(ILO logs) to determine the Hardware or software problems or any New device or patch installations

** if server has not booted up then  boot the server in the safe mode and then check the event logs/IML log(ILO logs) to determine the Hardware or software problems or any New device or patch installations

*** may be worth while in booting the server in the “Last know Good configuration”

Level –2 Investigative analysis

1. Check the myfault.sys and notmyfault.sys file of sysinternals tools

2. Crash Analysis

*******Complete Memory Dump********

A complete memory dump contains all the data which was in physical memory at the time of the crash.  Complete dump files require that a page file exists on the system volume, and that it is at least the size of physical memory plus 1MB.  Because complete memory dumps can be very large, they are automatically hidden from the UI on systems with more than 2GB of physical RAM, although this can be overridden with a registry change (which I won’t discuss here).

*********Kernel Memory Dump******

A kernel memory dump contains the kernel-mode read/write pages which were in physical memory at the time of the crash.  The dump file also contains a list of running processes, the stack of the current thread, and the list of loaded device drivers.  Kernel memory dumps are the default on Windows Server 2008 and Windows 7.

*********Small Memory Dump*********

A small memory dump (sometimes also called a mini-dump) contains the stop error code and parameters as well as a list of loaded device drivers, and a small amount of other data.  Small memory dumps must be analysed on a system which has access to exactly the same images as the system which generated the dump file, meaning that it can be difficult to analyse the dump file on a system other than the one on which it was created.

For basic crash analysis, a kernel memory dump is usually adequate and, as shown in Figure 4, the default location for its creation is %SystemRoot%\MEMORY.DMP.  The tool required for analysing the crash dump file isWinDbg, the Microsoft Windows Debugger, which can be downloaded from Microsoft's website.

After installation, WinDbg needs to be configured to use the Microsoft Symbol Server.  Once symbols are configured, click the File menu, choose Open Crash Dump, and select the crash dump file you want to analyze. The output from WinDbg will look like this:

##Finally##

The second to last line, which starts “Probably caused by” indicates the debugger’s best guess at the cause of the crash.  In the example in Figure 5 the debugger is correct - this crash was caused by NotMyFault.  Other information in the analysis indicates that the crash dump file is a kernel memory dump, and that symbol files could not be loaded for myfault.sys (because it is a third party driver, and the symbols are not available on the Microsoft Symbol Server).

More information can be gleaned from the dump file by executing verbose analysis, using the debugger command!” analyze –v “

 

couple of tools also can be used for dump analysis is

1. Dr.watson