SentryOne Team Blog (blogs.sentryone.com)

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:

Setup 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):

Extract location

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

File explorer

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:

Open command window here

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

Extracting the contents of the setup package

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.

Comments ( 2 )

    • Albert says:

      good point.

      what is the reason to extract the .exe to setup.exe?

      Command "SQLServer2014-KB3075950-x64.exe /quiet /action=patch /instancename=sqlserver2014 /IAcceptSQLServerLicenseTerms=1" still works though.

    • Aaron Bertrand says:

      No specific reason, just the way I've always done it (when making the patch available to other VMs / other hosts, it seems "cleaner" to me to copy or share the extracted folder, usually with a better label, than to copy around the cryptic .exe name).

    Leave A Comment

    Your email address will not be published.

    This site uses Akismet to reduce spam. Learn how your comment data is processed.