Tuesday, October 13, 2009

SysFader Hater

I recently encountered the SysFader error within Internet Explorer 8 on Windows 2k3 R2.

This initially worried me because it was within a page I had built that contained some jQuery animation. It turned out it was not just my page though – at least MSN, Amazon, and MajorGeeks caused the same error to appear. That seemed like a decent enough variety to assume it was not just my page.

There are some good posts about the SysFader error out there:

This error seems to have been around for a while – third link above is a thread that spans nearly 2 years.

I tried some of the proposed ‘fixes’ out there – with no success. I admittedly did not try that hard on the ones that had me turning off animation effects and 3rd party browser extensions within IE – since 1) I like me some animations & extensions and 2) The animation effects have been working fine for years, why would I suddenly need to turn them off? (No, I don’t fear change at all…)

There is even a post that points the blame at poor innocent MOSS: http://biztalkdev.com/blogs/paulwu/archive/2007/03/09/IE7-Crash-when-accessing-MOSS-2007.aspx This was interesting because the page that initially threw the error at me was MOSS-based. I also DID NOT attempt to disable the OWSSUPP.DLL ActiveX control since it had been working well for a while and as I mentioned earlier, I was seeing the error from other sites that were definitely not MOSS-based.

Even tried reboot – no dice. Scary because that was the second time in the past month that reboot has failed me!

So how I fixed it: Actually, it was pretty easy. I reinstalled Adobe Flash 10. Not sure what the minor version that I had was, but I had updated Flash recently on the affected machine and it was version 10 – so I may have reinstalled the current version – or at most it was a minor version update. Either way, the net effect of reinstalling flash and restarting IE was that the Sysfader error was a nothing but (a) bad memory.

Later SysFader!

Friday, October 9, 2009

Web Parts Down: A SharePoint Tragedy


There are times when I am a click or two away from registering some derivative of IHateSharePoint.com or SharePointIsKillingMe.com or WasSaneBeforeSharePoint.com. I was VERY close after encountering the following problem…


Act I Scene I

I had been through the Code – Build – Debug cycle with this particular feature numerous times (especially the Debug step). Suddenly one of the builds resulted in the informative web part error:

Web Part Error: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type could not be found or it is not registered as safe.

…which I have seen before – but usually only when the web part is first deployed. 99% of the time this error is caused by the entry for your web part in the SafeControls section of the web.config file. It usually boils down to something like a spelling error, the namespace, assembly version, etc.

ACT I Scene II

Remove the code I just added. No dice – same issue.


IISRESET. Strike two – same issue.

ACT I Scene IV

Remove code I added several builds previous. Same issue.

ACT I Scene V

Re-add the feature and web part to the page. Adding web part fails. Interesting. Upon navigation to home page, notice that ALL web parts are showing errors – even the out of the box ones. Also interesting in a ‘just what I needed’ sort of way.



Magic reboot. Same issue. Strange, because magic reboots rarely fail to resolve issues.



Hit up the internet to see what he knows. Typical stuff: make sure there is a SafeControls entry, make sure it is right, etc. etc. Found some good posts about what to check. Here are a few of them:

Check on all of it for me though – double checked in fact. Re-add assemblies to GAC just in case. Same issue.


Restore a web.config from previous day. SAME ISSUE.

Act II Scene III

Crank up ULS logging level to the deepest depths of verbosity – you know, the ‘disk filler and killer’ levels. But they gave me no additional information – showed me the same as what is rendered within page…

Act II Scene IV

Restore web.config from previous month. All web parts back up except the one I had been working on, which did not exist a month earlier.


So it was web.config related, and also probably an issue with my custom web part. After some experimentation, it turned out to be the entry in the SafeControls section. But not because it was invalid – remember I checked that in act 2 scene 1 – it was because the assembly could not be loaded because one of its dependencies could not be found. Why could it not be found? It was not in app’s bin folder or in GAC. Easy enough to fix once I finally found the real problem. My questions are:

> Why did this not show up as an error somewhere? I could have solved it within minutes rather than burning an entire afternoon.

> Why did this kill ALL SafeControls in the SafeControls section of the web.config, and not just the ones within the problematic entry? If there is a problem with a SafeControl node, the typical behavior is that it only affects anything in that namespace, not every SafeControl node.


Pray for no sequel!

© I caught you a delicious bass.
Back to top