Application crashes with SqlNullValueException when loading the C

Application crashes with SqlNullValueException when loading the CMS UI due to NULL values in the synchronized users table.

hct

Vote:

The CreateUser method in SynchronizeUsersDB uses SqlDataReader.GetString() without checking for NULL values first.
When the identity provider does not supply all expected claims during authentication, the user record is saved with NULL values, which then causes this exception on subsequent reads.

This appears to be a regression in episerver.cms.core 12.22.10, possibly due to changes in how user data is read from the database.

Current workaround: downgrade to Episerver.CMS.Core 12.22.9

Error Details

System.Data.SqlTypes.SqlNullValueException: Data is Null. This method or property cannot be called on Null values.
at Microsoft.Data.SqlClient.SqlBuffer.get_String()
at Microsoft.Data.SqlClient.SqlDataReader.GetString(Int32 i)
at EPiServer.DataAccess.Internal.SynchronizeUsersDB.<FindUsersAsync>g__CreateUser|15_0(DbDataReader reader)

Steps to Reproduce

1. User logs in via external identity provider (e.g., Azure AD)
2. Identity provider syncs user without all required claims (e.g., missing Email, GivenName, or Surname)
3. User record is created in tblSynchedUser with NULL values in string columns
4. User navigates to CMS UI
5. Application attempts to load notifications/subscriptions for the user
6. FindUsersAsync reads the user record and calls GetString() on a NULL column
7. Application crashes

#341106

Edited, Nov 26, 2025 15:11

Sunil

Vote:

Hi,
Thanks for the detailed breakdown, this definitely looks like a regression in 12.22.10, because SynchronizeUsersDB.FindUsersAsync should not be calling GetString() on columns that may contain NULL values.

Users created through external identity providers (Azure AD, Okta, etc.) often arrive with missing claims, and Optimizely normally handles that without errors. The fact that GetString() now throws means NULL checks were removed or changed in the latest release.

The user entry in tblSynchedUser is created by Optimizely’s built-in user synchronization logic, so this is not something you can prevent on your side.

Even if the IdP doesn’t supply email, given_name, or surname, the CMS should still create and read the user safely.
This failure indicates the new version is not handling NULLs correctly.

I would suggest logging this with Optimizely Support, since it’s reproducible and tied to a recent core change.

Thanks,

#341113

Nov 26, 2025 16:06

hct

Vote:

Possible solution found

The regression is in EPiServer.DataAccess.Internal.SynchronizeUsersDB at the local function CreateUser inside
FindUsersAsync(IEnumerable<string> userNames).

Problem code (12.22.10):
user.EmailAddress = reader.GetString("Email"); // Throws on NULL
user.DisplayName = string.Format(...,
reader.GetString("GivenName"), // Throws on NULL
reader.GetStringSafe(reader.GetOrdinal("Surname"))) // Safe

Expected (consistent with CreateUserFromReader):
user.EmailAddress = reader.GetStringSafe(reader.GetOrdinal("Email"));
user.DisplayName = string.Format(...,
reader.GetStringSafe(reader.GetOrdinal("GivenName")),
reader.GetStringSafe(reader.GetOrdinal("Surname")))

The GetStringSafe extension method is already used for Surname but was not applied to Email and GivenName.

#341114

Edited, Nov 26, 2025 19:50