Looks like I made a pretty big mistake when doing some testing with a sample sharepoint project. Ironically, I was trying to spike up a unit testable solution, without writing many of the tests first. I am still pretty new to SharePoint, and wanted to explore what I can / can't do with SP and IoC.

So without going into too much detail, I accidentally wrote some code that is recursive and ends up throwing a StackOverflowException. Not a big deal, right? Just retract the solution and remove it. The problem is that this code gets called during a solution feature's FeatureUninstalling method in a SPFeatureReceiver.

(Well, not exactly. The code ends up getting called during the SPFeatureReceiver's static constructor. If you're wondering why, I was trying to compose the root using Castle Windsor in order to inject dependencies that can be used during the FeatureInstalling and FeatureUninstalling methods.)

So what happens when trying to use either the central web admin or Uninstall-SPSolution is:

  1. A job is scheduled to retract the solution.
  2. The job executes and tries to retract the solution.
  3. The job constructs a new SPFeatureReceiver in order to invoke FeatureUninstalling.
  4. The SPFeatureReceiver (static) constructor invokes code that will try to compose the root, and within there, ends up throwing a StackOverflowException.
  5. I receive a popup message indicating that OWSTIMER.exe encountered an exception, and asks if I want to debug.
  6. OWSTIMER.exe restarts and loops back to step #2.

Hence the question: How to retract an unretractable solution?

2 Answers 2


Have you tried commenting out the offending code, rebuilding/repackaging, and then running an Update-SPSolution command?

The FeatureUninstalling event occurs on removal, and, I believe, it will not be called when upgrading (that's what the FeatureUpgrading event is for).

If you can upgrade successfully and replace the offending code, you would then be able to safely remove the solution.

On second thought, my suggestion above wouldn't work, because if this exception is occurring in the constructor, rather than the event, obviously that would still be called regardless of the solution modification method (Upgrade vs. Uninstall). You could manually replace the .dll in the GAC after removing the offending code though, and then trying a retraction.

  • I had the same idea about the dll, but the gac wouldn't let me uninstall until I found a workaround (changed a Local Security Policy setting). I ended up just removing the Castle.Windsor.dll and after that, the retract succeeded.
    – danludwig
    Mar 30, 2014 at 19:05
  • I can't confirm that the above works, but am marking it as the answer anyway. If you can't replace the dll, see my own answer to this question below.
    – danludwig
    Mar 30, 2014 at 19:13

I'd had a similar idea to @RJ Cuthbertson's answer regarding the GAC, but it would not let me uninstall anything from there. Until I found this:

IMPORTANT! Never ever do this on a production system, and always turn it back on afterwards.

  1. Open Local Security Policy MMC

  2. Goto Security Settings -> Local Policies -> Security Options

  3. Locate "User Account Control: Run all administrators in Admin Approval" and change the setting from Enabled to Disabled

  4. Reboot and now the assemblies can be deleted.

  5. Follow steps above to re-enable the local security policy setting and reboot again to reapply it.

After step #4 above I was able to remove Castle.Windsor.dll from the GAC, and after that, the retract / uninstall / remove all worked.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.