Java 6 Update 2 may stop Internet Explorer from starting

Posted on July 10th, 2007 by Reiner.
Categories: English, Computers.

After having installed Java 6 Update 2, my Internet Explorer 6 would refuse to start without any indication whatsoever. I’m running Windows 2000 Server and - as I’m doing Java development - there are numerous older JDKs installed on my PC.

The problem appears to be caused by …\Java\jre1.6.0_02\bin\ssv.dll (SSVHelper Class plugin) included within Java 6 Update 2 up to and including build version 1.6.0_02-b05.

IE immediatley returns to normal operation by either uninstalling Java 6 Update 2 or disabling the SSVHelper Class plugin.

As I was unable to disable SSVHelper from within IE 6 (I believe it is an IE 7 feature) I reverted to ShellExView, an excellent Shell Extensions Manager that allows arbitrary Shell Extensions to be disabled in case they are causing problems - SSVHelper in my case.

13-jul-07 update:

The bug has been fixed and the downloads at http://java.sun.com/javase/downloads/ have been updated to build version 1.6.0_02-b06 (as shown by java -version). 

To recover your PC from this bug, either re-download and re-install the JRE or disable the SSVHelper Class.

Links:

  1. SSVHelper Java 6u2 crashing Internet Explorer (java.net Forums)
  2. Bug ID: 6578549 Java 6 RE Update 2 package crashes Internet Explorer 7 (Sun Bug Database)
  3. Bug ID: 6559438 SSVHelper Class crashes Java 6u2 b02 (Sun Bug Database)

4 comments.

WLAN Hintergründe - Warum Sie andere Kanäle als 1, 6 und 11 vermeiden sollten wie die Pest

Posted on July 8th, 2007 by Reiner.
Categories: Deutsch, at other Locations, at Home, Computers.

Zusammengefasst: Verwenden Sie für Ihr 2,4 GHz WLAN auschließlich die Kanäle 1, 6 und 11. Und die Welt wird ein klein wenig besser - ganz umsonst :-)

Endlich! Ihr neuer WLAN Router und auch die Zugangsdaten sind eingetroffen. Da Sie ein umsichtiger und technisch versierter Mensch sind, wählen Sie den Kanal für Ihr neues WLAN so, dass er sich möglichst nicht mit denen Ihrer Nachbarn überschneidet. Bei der Suche nach verfügbaren WLANs stellen Sie fest, dass die Kanäle 1, 6, 9 und 11 bereits belegt sind und entscheiden sich für den Kanal 3. Sie sind sich nun ziemlich sicher, dass Sie Ihr WLAN optimal eingestellt haben und alles wie am Schnürchen laufen sollte. Glauben Sie…

In Wirklichkeit haben Sie gerade eben einen neuen Störsender installiert, der die Übertragungsgeschwindigkeit dreier WLANs halbiert - einschließlich Ihres eigenen. Wie kann das sein?

Nur 3 der 11 weltweit verfügbaren Kanäle überschneiden sich nicht: 1, 6 und 11

Dies liegt an der Frequenzbelegung der Kanäle in den 802.11 b/g Standards und dem Verhalten der WLAN Stationen: Während die einzelnen Kanäle voneinander nur einen Abstand von 5 MHz aufweisen, beträgt die von einer Übertragung genutzte Bandbreite etwa 20 MHz. Das bedeutet, dass nicht nur der eingestellte Kanal selbst, sondern auch die beiden nächstkleineren und die beiden nächsthöheren Kanäle belegt werden.

Daher nutzt eine WLAN Station, die auf Kanal 1 eingestellt ist, die Kanäle 1-2-3. Der nächste nicht-überlappende Bereich ist bei Kanal 6, der das Frequenzspektrum der Kanäle 4-5-6-7-8 nutzt. Der verbleibende Kanal 11 nutzt das Frequenzspektrum der Kanäle 9-10-11-12-13.

Überlappende Kanäle vermindern den Durchsatz erheblich

In städtischer Umgebung und mit nur 3 nutzbaren nicht-überlappenden Kanälen müssen sich WLANs irgendwann gegenseitig stören. Wenn man die gegenseitigen Störungen also schon nicht gänzlich vermeiden kann, ist es dann nicht besser die Lücken zu füllen, also alle verfügbaren Kanäle zu nutzen? Zwei Stationen, die auf den gleichen Kanal eingestellt sind, sollten sich mit Sicherheit stärker behindern, als wenn sie zwei benachbarte Kanäle nutzten. Überraschenderweise ist das nicht so.

