FF 3.5.3 crashed again

My Firefox 3.5.3 crashed again for the third time today:

Add-ons: {2B8EFF80-1240-11DB-BF6C-934CD2EFDFE8}:20080728.334,{CF40ACC5-E1BB-4aff-AC72-04C2F616BCA7}:1.5.2.35,toolbar@alexa.com:1.3.0,{2fa4ed95-0317-4c6a-a74c-5f3e3912c1f9}:2.1.062,firebug@software.joehewitt.com:1.4.2,{d37dc5d0-431d-44e5-8c91-49419370caa1}:2.5.35,{e4a8a97b-f2ed-450b-b12d-ee082ba24781}:0.8.20090123.1,{CAFEEFAC-0016-0000-0007-ABCDEFFEDCBA}:6.0.07,{CAFEEFAC-0016-0000-0011-ABCDEFFEDCBA}:6.0.11,{CAFEEFAC-0016-0000-0015-ABCDEFFEDCBA}:6.0.15,LogMeInClient@logmein.com:1.0.0.460,{B7082FAA-CB62-4872-9106-E42DD88EDE45}:3.0,{20a82645-c095-46ed-80e3-08825760534b}:1.1,pencil@evolus.vn:1.0.6,refractor@developer.mozilla.org:1.0b2,twitternotifier@naan.net:1.8.3,web@veoh.com:1.4,{972ce4c6-7e08-4474-a285-3208198ce6fd}:3.5.3
BuildID: 20090824101458
CrashTime: 1253813633
InstallTime: 1252611358
ProductName: Firefox
SecondsSinceLastCrash: 70976
StartupTime: 1253811215
Theme: classic/1.0
Throttleable: 1
URL: about:blank
Vendor: Mozilla
Version: 3.5.3

This happened while I was doing Google searches…probably one of the add-ons’ fault (probably the Alexa toolbar). 

Update 17:40 EDT: It’s not the Alexa toolbar. Next guess: McAfee SiteAdvisor 3.0

One of the design goals that one should aim to achieve, when building any plug-in architecture, is isolation, to the extent that  a crash in one of the  plug-ins should not bring down the entire application.

Somehow, that is very hard to do, isn’t it?

Guilty as charged.

COMException : Creating an instance of the COM component with CLSID {…}

I recently changed my NAnt build script, as part of its post-build cleanup step,  to unregister all .NET COM interop components after doing the build. Now my unit tests fails with this error:

System.Runtime.InteropServices.COMException : Creating an instance of the COM component with CLSID {596C3AA2-D5EC-4F86-85E3-7FAF86EC17A3} from the IClassFactory failed due to the following error: 800a005b.

What’s the cause?

Here are the facts: My .NET lib X depends on a  COM lib Y (596C3AA2-D5EC-4F86-85E3-7FAF86EC17A3), which depends on COM lib Z, which in turn invokes  .NET COM interop lib N.

It turns out that the real culprit was N, which wasn’t registered for some reason, even though I’ve told it to register via the regasm NAnt task.

Well, as it turned out, I needed to add the codebase=”true” attribute to the regasm task that registers N, which makes sense in hindsight, because my DLLs are not all in the same directory. Another “doh!” I suppose.