error "Event ID 33 SideBySide"

[gpzbc]

First of all, thank you. I love list.it and I look forward to
continued development.
I just updated to v0.4.0 on Vista 64 bit and have had no visible
problems. Although when I look at my windows event viewer I see
multiple instances of an error with "Event ID 33 SideBySide".
Unfortunately it looks like list.it is either the culprit or at least
involved. I started getting these right after I upgraded to v0.4.0

Here are the error details:
Log Name: Application
Source: SideBySide
Date: 3/26/2009 9:36:17 PM
Event ID: 33
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DyLAPTOP
Description:
Activation context generation failed for "C:\Users\Dylan\AppData
\Roaming\Mozilla\Firefox\Profiles\js22zprj.default\extensions
\lis...@csail.mit.edu\components\nsOilLocation.dll". Dependent
Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0"
could not be found. Please use sxstrace.exe for detailed diagnosis.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="SideBySide" />
<EventID Qualifiers="49409">33</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2009-03-27T03:36:17.000Z" />
<EventRecordID>10527</EventRecordID>
<Channel>Application</Channel>
<Computer>DyLAPTOP</Computer>
<Security />
</System>
<EventData>

<Data>Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0"</
Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>C:\Users\Dylan\AppData\Roaming\Mozilla\Firefox\Profiles
\js22zprj.default\extensions\lis...@csail.mit.edu\components
\nsOilLocation.dll</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
</EventData>
</Event>


Thanks for your help

[Jamey Hicks]

The localizer does use a native dll to access the wireless card. It was built for 32-bit windows, so I guess it's not surprising that it doesn't work on 64bit windows. I'll look into it.

Jamey

[ericjs]

I get a somewhat similar error in my event log, and I'm running 32-bit
windows (XP Pro, SP3). The text is:

Generate Activation Context failed for C:\Documents and Settings\Eric
Schwarzenbach\Application Data\Mozilla\Firefox\Profiles
\c1utfurv.default\extensions\lis...@csail.mit.edu\components
\nsOilLocation.dll. Reference error message: The operation completed
successfully.

There are many of these in my event log. I'd like to note that I
wasn't even activating your plug in when these errors occurred.

But why on earth is an browser extension like this directly accessing
a driver dll? Can't the https syncing be done through the browser
facilities? Doesn't this unecessarily expose the app to possible
kernal mode errors (which can crash the system)?

I've been getting lock-ups lately (which is why I'm digging into my
event log), and am suspecting this, perhaps in the form of a conflict
with my wireless connection manager.

[ericjs]

A followup with some additional info: The error my last post has event
ID 59 in the application event log for application SideBySide. I was
only able to tie it to listit by its reference to the dll in the
listit extension folder (and by googling the error an ending up here).
What exactly is SideBySide? It comes up in some searches as AdWare but
from the description I think that is probably a different SideBySide.

Most of the SideBySide errors in my event log are this one, but I now
notice that there is another with event id 32, and the message is:

"Dependent Assembly Microsoft.VC80.DebugCRT could not be found and
Last Error was The referenced assembly is not installed on your
system."

If I read this right, it seems this SideBySide component your
extension uses depends on this further component which your extension
install does not install.

[ericjs]

Sorry, one correction: these are from the System Event Log, not the
Application Event Log

[electronic Max]

Hi ericjs,

Thanks for reporting the error message. We'll look into it ASAP.

To answer your question, the nsOilLocation.xpi file is used by List.It
0.5.0 alpha (it's included but not used in the earlier versions of
list.it, including the stable build 0.4.1) to learn associations
between places you go and the notes that you take in those places.
For example, if you take a note at home, and have the place ranking
turned on, next time you go home the notes that you took previously at
home will float to the top of your list. It detects places using
WiFi signatures, much like many other location spotters (skyhook,
geode, etc). Or at least that's how it's supposed to work. It's
currently in alpha state and we're actively working to fix some bugs -
both performance and stability problems we've found. If you're
running 0.5.0 alpha now, the lockups you're experiencing could
definitely be related. The list.it team had to go offline for 2 weeks
due to conferences here at MIT, but we're officially back in action
now, and slated to release a fix later next week (0.5.0 alpha 2).

If you're running 0.5.0 and having problems with lockups, please
consider going back to 0.4.1 for the time being and we'll post an
update shortly. If you're running 0.4.1, it's safe to disregard any
error messages concerning .xpi files because they are not used at all
by list.it (they're included to make deployment simpler, and firefox
tries to load everything included in the bundle). But since it's not
even called or intialized, it should not contribute to any Firefox
failure.

Let us know if this helps and thanks,

Max

[gpzbc]

I am a bit of a noob, so I don't fully understand all of this. But I
am getting the side by side errors and I am using the stable build
0.4.1

Is my problem unrelated to ericjs's problem?

[electronic Max]

Hi gpzbc,

Sorry for being slow getting back to you + for your patience!

Yes, the error you are seeing is caused by the xpi file. Fortunately
though, list.it doesn't rely on using this file at all; it merely has
a copy inside of it because list.it version 0.4.1 and 0.5.0 alpha are
actually the _same_ codebase, except that 0.4.1 has the experimental
stuff disabled.

The problem is that even when the code is disabled, Firefox _still
tries_ to initially load all XPCOM components it finds at startup --
whether they are used or not. And it's running into an error on your
machine because we haven't had a chance to fix it for Vista 64 yet
(sorry!! we'll roll out a patch soon!). BUT, since the file isn't
actually _used_ after it tries to touch it at load time, it actually
shouldn't be causing you any real problems.

IF we get around to rolling out a new stable version, I'll remove the
XPI file so that it doesn't emit scary error messages. We will also
be sure to test our XPI with Vista 64 for our next release of
0.5.0a2.

If you are annoyed by the error and feel like doing some surgery, I
think that you should be able to easily delete the xpi file from
listit by going to:

<Firefox profle directory>/extensions/lis...@csail.mit.edu/components/
and deleting the nsIOilLocation.xpt, nsOilLocation.dll,
nsOilLocation.dylib, nsOilLocation.idl files there.

BUT, since we're going to be fixing it soon, I'd say hang on -- we'll
fix it soon!

Thanks,
Max
list.it team lead

[gpzbc]

Thank you very much for the explanation and for the continued
development of list.it.

I don't seem to be experiencing any visible problems other than the
the entries in the error event log. So in that case, I think I will
just wait for your fix.

Thanks again.

[ericjs]

Hi Max,

Thanks for the reply. I'm using 0.4.1 (on XP). I'm not sure if what
you're saying implies that listit therefore shouldn't be the source of
my lockups. I've disabled listit (about 2 days ago) and haven't
experienced any lockups since, though I realize that doesn't prove
anything.

The place ranking is an interesting idea, but frankly I have concerns
with idea of a browser extension hitting wifi directly. I suppose this
relates to the larger issue we have today of browsers with their lack
of basic os facilities like protected memory becoming application
platforms, but software that talks to hardware directly pushes that
envelope further and exacerbates the situation. I don't think one
should be incurring the kind of risk that comes with installing
hardware drivers by the (generally more casual) act of installing a
browser extension. Is this an issue your team is considering at all,
and are you considering other approaches?

Cheers,

Eric