WLAN Stationen sind überhaupt nicht dumm. Bevor sie einen Datenblock senden, hören sie zuerst ihren eingestellten Kanal ab, um festzustellen, ob bereits eine andere Station gerade einen Datenblock sendet. Erst wenn “die Luft rein” ist, beginnen sie mit der Ausstrahlung. Dieses Verfahren (DCF, eine Variante des CSMA) soll gegenseitige Störungen des gemeinsam genutzten Übertragungskanals minimieren. Dies ist ein Punkt, der sehr oft übersehen oder ausgeklammert wird, auch in wissenschaftlichen Arbeiten.

Wenn Station überlappende Kanäle verwenden (die also weniger als 5 Kanäle auseinander liegen), wird die Fähigkeit der Stationen, andere Übertragungen zu erkennen behindert - so als würden Sie ihnen ein Tuch vor die Augen binden - wodurch sich ihr soziales Verhalten verschlechtert und sie zu egoistischen Kriminellen werden.     

Außerdem bewirkt die Bandbreite einer Übertragung, deren Kanal sich nicht an die 1-6-11 Regel hält, dass gleichzeitig zwei der nicht-überlappenden Bereiche gestört werden. Daher verursachen Stationen, die sich nicht an die 1-6-11 Regel halten, unwissentlich vermeidbare Störungen, die ihrerseits wieder zu häufigen Sendewiederholungen führen, was letztlich den Durchsatz ihres eigenen und den benachbarter WLANs in den Keller bringt.

Was ist mit den Kanälen 12, 13 und 14

In Europa und Japan gibt es zwei zusätzliche Kanäle: 12 und 13. Sie bieten jedoch keinen wirklichen Nutzen, da sie sich das Frequenzspektrum der Sendungen mit Kanal 11 überschneidet. Daneben besteht die Gefahr, dass WLAN Stationen sich nicht mit Kanal 12 oder 13 verbinden können, falls sie nicht richtig für den Betrieb in Europa konfiguriert worden sind. So kann z.B. ein Nokia E6x keine Verbindung mehr über Kanal 12 und 13 herstellen, wenn Sie das SIMM aus dem Telefon entfernen. 

Kanal 14 ist etwas Besonderes. Er wird nur in Japan verwendet und trotz seiner Nummer besitzt er einen Abstand von 12 MHz zu Kanal 13, er wäre also besser mit Kanal 15,4 bezeichnet worden. Da sich die Übertragungen auf Kanal 14 nur minimal mit denen des Kanals 11 überschneiden, können in Japan die Kanäle 1, 6, 11 und 14 verwendet werden, um gegenseitige Störungen zu minimieren.  

Links:

  1. Channel Deployment Issues for 2.4-GHz 802.11 WLANs (Cisco), als PDF (englisch)
  2. 802.11b WiFi Channels (Moonblink) (englisch)
  3. DCF (Wikipedia) 
  4. CSMA/CA (Wikipadia)
  5. 802.11 (Wikipedia)

Demnächst: Warum SuperG und andere 108 MBit-Verfahren mehr schaden als nutzen.  Warum eine 3dB Antenne mehr bringt als 12 dB mehr Sendeleistung.

0 comments.

WiFi insights - Why you should avoid using channels other than 1, 6, 11 and 14 like the plague

Posted on July 8th, 2007 by Reiner.
Categories: English, at other Locations, at Home, Computers.

In short: Only use channels 1, 6, 11 (and 14 if you live in Japan) for your 2.4 GHz wireless LAN and simply ignore the other ones. The world will be a better place with no effort at all :-)

Great! Now you have got a WiFi of your own. As you are a prudent guy you’ll carefully choose a free channel so as not to interfere with your neighbors’ WiFis. Scanning for available networks reveals that channels 1, 6, 9 and 11 are already being used, which leaves channel 3 as the way to go.  You are quite confident that everything should be in order now. The truth however is rather disconcerting and may come to you as a shock.

What you have really done is, you have set up a new jammer that will halve the throughput of at least 3 networks - including yours. How can that be true?

Only 3 out of 11  channels do not interfere: 1, 6 and 11

This is due to the channel allocation scheme that is used by 802.11 b/g standards and the behaviour of WiFi equipment: While channels are equally spaced 5 MHz apart, the bandwith consumed by a single transmission path is roughly 20 MHz, effectively occupying 5 channel slots: The center channel it is set to, 2 adjacent channels towards lower frequencies and 2 channels towards higher frequencies as well.

Thus a station set to use channel 1 will occupy channels 1-2-3. The next non-overlapping channel will be 6 occupying channel slots 4-5-6-7-8. The only channel left will be channel 11 occupying channel slots 9-10-11.

