How to Check if Your Processor Supports Second Level Address Translation (SLAT)

If you want to run Docker for Windows, you will need to be running one of these specific Windows 10 SKUs. These include Windows 10 Professional, Windows 10 Enterprise, Windows 10 Pro for Workstations, or Windows 10 Education Edition. Since Docker for Windows requires Microsoft Hyper-V, you will also need a processor on your host machine that supports second level address translation (SLAT) in order to run Hyper-V.  You will also want/need SLAT support for pretty much any other hypervisor that you may be using.

Modern Processors

This should not be a problem in most cases, since nearly all systems that are running Windows 10 will have a new enough Intel or AMD processor so that SLAT support won’t be an issue. For AMD, SLAT support, which they call Rapid Virtualization Indexing (RVI), was introduced in the Barcelona microarchitecture in late 2007. For Intel, SLAT support, which they call Extended Page Tables (EPT), was introduced with the Westmere microarchitecture in early 2010.

Checking for SLAT Support

If you want to actually check your system to confirm that you have SLAT support in your processor (before you install Hyper-V), here is how to do it:

1. Download Coreinfo from this link

2. Extract the zip file, and then copy the Coreinfo.exe file to the root of your C: drive

3. Open a command prompt as an administrator

4. Navigate to the root of your C: drive in the command prompt

5. Run this command: coreinfo –v

6. The –v switch shows virtualization-related features

If you see an asterisk on the feature line, that means the processor supports that feature. If there is a dash on the feature line, the processor does not support that feature. You want to look at the EPT line for Intel or the NP line for AMD. This tells you whether your processor has second level address translation support.


Figure 1: Results of Coreinfo –v on an Intel Core i7-8700K Processor

If you already have Hyper-V installed, you will get inaccurate results, as shown in Figure 2. Just to be clear, this AMD processor does have SLAT support, but the fact that Hyper-V is running gives the wrong results.


Figure 2: Results of Coreinfo –v on an AMD Ryzen Threadripper 2950X Processor


You must have second level address translation support in order to run Docker for Windows since that is a Hyper-V requirement. This is actually a good thing, since second level address translation support gives you better virtualization performance.

Performance and Stability Related Fixes in Post-SQL Server 2014 SP3 Builds

As of April 16, 2019, there has been three Cumulative Updates (CU) for the Service Pack 3 branch of SQL Server 2014. There were a relatively large number of hotfixes in this first cumulative update. If you are running on the SQL Server 2014 SP3 branch, I really think you should be running the latest SQL Server 2014 SP3 Cumulative Update. 

Table 1 shows the SQL Server 2014 SP3 CU builds that have been released so far.

BuildDescriptionRelease Date
12.0.6205SP3 CU1December 12, 2018
12.0.6214SP3 CU2February 19, 2019
12.0.6259SP3 CU3April 16, 2019

Table 1: SQL Server 2014 SP3 CU Builds

You can follow the KB article link below to see all of the CU builds for the SQL Server 2014 RTM, SQL Server 2014 SP1, SQL Server 2014 SP2, and SQL Server 2014 SP3 branches.

SQL Server 2014 Build Versions

Like I have done for other versions and branches of SQL Server, I decided to scan the hotfix list for all of the Cumulative Updates in the SP3 branch, looking for performance and general reliability-related fixes for the SQL Server Database Engine. I came up with the list below, but this listing is completely arbitrary on my part. You may come up with a completely different list, based on what specific SQL Server 2014 features you are using.

Here are the fixes in the SP3 branch:

SQL Server 2014 SP3 Cumulative Update 1 (Build 12.0.6205), 13 total public hot fixes

FIX: Change Tracking cleanup message 22123 is unexpectedly recorded in the error log file in SQL Server

FIX: Incorrect results occur when you convert “pollinginterval” parameter from seconds to hours in sys.sp_cdc_scan in SQL Server

FIX: Access violation when you run a query that uses the XML data type in SQL Server 2014

FIX: Overestimations when using default Cardinality Estimator to query table with many null values

FIX: Access violation for query that uses INSERT INTO … SELECT to insert data into clustered columnstore index

FIX: “ran out of memory” error when executing a query on a table that has a large full-text index in SQL Server 2014 and 2016

FIX: I/O errors on a BPE file causes buffer time out in SQL Server

FIX: Assertion error occurs during restore of compressed backups in SQL Server 2016

FIX: Internal error messages when you update a FILESTREAM tombstone system table in SQL Server

FIX: ObjectPropertyEx does not return correct row count when there are partitions in a database object

FIX: SQL Server service crashes when DBCC CHECKDB runs against a database that has a corrupted partition in SQL Server


 SQL Server 2014 SP3 Cumulative Update 2 (Build 12.0.6214), 5 total public hot fixes

FIX: High CPU use when large index is used in a query on a memory-optimized table in SQL Server

FIX: “Non-yielding” error occurs when there is a heavy use of prepared statements in SQL Server 2014 and 2016

FIX: Assertion occurs when a parallel query deletes from a Filestream table


 SQL Server 2014 SP3 Cumulative Update 3 (Build 12.0.6259), 4 total public hot fixes

FIX: Query plans are different on clone database created by DBCC CLONEDATABASE and its original database in SQL Server 2016 and 2017

FIX: Columnstore filter pushdown may return wrong results when there is an overflow in filter expressions in SQL Server 2014

FIX: Log reader agent may fail after AG failover with TF 1448 enabled in SQL Server 2014


The reason that I put these lists together is that I want to convince more people to try to keep their SQL Server instances up to date with Cumulative Updates. If you do the proper testing, planning and preparation, I think the risks from installing a SQL Server Cumulative Update are quite low (despite the occasional issues that people run into).

If you install a Cumulative Update or Service Pack on a Production system the day it is released, after doing no testing whatsoever, and then run into problems (and don’t have a plan on how to recover), then I don’t have that much sympathy for you.

On the other hand, if you go through a thoughtful and thorough testing process, and you have a plan for how you will install the CU, and how you would recover if there were any problems, then you are much less likely to have any problems. You are also much more likely to avoid the issues that are fixed by all of the included fixes in the new build of SQL Server. You have done your job as a good DBA.

Finally, Microsoft has changed their official guidance about whether you should install SQL Server Cumulative Updates. As they say, “we now recommend ongoing, proactive installation of CU’s as they become available”.

SQL Server 2014 Service Pack 3 CU1 Released

On December 12, 2018, Microsoft released SQL Server 2014 Service Pack 3 CU1, which is Build 12.0.6205.1. There are 13 hotfixes in the public fix list. If you are running SQL Server 2014, you should be planning on getting on the SP3 branch as soon as possible (if you haven’t done it already). Keep in mind that SQL Server 2014 will fall out of Mainstream Support on July 9, 2019, which means there will be no more Service Packs or Cumulative Updates after that.

Microsoft also released SQL Server 2014 Service Pack 2 CU15 on the same day. It is Build 12.0.5605.1, and it has 7 hotfixes in the public fix list. If you are on the SP2 or an even earlier branch, you should be thinking about getting on SP3 as soon as you can.