Remove orphan Event handlers in SharePoint Lists

Recently we had to migrate at a client a site collection from SharePoint 2007 towards SharePoint 2010 (yeap, a lot of people are still doing this). Not having all the information at hand, the administrator performing the migration, was unaware that one assembly, which was manually registered in GAC was actually containing a Event Receiver attached to a list. To make matter worse, a feature has been manually deployed in the physical location of the old SharePoint 2007 farm -really, really bad practice.

This resulted in the assembly not being included into the deployment (particularly also because the Administrator has not performed as Test-SPContentDatabase which would have revealed the need for some binaries). In addition, despite de successful migration, and even proper functioning of most of the stuff on across the site collection, funny errors started to appear in the ULS logs related to a certain assembly not be available.

Event Type: Error

Event Source:
Event Category: General
Event ID: 6644
Date:  11/12/2010
Time:  11:16:54 AM
User:  N/A
Event manager error: Could not load file or assembly ‘FullyQualifiedAssemblyName’ or one of its dependencies. The system cannot find the file specified.
For more information, see Help and Support Center at


We figured out pretty quickly that an Event Receiver was the culprit here, so we started investigating, which lead us to a particular list using it.

Our administrator was quite quick and by the time we’ve been connected, here already had figured out a SQL query, if you prefer the database approach, not recommended though, only in extreme cases, use this call to get a the results across the whole content database however, this also searches for a specific Assembly  (this is retrieved from ULS logs where the error originally appeared after migration)

USE [<YourContentDatabaseName>]

SELECT * FROM EventReceivers WITH (NOLOCK) WHERE Assembly='ReplaceHereWithYourAssemblyName, Version=X.X.X.X, Culture=neutral, PublicKeyToken=PutYourTokenHere'

We used a variation of the following scripts to check which Event Receivers are attached to the actual list of interest:

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)$Site = New-Object Microsoft.SharePoint.SPSite(“<YourSiteCollectionUrl>”)

$spWeb = $Site.Rootweb
$spList = $spWeb.Lists["ListTitleForWhichYouInspectForEventHandlers"] 
$spList.EventReceivers | Select Name, Assembly, Type| Export-Csv C:\EventResult.csv

The results were clear that we need to  unregister the event handler from the list. We’ve tried the easiest path, SharePoint Manager 2010, which gracefully failed to perform the operation.

So we failed back to PowerShell, using something as presented here below.

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
$spWeb = Get-SPWeb -Identity "SiteCollectionURL"
$spWeb.AllowUnsafeUpdates = $true
$spList = $spWeb.Lists["TargetList"]
$eventsCount = $spList.EventReceivers.Count
$assembly = "<ReplaceHereWithFullyQualifiedAssemblyName>"
$class = "<ReplaceHereWithAssemblyQualifiedClassName>"
for ($i = 0; $i -lt $eventsCount; $i+=1) 
if ($spList.EventReceivers[$i].Assembly -eq $assembly -and $spList.EventReceivers[$i].Class -eq $class)    

Very important is here the Assembly and of course the Class Name which are used in filtering only those Event Handlers to remove. Without proper filtering you could end-up with a real problem on your hands. By example, Workflow auto start event handler is already added, so make sure you don’t remove the registration.

Hope it helps in troubleshooting efforts,



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s