Overlapping channels substantially decrease throughput 

Assuming urban surroundings and just 3 useable non-overlapping channels, wireless networks are bound to interfere with each other. If interference cannot be avoided, why not try to minimize interference by “filling the gaps”?  Two stations using the same channel should most certainly experience much more interference than if they were using different ones, even if they were just one slot apart. Suprisingly enough, this is not true.

Wireless stations are by no means dumb passive devices. Before initiating a transmission they will listen for other ongoing transmissions and abide from starting their own transmission when they find that the channel is currently in use, thus minimizing interference (DCF, CSMA) . Sadly enough, this is an important factor that is often overlooked or set aside, even in academic documents. 

Now when you offset two stations by less then 5 channels you’ll impede their capability to properly detect ongoing transmissions - practically blindfolding them and turning them into anti-social criminals.

Furthermore, by virtue of its bandwidth, each transmission that does not adhere to the 1-6-11 rule will use up 2 instead of 1 out of the proper channel bands described. Thus stations set to channels other than 1, 6 or 11 will unknowingly and unneccessarily interfere and disrupt both each other and other adjacent channels, in turn causing frequent re-transmission which will bring throughput down to a crawl.  

What about channels 12, 13 and 14

Within Europe and Japan, there are two additional channels available: 12 and 13. But they are of little use, as they both overlap with channel 11. Still worse, devices may refuse to connect to those channels, unless they have been set up properly, e.g. a Nokia E6x will no longer connect to channels 12 and 13 when you remove your SIMM. 

Channel 14 is a very special case. It is used in Japan only and despite its number it is spaced 12 MHz apart from channel 13, so it might have been named channel 15.4. Transmissions on channel 14 will interfere only minimally with those on channel 11. Therefore, in Japan there are 4 channels that should be used in order to minimize interference: 1, 6, 11 and 14.

Links:

  1. Channel Deployment Issues for 2.4-GHz 802.11 WLANs (Cisco), as PDF
  2. 802.11b WiFi Channels (Moonblink)
  3. DCF (Wikipedia) 
  4. DCF (WiFi Planet)
  5. CSMA (Wikipadia)
  6. 802.11 (Wikipedia)

Comming next: Why SuperG and other 108 MBit transmissions often cause more damage than benefit. Why a 3 dB Antenna boosts more than increasing Transmit Power by 12 dB.

3 comments.

Nur für Technik-Freaks - Was Ihr Router so alles kann: DD-WRT verbindet sich mit Relakks

Posted on July 5th, 2007 by Reiner.
Categories: Deutsch, at Home, Computers.

Wie können Sie sich Ihr WLAN mit Ihren Nachbarn teilen, ohne zum Freiwild Hamburger Gerichtsbarkeit zu werden (heise: Unverschlüsseltes WLAN hat Folgen)  und ohne wegen der dem Zeitgeist geschuldeten Verdrehung der Unschuldsvermutung jeden Mausklick Ihrer Nachbarn mitschreiben zu müssen?

Hier wird keine fertige Lösung vorgestellt, sondern nur Hinweise für technisch Versierte gegeben, wie man einen DD-WRT Router (mit statischer IP)  so einrichten kann, dass er sein WLAN über Relakks tunnelt. Vielleicht findet sich ja jemand, der mehr Ahnung hat als ich, und daraus eine anklickbare Option für DD-WRT erstellen kann :-) (more…)

11 comments.

For Techies Only - Your Router can do Tricks: DD-WRT does Relakks

Posted on July 5th, 2007 by Reiner.
Categories: English, at Home, Computers.

How can you share your WiFi with your neighbors without being forced to spy on them - just in order to proove that it wasn’t you who put the new Harry Potter into the public domain by mistake?

This post does not offer a ready-to-use solution, but instead provides some work-in-progress material on how to set up a DD-WRT device (using a static public IP) so that it tunnels its WiFi through Relakks.  Maybe someone more knowledgeable than me might turn this into a clickable option :-) (more…)

14 comments.

JBoss 4.2.0.GA + Unified Invoker + JBoss Remoting = not too much excitement for me yet

Posted on May 19th, 2007 by Reiner.
Categories: English, Computers.

I was rather excited to learn that JBoss 4.2 now uses the Unified Invoker by default, which in turn uses JBoss Remoting. Of course I assumed that JBoss Remoting’s thrilling features would be available to the Unified Invoker. I was wrong. (more…)

1 comment.

Problem solved: Microsoft Update may clog your CPU at 100% on boot starting Apr 11, 2007

