Upgrading to Sitecore 10.1 or higher brings significant improvements to how the platform handles data, but it also introduces stricter validation for media assets. If you have recently performed an upgrade and find your publishing process grinding to a halt with a Sitecore.Framework.Data.Blobs.Abstractions.BlobProviderException, you are not alone. This specific error, stating "No supported provider for is configured," typically occurs when the publishing engine encounters a media item with a missing or empty blob reference.
In this guide, we will explore why this happens in Sitecore 10.1+ environments, how to identify the problematic items using SQL and PowerShell, and how to implement a code-based workaround if a database cleanup isn't immediately feasible.
Understanding the BlobProviderException in Sitecore 10.1+
When you upgrade to Sitecore 10.1, the platform shifts toward the Sitecore.Framework.Data.Blobs abstraction. This architectural change means that the publishing helper now explicitly looks for a configured blob provider for every media item it processes.
If a media item exists in your master database but its associated binary data (the "blob") is missing from the Blobs table—or if the field itself contains an empty string instead of a valid GUID—the GetBlobProvider method fails. Because the identifier is null or empty, Sitecore cannot determine which provider (Classic, Azure, etc.) should handle the request, resulting in the following stack trace:
Sitecore.Framework.Data.Blobs.Abstractions.BlobProviderException: No supported provider for is configured.
at Sitecore.Framework.Data.Blobs.BlobStorage.GetBlobProvider[T](BlobIdentifier identifier)
at Sitecore.Publishing.PublishHelper.CopyBlobField(Field sourceField, Item targetVersion)
This is often a result of UpgradeApp.exe failing to clean up legacy system media files or orphaned records from previous versions. To fix this, you must either remove the corrupted references or teach Sitecore how to handle empty blobs gracefully.
Identifying Corrupted Media via SQL
The most direct way to resolve this is by cleaning up the database. You need to find records in the SharedFields or Fields tables that point to a BlobId that no longer exists in the Blobs table.
Step 1: Scan Shared Fields
Most media blobs are stored in shared fields. Use the following query to identify items where the blob field ID {40E50ED9-BA07-4702-992E-A912738D32DC} references a non-existent blob:
SELECT itemid
FROM [dbo].[SharedFields] s
LEFT JOIN [dbo].[Blobs] b ON s.value = '{' + CAST(b.BlobId AS VARCHAR(36)) + '}'
WHERE s.fieldid = '{40E50ED9-BA07-4702-992E-A912738D32DC}'
AND b.BlobId IS NULL
AND s.value <> ''
Step 2: Scan Versioned Fields
If you use versioned media items, you must also check the Fields table for the versioned blob field {DBBE7D99-1388-4357-BB34-AD71EDF18ED3}:
SELECT itemid
FROM [dbo].[Fields] s
LEFT JOIN [dbo].[Blobs] b ON s.value = '{' + CAST(b.BlobId AS VARCHAR(36)) + '}'
WHERE s.fieldid = '{DBBE7D99-1388-4357-BB34-AD71EDF18ED3}'
AND b.BlobId IS NULL
AND s.value <> ''
Once identified, you can verify these items in the Sitecore Content Editor. If they are indeed broken orphans, you can safely delete the rows from the SharedFields or Fields tables to allow publishing to resume.
Auditing the Media Library with PowerShell
If you do not have direct SQL access or prefer to work within the Sitecore interface, Sitecore PowerShell Extensions (SPE) is an excellent tool for auditing your Media Library. The following script iterates through your media items and flags those with empty blob fields.
$items = Get-ChildItem -Recurse -Path "master:/sitecore/media library" | Where-Object {
$_.TemplateID -ne [Sitecore.TemplateIDs]::MediaFolder -and
$_.TemplateID -ne [Sitecore.TemplateIDs]::Node
}
$items | ForEach-Object {
$mediaItem = [Sitecore.Data.Items.MediaItem]$_
$blobField = $mediaItem.InnerItem.Fields["blob"]
if($blobField -and [string]::IsNullOrEmpty($blobField.Value))
{
Write-Host "Empty Blob Item Found: " $_.ID $_.Name $_.Paths.FullPath
}
}
This approach is safer for production environments as it allows you to manually inspect the items before taking action. If you find items that are essentially "shells" without content, deleting them through the Content Editor will clean up the database references automatically.
Implementing a NullBlobProvider Workaround
In some scenarios, you might have thousands of legacy items and cannot perform a manual cleanup immediately. In this case, you can implement a custom NullBlobProvider. This provider tells Sitecore: "If you see an empty blob identifier, don't crash; just treat it as an empty stream."
The C# Implementation
Create a class that implements IBlobProvider to handle empty identifiers:
using System;
using System.Collections.Generic;
using System.IO;
using Sitecore.Framework.Data.Blobs.Abstractions;
namespace YourNamespace.Providers
{
/// <summary>
/// Prevents publishing crashes in Sitecore 10.1+ when encountering empty blobs.
/// </summary>
public class NullBlobProvider : IBlobProvider
{
public bool BlobExists(BlobIdentifier identifier) => false;
public bool CanHandle(BlobIdentifier identifier) =>
identifier == null || string.IsNullOrEmpty(identifier.ToString());
public BlobIdentifier CreateBlobIdentifier() => new BlobIdentifier(string.Empty);
public BlobIdentifier CreateBlobIdentifier(Guid guid) => new BlobIdentifier(string.Empty);
public Stream GetBlob(BlobIdentifier identifier) => null;
public void RemoveBlob(BlobIdentifier identifier) {}
public void SetBlob(Stream stream, BlobIdentifier identifier) {}
public Guid ToGuid(BlobIdentifier identifier) => Guid.Empty;
}
}
The Configuration Patch
After deploying the class, register it in your Sitecore configuration. This patch adds the NullBlobProvider to the web database (or your specific publishing target):
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
<sitecore>
<databases>
<database id="web" role:require="Standalone or ContentManagement">
<BlobStorage>
<providers>
<provider name="null"
type="YourNamespace.Providers.NullBlobProvider, YourAssembly"
patch:after="provider[@name='classic']"/>
</providers>
</BlobStorage>
</database>
</databases>
</sitecore>
</configuration>
Frequently Asked Questions
Why didn't the Sitecore UpgradeApp.exe tool fix this?
While the UpgradeApp.exe tool handles the majority of schema changes and data migrations, it sometimes skips custom media templates or system items that were modified in the source database. If a media item was corrupted prior to the upgrade, the tool might migrate the reference as-is without validating the existence of the binary blob.
Is it safe to delete records directly from the SQL SharedFields table?
Generally, yes, provided you have a backup and have confirmed the itemid corresponds to a broken media item. However, the recommended approach is always to delete the item via the Sitecore Content Editor or PowerShell API to ensure all linked references and indexes are updated correctly.
Does this error affect Azure Blob Storage users?
Yes. Whether you are using the default SQL blob storage or Azure Blob Storage, the BlobProviderException occurs at the abstraction layer before the specific storage provider is even invoked. The issue is the missing identifier, not the storage medium itself.
Wrapping Up
The BlobProviderException in Sitecore 10.1+ is a common hurdle during upgrades, but it is easily managed once you understand that it is simply a validation check for orphaned media. By using the SQL queries provided to identify broken references or implementing a NullBlobProvider for a quick fix, you can ensure your publishing pipelines remain stable.
Always remember to perform a full republish after cleaning up your media library to ensure the web database is in sync with your corrected master data.
