SQL SERVER – System. Security. Cryptography. CryptographicException – There Was an Error Generating the XML Document

SQL Server setup stopped with “There was an error generating the XML document.” Nothing about XML was wrong. The real error was three layers down, in Windows encryption, and it pointed at the domain controller. I cannot rebuild that network here, but I could run the exact call that failed, and let Windows translate the error code for us.

What Setup Said

SQL Server Setup has encountered the following error:
There was an error generating the XML document.
Error code 0x84B10001.

That is setup reporting the last thing that broke, not the first. Setup writes its settings to an XML file as it goes. Writing that file failed, so setup blamed the XML. The reason it failed is somewhere else.

Where the Real Error Was

Setup keeps a log folder, and Summary.txt in it is always the first file to open. It lives under C:\Program Files\Microsoft SQL Server\ in the version folder, then Setup Bootstrap\Log, with one folder per attempt named by date and time. Ours said this:

HResult : 0x80090345
Stack:
  at System.Security.Cryptography.ProtectedData.Protect(Byte[] userData,
     Byte[] optionalEntropy, DataProtectionScope scope)
  at Microsoft.SqlServer.Common.SqlSecureString.WriteXml(XmlWriter writer)

Read the stack from the bottom. Setup was writing a secure string, a password, into the XML. To do that it called ProtectedData.Protect, which is DPAPI, the Windows service that encrypts data for a user. That call failed with 0x80090345. The XML error was just the messenger.

Letting Windows Explain the Code

You do not need to search the internet for an HResult. Windows will translate it:

(New-Object ComponentModel.Win32Exception([int]0x80090345)).Message

The requested operation cannot be completed. The computer must be trusted for
delegation and the current user account must be configured to allow delegation.

That is the real error, word for word. It is a handy trick for any 0x8 code that setup or a .NET tool throws at you.

The Same Call, Working

To make sure there is nothing exotic about this, I ran the exact call from the stack trace on my own machine:

Add-Type -AssemblyName System.Security
$data = [Text.Encoding]::UTF8.GetBytes('setup would protect a password here')
$enc  = [System.Security.Cryptography.ProtectedData]::Protect($data, $null, 'CurrentUser')

Protect(CurrentUser): ok, 35 bytes in, 262 bytes out, 5 ms
round trip matches: True

Five milliseconds, no complaint. My machine is not joined to a domain, so DPAPI keeps everything local and never has to ask anyone. On my client’s machine it had to ask a domain controller, and that is where it went wrong.

Why the Domain Controller Mattered

For a domain user, DPAPI protects its secrets with a master key, and it wants a backup of that key held by the domain. The backup has to be made with a writable domain controller.

The known cause of this exact error is a read-only domain controller, an RODC. If that is the only domain controller the machine can reach, it cannot take the backup. DPAPI refuses to protect the data without one, setup’s password cannot be written, and the XML file fails. A chain of three failures, reported as the last one.

That is what the error and the fix point to, from how DPAPI works. I have no domain here, so I could not reproduce the refusal itself.

The Workaround, and What It Changes

Microsoft documents a registry value that lets DPAPI back up the master key locally instead of waiting for a writable domain controller. It is a DWORD named ProtectionPolicy, set to 1, under this key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Protect\Providers\
    df9d8cd0-1501-11d1-8c7a-00c04fc297eb
    ProtectionPolicy (DWORD) = 1

We set it, ran setup again, and it completed. On my own machine the key exists and ProtectionPolicy is not set at all, which is the normal state.

Be clear about what it changes before you do it. It moves the backup of DPAPI master keys from the domain to the machine itself, for every user on that machine, not just for setup. That is a security decision, not a setup tweak. Talk to whoever looks after your domain first. If they can make a writable domain controller reachable during the install instead, that fixes the cause and leaves DPAPI as it was.

The Lesson for Any Failed Install

The dialog box in front of you describes the last step that broke. Summary.txt, and the detail logs next to it, describe the first. Always go to the log folder before you go to a search engine, and read any stack trace from the bottom up.

This is not an XML error, it is Windows unable to lock away a password.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.