Posted on May 6th, 2007 by Reiner.
Categories: English, Computers.

The problem has been fixed, but I suggest to wait until the fix will be distributed automatically starting about 22-May-07. Thereafter - in June - you should then switch back from Windows Update to Microsoft Update. Technical info from Les Connor at WSUS v2 client and high CPU fix.

0 comments.

Problem gelöst: Ab 11. April 2007 verlangsamt Microsoft Update u.U. PC nach dem Start

Posted on May 6th, 2007 by Reiner.
Categories: Deutsch, Computers.

Ein Fix zu diesem Problem ist jetzt verfügbar, aber ich empfehle, solange zu warten, bis er ab ca. 22. Mai automatisch verteilt wird, und erst danach - also so ab Juni 2007 - die automatischen Updates wieder von Windows Update auf Microsoft Update umzuschalten. Info für Spezialisten von Les Connor bei WSUS v2 client and high CPU fix (auf Englisch).

0 comments.

Ab 11. April 2007 verlangsamt Microsoft Update u.U. PC nach dem Start

Posted on April 12th, 2007 by Reiner.
Categories: Deutsch, Computers.

Es gibt plötzlich Berichte darüber, dass Microsoft Update (nicht Windows Update) den PC nach dem Starten mehrere Minuten lang sehr langsam macht.

An meinem Rechner wird eine seiner CPUs nach dem Starten von wuauclt.exe ca. 12 Minuten lang mit 100% belegt. Ältere PCs mit nur einer CPU reagieren mehrere Minuten bis zu einer Stunde lang auf keinerlei Eingaben.

Siehe z.B. Alex met SVCHOST (auf Englisch), wo ein work-around vorgestellt wird:

  1. Automatische Updates ausschalten
  2. Bei http://update.microsoft.com/ die Einstellungen so ändern, dass Microsoft Update nicht mehr verwendet wird, sondern nur noch Windows Update
  3. Automatische Updates wieder einschalten

Aktualisierungen:

 6. Mai 2007: Ein Fix ist jetzt verfügbar, aber ich empfehle, solange zu warten, bis er ab ca. 22. Mai automatisch verteilt wird, und erst danach - also so ab Juni 2007 - die automatischen Updates wieder von Windows Update auf Microsoft Update umzuschalten. Info für Spezialisten von Les Connor bei WSUS v2 client and high CPU fix (auf Englisch).

 1. Mai 2007: Das Problem scheint immer noch nicht gelöst zu sein. Siehe SVChost performance issues — hold on just a smidge longer (auf Englisch).

12. April 2007: Ich freue mich, dass auch ein echter Guru (Bradley von The SBS Diva Blog) dies z.Zt. als Mittel der Wahl empfiehlt: SVChost and flipping back to Windows Update  (auf Englisch)

Wahrscheinlich ist dieses Problem bei Microsoft bereits bekannt und arbeitet z.Zt. an Hot-Fixes. Siehe z.B.:

Ein m.E. gute Darstellung des Problems gibt es bei Windows Update / Microsoft Update / svchost / Autoupdate / 100% CPU - Patrick Hopp (auf Englisch)

1 comment.

Microsoft Update may clog your CPU at 100% on boot starting Apr 11, 2007

Posted on April 12th, 2007 by Reiner.
Categories: English, Computers.

There have been reports, that Microsoft Update (not Windows Update) may clog your CPU for some time after booting your PC.

On my system wuauclt.exe keeps one of its CPUs busy at 100% for about 12 minutes.

See Alex met SVCHOST, where Wim describes a work-around:

  1. Disable Automatic Updates on the computer
  2. Go to http://update.microsoft.com/, choose “Change Settings”, select “To stop using Microsoft Update” at the bottom of the page and then check the box “Disable Microsoft Update software and let me use Windows Update only”
  3. Re-enable Automatic Updates

Updates:

06-May-07: The problem has been fixed, but I suggest to wait until the fix will be distributed automatically starting about 22-May-07. Threafter - in June - you should then switch back from Windows Update to Microsoft Update. Technical info from Les Connor at WSUS v2 client and high CPU fix.

01-May-07: The problem appears not to have been solved yet. See SVChost performance issues — hold on just a smidge longer.

12-Apr-07: Glad a real guru (Bradley from The SBS Diva Blog) backs this somewhat bleak work-around: SVChost and flipping back to Windows Update  

Microsoft may be aware of the problem and is preparing hot-fixes. See

There’s a post that gives some details at Windows Update / Microsoft Update / svchost / Autoupdate / 100% CPU - Patrick Hopp

1 comment.

Older » « Newer