Server Unexpected shutdown issue

on

                                       Server Unexpected shutdown issue

                                    Event Source: EventLog / Id: 6008

__________________________________________________________________________________________________

Today I am going to Explaining of troubleshooting of server Unexpected shutdown

Server Unexpected shutdown:

 The following alert indicate that a Server may have Unexpected shutdown.

 1.      Event Log : 6008






Process:

 After we receive a Server unexpected shutdown issue, we must perform a sanity check on the server and if we can ensure that everything is fine on the server, we need to analyze memory/mini dump and provide root cause for the unexpected shutdown.

  Sanity Check: Post Server Reboot

Sanity Check consists of 2 main steps.

 

1.      Checking whether all the Windows Services in “Automatic” mode are “Running/Started” or not.

2.      Checking if there are any Critical/bug check Error Event logs which could indicate that there is an issue with hardware [RG1] or OS or application.

 

Standard Operating Procedure:

 

To check the Windows Services Status and Critical Error Event Logs, always try to use the N-care based Remote Commands first.

 

If that is not working, then we will have to login to the server and check.

 

Windows Services:  Start => Run => services.msc

 

a)      We need to ensure that all Automatic Services are in running state.

b)      If any Auto Service is stopped, then immediately restart the service.

c)      We should also ensure that the Application/Service that is restarted, is working normally after the restart.

Note: Follow Notes first for any explicit instructions on the server.

 

d)     If the services are related to Exchange, then we need to check whether Exchange is working fine and mail flow is normal.

e)      If the services are related to any other critical application (e.g. Blackberry, Citrix, SQL, QuickBooks etc.) then restart the services.

f)       If the services are not started then information should be conveyed to the VAR stating that the services were failed to start.

 

Windows Event Log:  Start => Run => eventvwr

a)      If there are any Critical event logs on the server regarding Hardware related issues like (Power Supply, Battery Failed, NIC Failed, Physical Disk failed), then check what was observed, and send the update to the VAR on the status.

 

b)      If there are no critical errors observed on the server, and if the Automatic Services are fine, then we can close the ticket and update the VAR with the information.

 Added hardware

Expected restarts of Server:
 

Expected restarts of servers can be either “planned or unplanned”.

 

1.      A planned shutdown is one in which both the user and the computer fully anticipate the shutdown. For example, as a matter of either policy or habit, a user might shut down his or her computer at the end of each day.

 

2.      An unplanned shutdown is one in which the user does not anticipate the shutdown, but has time to perform the shutdown in a normal manner. For example, if an application becomes unresponsive, the user might be forced to restart the computer. When a user does not have control over the exact timing of a restart, the task is unplanned.

 

For Planned Reboot:

 

1.      Check for the Event log with Event ID 1074 and the Source would be USER32.

 

2.      From the below screen shot we can observe that the last shut down was “Planned” and Event id for Planned reboot is 1074 as an example.

 

3.      The User: besadmin has initiated the restart and the comment is “After mail server crash”.

 

Planned reboot is 1074 as an example:





1.      When we receive a server down alert, by checking for the above Event logs and Event id’s, we can conclude that the last server restart is “Planned or Unplanned”.

2.      Also check if any errors had generated related to hardware issues, we need to login into HP management console or Dell open manager and send the update to the VAR on the status regarding the failure status.[RG1] 

 

1.      Check whether Memory/MINI dump generated if generated validate using WINDBG.
 
(1)   How to analyze MEMORY/MINI dump:
 

1. We have to check MEMORY/MINI dump in the system root directory such as “C:\windows” It has the name “Memory.dmp”.  Small memory dumps are usually stored in the Mini-dump directory of the system root, like “C:\Windows\Minidump\”or check %systemroot% in run command.  If that folder doesn’t exists, then there haven’t been any mini-dumps yet created.  Mini dumps have the date that they happened in the file name, so there will be one for each crash saved in the mini-dump location.


If you cannot find a memory dump there, you will need to check the location by getting back into the advanced system properties. The actual name of the executable that displays that information is called “SystemPropertiesAdvanced.exe”, and if you type that into PowerShell, CMD, or search for it from the Start Menu you will get to the configuration dialog.   After clicking the “Startup and Recovery” button you can see the location of the memory dumps.

To verify a System Crash with WinDbg:

  1. Start Windows debugging tool
  2. Begin Kernel Debugging by selecting it from the File menu.




Happy Learning!!!!!!!!!!!😉😉😉😉


Comments

Post a Comment