SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

Configuring a Complete Memory Dump

Imagine this scenario: One of your servers just crashed, and you open a ticket with Microsoft for them to perform a root cause analysis and hopefully find a solution.  What you get instead is this: “Unfortunately, all we were able to capture was a mini dump that doesn’t provide us enough information.  Lets configure your server for a complete memory dump and call us back once you have that.”

Ugggghhhhh.

Out of the box, Windows is configured to take a kernel dump, not a complete dump.  Even though a kernel dump is significantly smaller than its complete counterpart, Microsoft documentation states that this is “the most useful dump for most purposes.”  Quite a statement, considering I’ve never called Microsoft and heard the engineer say “Great!  You have a kernel dump!  This is all we need!”

Configuring your server to correctly take a complete memory dump depends on a couple factors.  First, you will need available drive space.  The size of the .DMP file that is created with a complete memory dump is – you guessed it – the size of the total amount of RAM in your machine.  You will also need available space for a temporary holding area for the memory while it is getting written to the dump file.  So, if you have 128 GB of RAM in your server, plan on having at least 256 GB available.  The temporary holding area is either your page file or a dedicated dump file, and which one you want to use will depend on whether or not you are booting from SAN, or a local drive.

 

Local Hard Drive Boot + Pagefile

Regardless of whether or not you are booting from SAN, you’ll want to keep your page file on a local drive if possible.  This will provide Windows with reliable access to page memory to disk if needed.  If you are booting from a local drive, having the pagefile double as a holding area for memory during a crash is the most straightforward configuration.

Configuration Steps

1. Go to System Properties–>Advanced–>Startup and Recovery, and under ‘Windows debugging information’,  select ‘Complete Memory Dump’.  Also set the location of the memory dump to a local drive, and select ‘Overwrite any existing files’ to ensure you only have at most one .DMP file.

SystemPropSR_D

 

2. On the same Advanced tab of System Properties, select Performance Options–>Change(under ‘Virtual Memory’).  Here you will want to set the location of the pagefile to a local drive and size it for the amount of memory on your machine.  Set the Initial Size to the total amount of memory, and set Maximum Size to the total amount of memory + 100 MB for header information (Microsoft recommendation).  The screenshot below is for an example where the D: drive is the local drive, and the server has 128 GB of RAM installed.

SysPropVirtualMemory

3. Reboot for settings to take effect.

 

Boot from SAN + Dedicated Dump File

Here’s where things get a little more interesting.  As mentioned above, the best practice is to keep your page file on a local drive so that it is nice and close in the event Windows needs to use it.  In a boot from SAN situation, this best practice can end up with a memory dump not getting created because the SAN volume and and local drive may have trouble communicating during a crash.  The solution in this scenario is to take the pagefile out of the equation by configuring Windows to use a dedicated dump file instead of the pagefile during a crash.

1.   This step is the same as Step 1 in the local boot scenario above.  Make sure you’re taking a complete memory dump, set the location (your boot from SAN volume), and overwrite the file if one already exists.

2.  A series of registry edits need to be made in order to enable the creation and use of a dedicated dump file.  You’ll want to put this on the boot from SAN volume also.    Add the following entries to the registry:

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
Type: DWORD
Name: IgnorePagefileSize
Value: 1

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
Type: REG_SZ
Name: DedicatedDumpFile
Value (The full path of the location where you’d like your dedicated dump file): C:\dedicateddumpfile.sys

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
Type: REG_EXPAND_SZ
Name: DumpFile
Value (The full path of the location where you’d like your dump file created):
C:\Memory.DMP

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
Type: DWORD
Name: CrashDumpEnabled
Value: 1

3.   If you’re doing this configuration on Windows 2008 R2 Server, Windows may still attempt to use the page file for some activity during a crash.  In order to ensure it only uses the dedicated dump file you configured, the following hotfix needs to be installed: http://support.microsoft.com/kb/2716542

4.   Reboot for settings to take effect.

 

The steps for the above scenarios work with both Windows Server 2008 R2 and Windows Server 2012.  The only exception is that you don’t need the hotfix mentioned for Windows Server 2012.  A complete memory dump, if you have the space, is worth taking the time to set up.  If you need to reach out to Microsoft for help with a server crash, being armed with a complete dump will expedite the troubleshooting and get you to a root cause faster.


Adam Kreul | Blog

I am currently a Senior DBA for Integrys Energy Services in Green Bay, WI. I’ve been a DBA since 2008 and have worked primarily with SQL Server versions 2005 and above supporting databases as large as 6TB.

Although my title says “DBA”, I also play the role of SAN administrator and data warehouse developer. I love learning and applying new technology and have a passion for making the environment I support as fast as possible. My blog is syndicated from www.adamkreul.com and you can follow me on Twitter at @AdamKreul.

Comments

Leave a comment on the original post [www.adamkreul.com, opens in a new window]

Loading comments...