Patching Error: No room is available to display rows

On several occasions, I have been patching SQL Server with a service pack or cumulative update, only to be interrupted with this error:

(Sorry about the wacky font sizes; this is on a Windows 7 VM that is having serious issues with HiDPI.)

For search goodness, here are the important lines from the log file: 

Slp: Error: Action "Microsoft.SqlServer.Configuration.UIExtension.WaypointAction" threw an exception during execution.
…
Slp: Microsoft.SqlServer.Setup.Chainer.Workflow.ActionExecutionException: Thread was being aborted.
—> System.Threading.ThreadAbortException: Thread was being aborted.
…
Slp: Exception type: System.InvalidOperationException
Slp:   Message:
Slp:      No room is available to display rows.
Slp:   HResult : 0x80131509
Slp:   Stack:
Slp:      at System.Windows.Forms.DataGridView.set_FirstDisplayedScrollingRowIndex(Int32 value)
Slp:      at Microsoft.SqlServer.Configuration.InstallWizard.RunRuleProgressController.RulesEngineExecutionCompleted (Object sender, RunWorkerCompletedEventArgs e)

The first time I saw this error, I was kind of taken aback. It was on a Windows 7 VM with 16 instances installed (I’m really not kidding, this is the VM where I can test on just about any build since 2000 RTM). I initially thought that the error came from the screen during setup where it lists the existing instances; but this error occurs long before that. If you examine the stack closely, you’ll see that it actually happens when trying to display the engine rules grid view.

Like most people who had a computer when Windows 95 was first released, my first instinct was to just try setup again, kind of like how most Windows problems resolve themselves by rebooting. Sure enough, I was able to patch my instance, as this time around the error was not raised.

Then, I needed to apply a different cumulative update to a different instance. This time, the error happened, and trying again did not make it go away. A reboot didn’t fix it either. I started to wonder if setup had become self-aware; this problem had certainly become pervasive. I wanted to get these existing instances all patched up to the latest before I installed a new instance. I posted a message about it to a private MVP e-mail list, but got no takers.

I did not have the energy to try to parse the entire error log file; seeing if I could reverse engineer what setup was trying to do, never mind figure out a way to bypass it, did not sound like fun times on that glorious Friday afternoon, just minutes before beer o’clock. Understanding that the issue seemed completely isolated to the UI components in setup, I decided to go command-line. (And note that the following routine could be used for any UI-related setup error you’re trying to bypass, not just the specific error I mention above.)

As anyone who has installed a cumulative update knows, they come in these self-extracting packages with seemingly unrelated names, like 482290_intl_x64_zip.exe (this happens to be SQL Server 2014 Cumulative Update #6, from KB #3031047). When you double-click this file, it asks you where you want to extract it (if you are dealing with a service pack, you can skip this step):

In this case, it will place the file SQLServer2014-KB3031047-x64.exe in the folder c:\temp\cu\:

Now, instead of double-clicking that file, go to the parent folder, press Shift + Right-Click on the folder cu, and choose Open command window here:

Then type “SQL” and tab, and then type ” /x” and Enter. This will generate another destination prompt:

Once it’s done, at the same prompt (maybe after a cd if you changed the destination folder), just run the following, and it will patch your instance(s) without ever raising any UI dialogs:

setup.exe /quiet /action=Patch /allinstances /IAcceptSQLServerLicenseTerms=1

If you only want to patch a specific instance (let’s say an instance named FOO):

setup.exe /quiet /action=Patch /instanceName=FOO /IAcceptSQLServerLicenseTerms=1

Assuming you have no reboots pending and there aren’t other issues going on with your instance, the output should be as simple as this, and then it will return you to a command prompt:

Microsoft (R) SQL Server 2014 12.00.2480.00
Copyright (c) Microsoft Corporation. All rights reserved.

To verify that the patch succeeded, you can check each instance using SELECT @@VERSION;, and you can review the Summary.txt file and newest log folder created in C:\Program Files\Microsoft SQL Server\120\Setup Bootstrap\Log\.

(Of course, for other versions and other patches, the folders and build numbers will vary slightly.)

For more information about installing updates from the command prompt, see this topic in MSDN. Note that the syntax and options have changed slightly between major versions.

This issue has been reported on Connect (#925846), against SQL Server 2014 Setup – so it can happen for initial setup, too; not just when patching. The Connect item has been closed as “no repro” – and even though Microsoft asked for logs and those logs were supplied, there has been no activity at all. There was also a discussion about this issue in the MSDN forums, but that led to a similarly fruitless outcome.

In any case, if you are getting this issue with the initial installation of a SQL Server instance, you can look at this MSDN topic for assistance with creating an unattended install, which will bypass the UI much like the above technique does for cumulative updates and service packs.

Aaron Bertrand

Aaron (@AaronBertrand) is a Data Platform MVP with industry experience dating back to Classic ASP and SQL Server 6.5. He is editor-in-chief of the performance-related blog, SQLPerformance.com.

Aaron’s blog focuses on T-SQL bad habits and best practices, as well as coverage of updates and new features in Plan Explorer, SentryOne, and SQL Server.