Plugin error

[Jef]

I am getting an error after installing the Google Earth plugin.

The plugin looks like it successfully installs because the installer
creates a google earth plugin directory with files in them and the
event log said the plugin was successfully installed.

When I access http://code.google.com/apis/earth/

I get an error.
The Google Earth Plugin had an internal error. Try reloading the
page.

I noticed my CPU usage goes to 50% for the application geplugin.exe.

After I close the browser the geplugin still continues to run.

The system is a Dell percision 540.
Windows XP 32 bit sp2
2GB of RAM 750MB in use.
ATI FireGL Z1
Dual 3.0GHz Intel Xeon chips
IE 6.0 SP2

Is there a way to debug this thing or figure out what it's doing?

HELP!!!

[ManoM]

Hi Jef,

Does it work in Firefox? Do you have DirectX fully updated?

Mano

On Jul 1, 9:37 am, Jef wrote:
> I am getting an error after installing the Google Earth plugin.
>
> The plugin looks like it successfully installs because the installer
> creates a google earth plugin directory with files in them and the
> event log said the plugin was successfully installed.
>

> When I accesshttp://code.google.com/apis/earth/

[Jef]

I have installed the latest DirectX update. Today and tested it again.
Still no luck.

Thanks

Jef

> > HELP!!!- Hide quoted text -
>
> - Show quoted text -

[ManoM]

Hi Jef,

Another thing to try: If you're using FireFox, install the Firebug
extension and see what error messages come up.

Mano

[paul5]

Hi Mano,

I am a colleague of Jef. The high CPU utilization problem we are
having with the plugin is not restricted to Firefox. It happens on IE
(6.0, sp2) as well. We ran Firebug on Firefox but it didn't show
anything wrong. No error messages. An error page eventually returns
after a while of "Loading...". The error page says: "There was some
problem with the Google Earth Plugin. Try reloading the page." Looking
at TaskManager, the geplugin.exe is still running and taking up 99%
CPU. If I reload the page I will get another instance of the plugin
exe running at high % CPU.

We noticed this behavior happens only on certain networks within our
company. The machines that are having problems are in network that are
behind multiple firewalls. Could this be causing the problem? Is there
special settings we need to adjust on our firewalls?

Thanks,
- paul

[gkscorpi]

Hi, just to let you all know, that I have just installed the plugin
and works great. I am using macafee firewall and it did ask for me to
grant access to the internet. All is good for me. So looks like it is
a firewall problem that you lot have. The plugin installation showed
successfull but the browser failed to load untill the firewall asked.
Thought I'd let you know. Just tested google earth with the weather,
roads, ect and little bit slow but not much. Good luck

> > > > - Show quoted text -- Hide quoted text -

[ManoM]

Hi paul,

Can you run the regular Google Earth client on those machines?

Mano

[paul5]

Hi Mano,

Yes, the regular Google Earth client works fine on those machines.

- Paul

On Jul 3, 11:07 am, ManoM wrote:
> Hi paul,
>
> Can you run the regular Google Earth client on those machines?
>
> Mano
>
> On Jul 2, 5:14 pm, paul5 wrote:
>
> > Hi Mano,
>
> > I am a colleague of Jef. The high CPU utilization problem we are

> > having with thepluginis not restricted to Firefox. It happens on IE

> > (6.0, sp2) as well. We ran Firebug on Firefox but it didn't show
> > anything wrong. No error messages. An error page eventually returns
> > after a while of "Loading...". The error page says: "There was some

> > problem with the Google EarthPlugin. Try reloading the page." Looking

> > > > > > Thepluginlooks like it successfully installs because the installer
> > > > > > creates a google earthplugindirectory with files in them and the
> > > > > > event log said thepluginwas successfully installed.

>
> > > > > > When I accesshttp://code.google.com/apis/earth/
>
> > > > > > I get an error.

> > > > > > The Google EarthPluginhad an internal error. Try reloading the

[ManoM]

Hi Paul,

So it seems like its a firewall problem. I don't know the software
that you're using, but often they log what is being blocked, so you
can probably figure out what you need to open up in the firewall by
checking the logs.

Mano

[mcc]

Mano:

Were this a firewall problem, one would expect a more consistent
behavior than is being observed. We do not see all systems failing to
complete the download and installation of the Google Earth Plugin.
Nor do we see the high CPU utilization when the application is
activated on all systems.

In the path there is a firewall running an intercept application HTTP
proxy. If the server fails to set Content-Length in the HTTP header,
as does the Google server, there is a potential for the transfer to be
terminated prematurely. This is, particularly, true if the connection
is terminated by a RST rather than the FIN procedure. Is there any
reason for the Content-Length not to be set?

The original "crash test dummy" systems that I used could download and
install the Google Earth Plugin without problems and did not encounter
the 100 percent CPU utilization problem. One significant difference
about the physical and virtual "crash test dummy" systems is that they
were not in an Active Directory domain.

Over the weekend, I used a virtual system configured to be in an AD
domain. Consistently, I encountered problems with downloading and
installing the software when Internet Exploder was used to download
the install program. The standard complaint was that the server had
terminated the connection abnormally. After a half-dozen attempts, I
gave up and tried Firefox 3. It downloaded and installed the software
without a problem. Once Firefox was used to download the software, it
was immediately usable by both Firefox and Internet Exploder.

On several of the systems that were encountering problems, we were
using Terminal Service/rdesktop to connect to the systems. We
discovered that the Google Earth Plugin could be downloaded and
installed when we were physically at and logged into the system. Not
sure why it would fail in the first instance but not in the second.

No errors or rule/policy violations have been reported by any of the
corporate firewalls in the path.

I've noticed over the years that web servers that don't use the
Content-Length header are more prone to problems than those that do
especially when the packets must traverse a security boundary.

Merton Campbell Crockett