Abgelegt unter: Der gelöste Fall | Tags: Acer, AirportExpress, Apple, AR5007EG, Aspire, Atheros, Netzwerkproblem
Kürzlich wurde ich mit einem weiteren skurrilen Problem konfrontiert. Dabei handelte sich sich um ein Acer Aspire 5100 Notebook, das die Internetverbindung per Wireless LAN über einen Apple Airport Express herstellen sollte.
Am Anfang klappte alles wunschgemäss: Das gewünschte WLAN wurde in der Suche nach Drahtlosnetzwerken angezeigt und nach dem Klick auf „Verbinden“ wurde nach dem notwendigen WPA2-Preshared-Key gefragt. Der Key wurde problemlos akzeptiert und kurz darauf wurde auch bestätigt, dass die Verbindung erfolgreich hergestellt werden konnte.
Doch was sollte denn das? Das auf diesem Notebook installierte Vista behauptete stur, es hätte nur lokalen Netzwerkzugriff! Internetzugriff? Weit gefehlt…
Die Netzwerkdiagnose von Windows hatte einzig zu vermelden, dass ein „Problem mit dem Netzwerkrouter oder Breitbandmodem“ die Internetverbindung möglicherweise verhindere. Doch dass der Apple Airport Express einwandfrei konfiguriert war und problemlos funktionierte, bewies ein weiterer Zugriffsversuch mit einem anderen Notebook und einem iPhone.
Als ich dann das übliche „ipconfig /all“ in einem CMD-Fenster ausführte, schien alles in Ordnung zu sein: Das Adresse bezog eine passende IP-Adresse per DHCP, DNS-Server und Standardgateway waren ebenfalls i.O. Der Ping auf die eigene IP-Adresse wurde einwandfrei beantwortet und der Ping auf den Airport… ähhh „Destination host unreachable“?
Da kommunizierte also das Gerät „einwandfrei“ mit der Airport-Basisstation und bezog per DHCP eine passende IP-Adresse mitsamt den korrekten übrigen Settings und wollte daraufhin trotzdem nicht mehr kommunizieren?
Nun ja: „Skurrile Probleme“ rund um die Hardware schreien üblicherweise danach, dass man mal den entsprechenden Treiber unter die Lupe nimmt. So besuchte ich die Acer Webseite und lud von dort den für das Acer Aspire 5100 angebotenen „Atheros Wireless LAN Treiber“ 7.1.0.90 (vom 05.12.2008) herunter und installierte diesen. Leider Fehlanzeige… Auch der neue Treiber brachte keinerlei Verbesserung.
Da das betreffende WLAN-Modul von Atheros stammte, suchte ich im Internet nach diesem Hersteller. Und siehe da: Auf dessen Webseite http://www.atheros.cz/ fand ich einen weiteren, neuen Treiber (Version 7.7.0.331 vom 12.06.2009) für das von Acer verbaute Modul Atheros AR5007EG.
Ich lud diesen Treiber herunter und startete dessen Installation. Ergebnis: Da ich auf dem Notebook das vom Apple Airport Express bereitgestellte WLAN bereits als bevorzugtes Netzwerk konfiguriert hatte, war das Gerät schneller online als die Treiberinstallation Erfolg vermelden konnte.
Fazit: Neue Treiber können etliche Probleme beseitigen. Doch nicht immer findet man diese auf der Webseite des Herstellers des PC/Notebook. Es kann sich lohnen, auch direkt beim Hersteller der jeweigen Gerätekomponenten nach Treibern zu suchen…
Abgelegt unter: Der gelöste Fall | Tags: AAWService.exe, AdAware, CPULoad, ProcessExplorer, Sysinternals
Kürzlich wurde ich mit einem Notebook konfrontiert, dessen Besitzer am Verzweifeln war: „Das Notebook sei schlicht und einfach nicht mehr benutzbar“, lautete der lapidare Hilferuf. Obwohl ich derart schwammige Problemmeldungen keineswegs schätze, habe ich mir das betroffene Gerät angeschaut:
Nach dem Einschalten des Notebooks startete das installierte Vista Home Premium im gewohnten Tempo und der Benutzer meldete sich an, sobald der Anmeldedialog erschien. Soweit war noch alles in Ordnung. Doch unmittelbar nach dem Erscheinen des Desktops wurde das System unerträglich langsam und fror nahezu ein. Es gelang mir noch, den Taskmanager zu starten; dieser zeigte 100% CPU-Auslastung an. Kurz darauf wurde das System dermassen langsam, dass im Taskmanager nicht einmal mehr die Prozesslisten, geschweige denn die Grafiken zum Verlauf der CPU-Auslastung aktualisiert wurden. Zudem lief der Lüfter des Gerätes auf vollen Touren.
Nach etlichen Minuten Wartezeit wurde der Taskmanager zwar wieder etwas lebendig und begann seine Ansicht wieder zu aktualisieren, aber unter einer „benutzbaren Applikation“ stelle ich mir etwas anderes vor. Die CPU-Last blieb unverändert bei 100%.
In der Benutzer-Ansicht des Taskmanager waren nur Prozesse zu sehen, die kaum CPU-Last produzierten. Die Ursache für die hohe CPU-Last musste deshalb anderswo liegen, weshalb ich auf den Knopf „Prozesse aller Benutzer anzeigen“ klickte. Es dauerte weitere vier bis fünf Minuten, bis sich die Anzeige dunkel verfärbte und nochmals geraume Zeit, bis ich den Dialog der Benutzerkontensteuerung (UAC) abnicken konnte. Doch trotz weiterer unzähliger Minuten Wartezeit erschien der Taskmanager mit der Ansicht aller Prozesse nicht.
Es gelang mir aber, von einem USB-Stick den „Process Explorer“ der Sysinternals-Suite zu starten. Hier konnte ich sogleich in der Anzeige erkennen, dass ein Prozess namens „AAWService.exe“ für die immense CPU-Last verantwortlich war. Der Rechtsklick auf den entsprechenden Eintrag mit anschliessendem „Kill Process“ wurde jedoch sogleich mit „Zugriff verweigert“ quittiert.
Eine kurze Recherche bei Google förderte zu Tage, dass es sich bei AAWService.exe um den Dienst der Software „Ad-Aware“ von Lavasoft handelt. Ich öffnete deshalb die Konsole der Dienste-Verwaltung und suchte dort nach dem Dienst „Lavasoft Ad-Aware Service“. Und siehe da: Dessen Status war auch noch nach weit über 30 Minuten nach dem Systemstart immer noch auf „wird gestartet“. Mit viel Geduld gelang es mir, den Starttyp des Dienstes auf „manuell“ zu setzen, worauf ich das Gerät neu startete.
Nach dem Neustart reagierte das System wieder in normaler Geschwindigkeit, weshalb ich anschliessend – in Rücksprache mit dem Benutzer – die Ad-Aware-Software komplett deinstallierte. Auch der Task-Manager liess sich dann wieder wie gewohnt in die Ansicht „Prozesse aller Benutzer anzeigen“ umschalten…
Weshalb die Ad-Aware-Software Amok lief, ist mir nicht bekannt; für eine Suche nach der tieferen Ursache dieses Problems fehlt mir sowohl die Zeit als auch die Lust.
Fazit: Sündenbock dank „Process Explorer“ gefunden. Herzlichen Dank an Mark Russinovich für die Sysinternals-Tools!