Log-Analyse bei missglücktem Windows 8 Upgrade

[English version]Viele Benutzer setzen ja auf das Windows 8 Upgrade-Angebot – von 14,99 über 29,99 bis 59,99 Euro ist ja alles dabei. Und dann geht das Schimpfen los, wenn das Upgrade nicht klappt oder ein Rollback auf das vorherige Windows gemacht wird. Nachdem ich die letzten Tage genügend Fälle im Microsoft Answers-Forum zu Windows 8 unter die Augen bekommen habe, möchte ich kurz skizzieren, wie man die Fehleranalyse durch Auswerten der Log-Dateien “auf die Füße stellt”.


Werbung



Aus reiner Not haben ein paar Benutzer hier einen Waschzettel mit Sofortmaßnahmen zur Vorbereitung des Setup ins Forum gestellt. Von der Deinstallation solcher Goodies wie die allgegenwärtigen Internet Security Suites (optimal natürlich mit Release Datum von Anno Tobak), über TuneUp, CCleaner & Co. über Daemon-Tools bis zu diversen Tools, die Hersteller von Notebooks mit beipacken zu müssen, ist alles dabei. Bei manchen hilft die Deinstallation – wenn es aber nicht klappt, kommen die Fragen “Was kann ich noch tun?” – und die Antworten kommen dann üblicherweise aus dem Gebiet der Kartenleger- und Kaffesatzleserei. Ich gestehe, auch ich musste mir beim Release am Freitag mit meiner Kristallkugel behelfen. Zwischenzeitlich habe ich mir aber ein paar Gedanken gemacht, ob man einige Sachen nicht professioneller abhandeln kann.

Wo finde ich die Log-Dateien?

Microsoft lässt seine Supporter im Regen stehen – so würde ich das als Außenstehender auf den Punkt bringen wollen. Ich weiß nicht, ob und wie der Hotline-Support geschult wird – aber zumindest die Forenmoderatoren in den Microsoft-Foren sind da wenig bis gar nicht gebrieft worden. Sonst hätte die Info, dass das Setup mit protokolliert, was es macht, vorgelegen.

Ich habe mich irgendwann genervt auf die Suche gemacht und Freitag um kurz vor Mittag hier veröffentlicht. Microsoft hat bereits im Februar 2012 einen Beitrag Windows Setup Log Files and Event Logs veröffentlicht. Dem Beitrag zufolge, sind folgende Informationen zu finden.

Ordner Bemerkung
$windows.~bt\Sources\Panther Da findet sich alles an Infos, bevor Setup auf das Laufwerk zugreifen kann.
$windows.~bt\Sources\Rollback Hier finden sich die Log-Dateien, falls das Upgrade auf Windows 8 wegen eines fatalen Fehlers per Rollback zurückgesetzt wird.
%WINDIR%\Panther Einträge des Setup, die nach der Disk-Konfiguration erfolgten.
%WINDIR%\Inf\Setupapi*.log Logs der Plug&Play Installation
%WINDIR%\Memory.dmp Speicher-Dumps bei BlueScreens und Abstürzen
%WINDIR%\Minidump\*.dmp Mini-Dumps
%WINDIR%\System32\Sysprep\Panther Sysprep-Protokolle

Also gilt es zu prüfen, welche Ordner man überhaupt braucht. Die Memory.dmp und MiniDump-Geschichte wäre nur relevant, wenn das System beim Setup per BlueScreen abstürzt oder nach dem Setup ständig die Grätsche macht. Die Fälle hatte ich im Forum – hier habe ich dann auf meine Artikelserie zur BlueScreen-Analyse verwiesen. Fehlerhinweise bei BlueScreens (sind mittlerweise BlackScreens in Windows 8) finden sich wohl auch in der Ereignisanzeige.

Werte die Log-Dateien aus

Schaut man sich die obige Tabelle an, bleiben für die Analyse eigentlich nur zwei Ordner Panther und Rollback übrig. Man navigiert also im Explorer zu den beiden Ordnern und schaut, ob dort .log-Dateien vorhanden sind. Log-Dateien sind einfach Textdateien, die sich mit jedem Editor öffnen lassen.

Man darf nur nicht den Fehler vieler Benutzer machen und die Log-Datei per Doppelklick öffnen wollen. Meist wird der Zugriff wegen fehlender Berechtigungen abgewiesen. Vielmehr kopiert man die log-Datei auf den Desktop. Dann werden die Zugriffsberechtigungen an den Zielordner angepasst und man kann die Datei im Windows-Editor öffnen.

Hier habe ich ja schon erste Analysen einer log-Datei vorgenommen.  Dort hatte ich aber nicht die vollständigen Logs zur Verfügung. Zwischenzeitlich haben mir einige Anwender Log überlassen. Daher hier einmal einige interessante Insights, was scheitert. Ich habe die Einträge etwas bereinigt und die vorangestellten Zeitstempel und das Wörtchen Error in den Folgezeilen gelöscht, um alles in eine Zeile zu bekommen.

2012-10-26 05:40:28, Error                
CONX   Failed to open file: 0x80070020
CONX   GetFileImageInfo failed for for [sptd.sys] 0x80070020
CONX   Failed to get image properties for c:\windows\sysnative\drivers\sptd.sys: 0x80070020
CONX   GetFileProperties failed for [c:\windows\sysnative\drivers\sptd.sys] with 0x80070020
..
CONX   Failure while installing install.wim. Error: 0x8007025D[gle=0x0000025d]

Direkt am Anfang der setuperr.log rappelt es bereits gewaltig. Eine sptd.sys  sorgt bereits dafür, dass der Zugriff auf die GetFileImageInfo-Methode scheitert. Diese liefert aber die Informationen über die Eigenschaften des Laufwerks.

Im Verlauf des Log-Files habe ich dann auch den Hinweis gefunden, dass keine ISO-Datei erstellt werden könne – dies wäre eine Erklärung, warum einige Anwender keine Option zum Speichern der ESD-Dateien in eine ISO-Datei erhalten. Aber nun wäre noch interessant, was für ein ominöser Treiber da werkelt. Also mal eine Suchmaschine nach sptd.sys befragt. Die verwies mich irgendwie häufig auf Daemon-Tools – dort soll der Treiber zur Emulation eines virtuellen Laufwerks verwendet werden. Es gab auch Treffer, die auf Trojaner und Viren hinwies. Ich habe mal die wahrscheinlichere Variante vermutet, und der Anwender bestätigte die Installation der Daemon Tools.


Werbung

Und in der Datei setupapi.app.log des gleichen Systems fand ich noch die folgenden, interessanten Informationen.

>>>  [SetupInstallFromInfSection – DefaultInstall.NTAMD64]
>>>  Section start 2012/10/28 19:22:29.662
      cmd: "C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE 2.0\KLIFX64\drvins64.exe" install kl1 "C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE 2.0\KLIFX64\kl1.inf" "C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE 2.0\KLIFX64\kl1.cat" kl1.cat
<<<  Section end 2012/10/28 19:22:29.662
<<<  [Exit status: SUCCESS]

>>>  [SetupInstallFromInfSection – kl1.install]
>>>  Section start 2012/10/28 19:22:30.026
      cmd: "C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE 2.0\KLIFX64\drvins64.exe" install kl1 "C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE 2.0\KLIFX64\kl1.inf" "C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE 2.0\KLIFX64\kl1.cat" kl1.cat
<<<  Section end 2012/10/28 19:22:30.026
<<<  [Exit status: SUCCESS]

cpy: Open PnpLockdownPolicy: Err=2. This is OK. Use LockDownPolicyDefault

Die Protokolldatei besagt zwar, dass die Operationen erfolgreich abgeschlossen wurden, auch wenn ein Error auftaucht. Aber ein Virenscanner im Setup geht gar nicht. Und da werkelt ein Kapersky.

Eine andere Protokolldatei zeigte z.B. folgende Einträge:

CONX   [WICA::CosCommunicator::Initialize] Failed to extract the web service url from forward link http://go.microsoft.com/fwlink/?LinkID=231688[gle=0x00002ee7]

CONX   [WICA::CosCommunicator::GetApplicationRatings] [0x80070057] Failed getting application ratings[gle=0x00002ee7]

CONX   ConX::Setup::Media::CWorkerProc::SetupThreadProc: An error occurred while servicing the boot files from [C:\$WINDOWS.~BT\Windows\BOOT]; status = [0x8007007B][gle=0x0000007b]

Es gibt bereits beim Zugriff auf die Web-Dienste Probleme, so dass die Kompatibilitätsauswertung scheiterte (habe ich hier nicht aufgeführt). Und zum Schluss gibt es noch Ärger mit den Boot-Dateien. Ich habe zwar nicht die genaue Ursache ermitteln können (die Log-Dateien waren unvollständig), aber es deutet sich an, dass ein Virenscanner da dazwischen funkt.

Als Nachschlag (der Beitrag wurde auf Vorrat verfasst) noch ein Log-File, der mir von einem Anwender freundlicherweise zugeschickt wurde. Liefert, zusammen mit den Hinweisen des Anwenders, die dieser bei der Ursachenanalyse zusammentrug, interessante Insights.

CONX CFreeSystemPartitionDiskSpaceChecker invoked.
CONX [ConX::Compatibility::Wica::RunScanner] Started system scan. CONX ConX::Compatibility::CSystemAbstraction::
GetSystemVolumePath: System volume path: \Device\HarddiskVolume1 CONX ConX::Compatibility::CSystemAbstraction::
GetSystemVolumePath: Assigned drive letter G:\ to system volume. Error CONX ConX::Compatibility::CSystemAbstraction::
GetDiskFreeSpaceW: Failed to retrieve disk space info for G.[gle=0x00000015]
Error CONX CFreeSystemPartitionDiskSpaceChecker failed. Failed to determine the free disk space on the system partition. . HRESULT = 0x80070015[gle=0x00000015]

So ohne weitere Infos hätte ich jetzt angenommen, dass die Festplatte G: nicht initialisiert, kaputt oder mit einem Linux Ext2/3/3 Dateisystem formatiert oder einem OEM-Partitionsformat versehen wäre, oder sonst etwas hakelt. Der Anwender kannte aber sein System und ich hatte ihm einen Hinweis auf einen virtuellen optischen Datenträger, der emuliert wurde, geliefert. Konkret war es Alcohol 120%, welches aber deinstalliert war. Dummerweise scheinen aber Reste in der Registrierung zurück zu bleiben, so dass das Laufwerk G:\ als Phantom übrig blieb (kenne ich von anderen virtuellen Laufwerkslösungen). Und damit lief das Setup natürlich in den Wald, als es die Kapazität des Laufwerks G: ermitteln wollte. Der Laufwerksbuchstabe ließ sich natürlich nicht in einem Partition Manager oder in der Datenträgerverwaltung entfernen – hier ist noch Feldforschung notwendig. Mein Dank an Peter B. für seine Informationen und Findings.

Tipp: Möglicherweise hilft das hier oder das hier.

Auf diese Weise kann man versuchen, sich durch die Log-Files zu hangeln. Mein Lob geht an die Anwender, die sich an Hand meiner bisherigen Infos an die Materie getraut und ihre Problembären mit ein wenig Unterstützung gefunden haben. Ich selbst bin (mangels Upgrade-Lizenz und mangels der Fehler) mehr oder weniger auf Trockenübungen und raten angewiesen.

Der angegebene Dienst ist kein installierter Dienst

Noch ein kleiner Nachtrag: Bei manchen Leuten wirft das Setup bereits beim Aufruf das Handtuch, weil angeblich kein passender Dienst gestartet wurde. Die Fehlermeldung lautet:

Der Download wurde nicht erfolgreich abgeschlossen. Die Downloadaufgabe wurde nicht abgeschlossen. Der angegebene Dienst ist kein installierter Dienst.

Ich habe einiges recherchiert, bin aber auf keine wirklich grünen Zweig gekommen. Allerdings kommt mir, nach Auswertung zahlreicher Forenbeitrag, die in den letzten Tagen durch meine Finger gegangen sind, ein Verdacht auf. Mögliche Ursachen für diesen Fehler sind:

  • Mit Tuning-Tools oder manuell abgeschaltete Microsoft Dienste.
  • Infektion des Systems mit einem Virus oder Trojaner, der den BITS-Dienst ggf. manipuliert hat.
  • Viele Systeme sind mit Auto-Updatern, Update-Centern oder Download-Managern versehen, die den Download blockieren.

Insbesondere die letzte Variante halte ich für viele Probleme verantwortlich. Teilweise werden diese Tools als Update-Center vom Hersteller vorinstalliert. Andere kommen mit Drucker- oder anderen Softwarepaketen auf das System. Abhilfe schafft dann nur die radikale Deinstallation der Auto-Updater, anschließend upgraden und dann den Auto-Updater wieder installieren. Möglicherweise kann man das Problem auch etwas eingrenzen, indem man gemäß meinem Artikel Problemdiagnose mit msconfig befolgt. Zumindest ein Fall ist mir (in anderem Kontext) bekannt, wo ein Download-Manager eines Druckerherstellers Probleme bereitete und Windows nach der Deinstallation des Tools fluppte.


Werbung


Tabula Rasa, wenn’s nicht hin haut

Falls die ganze Analyse nix bringt oder man nicht wirklich auf den Trichter kommt, was da schief läuft, oder falls das System mit Tuning-Tools etc. kaputt optimiert wurde, hilft nur Tabula Rasa. Microsoft sieht für die Upgrades folgendes vor: Altes Windows neu installieren und dann sofort das Upgrade nachschieben. Dabei gehen alle Einstellungen und Programme verloren – was den angenehmen Nebeneffekt hat, dass alle Problembären ins digitale Nirvana verbannt werden.

Wer da von der Upgrade-Orgie genervt ist, kann aber einen direkteren Trick nutzen. Einfach die aus den ESD-Dateien erstellen Setup-Datenträger booten und ein clean install durchführen. Dabei würde ich im Setup-Assistenten in der Partitionierungsseite sowohl die Windows-Partition als auch eine vorhandene Partition “System-reserviert” löschen. Hintergrund ist, dass Windows 8 (im Gegensatz zu Windows 7) kein 100 MB, sondern 385 MByte reserviert. Zudem vermeidet man mit diesem Manöver, dass Probleme im USN (Update Sequence Number Journal) sowie Dateisystemfehler durch das erforderliche Neuformatieren bereinigt sind.

Sofern die Hardware Windows 8 verträgt (PAE/NX-Unterstützung oder fehlende Grafiktreiber sind eine Hürde für ältere Windows XP-Rechner), sollte die Installation klappen. Kleines Problem: Windows 8 wird sich wohl nicht aktivieren lassen, da kein Upgrade ausgeführt wurde. Aber das ist auch kein Problem, hat heise doch bereits vor Jahren den Artikel Der Windows 7 Upgrade Trick veröffentlicht. Dieser zeigt, was man tun muss, um die Aktivierung doch noch ausführen zu können.

Ich hoffe, euch mit diesem Abriss noch ein paar Hilfen an die Hand gegeben zu haben, um den Umstieg auf Windows 8 zu meistern. Und falls es nach dem Upgrade noch Ärger gibt, lest die Hinweise in diesem Artikel durch. Hilft ggf. auch bei Problemen mit Apps.

Ich selbst tue mir den Stress nicht an, sondern arbeite mit Clean Installs. Zudem werde ich meine Produktivsysteme weiter mit Windows 7 fahren. Allerdings laufen hier mehrere Windows 8-Installationen – schließlich brauche ich ja ein wenig Futter für meine Windows 8-Bücher (die finanzieren mit ca. 1 Euro/Tantiemen pro Exemplar auch dieses Blog mit ;-).

Links:
1: Install.-FAQ & Diagnose, wenn das Windows 8 Setup stirbt … Teil 1
2: Windows 8 Installations-FAQ & Setup-Troubleshooting … Teil 2
3: Windows 8 Pro-Upgrade: Black Screen-Troubleshooter
4: Windows 8-Upgrade: Fehler beim Abrufen des Scanberichts
5: Windows 8: DVD-Laufwerke verschwunden
6: Windows 8: CPU-Kompatibilitätsprobleme beim Setup Teil 1
7: Windows 8: CPU-Kompatibilitätsprobleme – Teil 2
8: Problemdiagnose mit msconfig

Noch was zu App-Startproblemen
a: Windows 8: Metro-Apps starten nicht
b: Windows 8: Insides zum Metro-App-Startproblem
c: Nachträge zum Win8 Metro-App-Startproblem

BlueScreen-Analyse
d: Windows BlueScreen-Analyse – Teil 1
e: Windows BlueScreen-Analyse – Teil 2
f: Windows BlueScreen-Analyse – Teil 3 


Werbung – meine Windows 8 Titel –


(c) by Günter Born www.borncity.de
The source of smart computer books


Werbung

Dieser Beitrag wurde unter Windows 8 abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

5 Kommentare zu Log-Analyse bei missglücktem Windows 8 Upgrade

  1. Pingback: [BLOCKED BY STBV] Windows 8 Upgrade - Seite 2 - Installation und Updates (Windows 8)

  2. Günter Born sagt:

    Nachtrag: Zum Fehlercode 0x80070057 gibt es einen Support-Artikel von Microsoft, der helfen könnte:

    http://support.microsoft.com/kb/982736/de

    Nachtrag zum Upgrade Windows 8 auf Windows 8.1

    Die obigen Ausführungen gelten sinngemäß auch für das Upgrade auf Windows 8.1. Hier gibt es noch ein Microsoft-Dokument zum Upgrade für OEMs. Die Rollback-Log-Dateien finden sind in:

    $Windows.~BT\sources\Panther
    $Windows.~BT\sources\Rollback

  3. Fritz Kronberg sagt:

    Hier meine Problembeschreibung: Ich habe leider nichts darauf passendes gefunden, deshalb hier in einem Kommentar, wo so etwas eigentlich nicht hingehört.
    Ich vermute, daß ich den Fehler selbst gefunden habe. Ich möchte ein win xp, das auf meiner zweiten Festplatte in einer logischen Partition (G:) installiert wurde upgraden. Weil sich aber offenbar bei den Microsoftentwicklern niemand vorstellen kann, daß jemand sein Betriebssystem woanders als auf C: in der ersten Festplatte hat (wie ich erstmals beim Versuch, meine Dateien und Einstellungen zu übertragen bemerkte), werden die Startdateien und einige andere Ordner eben dort angelegt. Das führt dann nach langem Gerödel beim ersten Neustart zu der Fehlermeldung:

    Your Computer needs to reboot
    Error Code 0x0000007E
    Parameter
    0x030F0209
    0x756E6547
    0x49656E69
    0x6C65746E

    Ich wäre sehr glücklich, wenn Sie mir einen Weg sagen könnten, wie ich mein Ziel erreichen kann. Natürlich ist mir klar, daß eine Neuinstallation meines xp auf C: und ein Upgrade von dort möglicherweise erfolgreich ist. Auf dieser Platte habe ich aber nicht mehr genug Platz, weshalb ich ja mein System auf G: gelegt habe. Eine weitere Möglichkeit, die ich, wenn auch zähneknirschend in Erwägung ziehen würde, wäre eine Installation auf D: (erste primäre Partition der zweiten Festplatte). Ich habe dort mit Clonezilla einen Klon meines xp eingerichtet, der auch arbeitet, aber leider nicht vom bios erkannt wird, weshalb ich den nur über die Startdateien auf C: starten kann.
    Wenn Sie mir eine Möglichkeit sagen könnten, wie ich dieses System für das bios erkennbar machen kann, wäre ich auch zufrieden. Es wäre die zweitbeste Lösung, weil dort dann das Upgrade vermutlich funktionieren würde, wenn ich D: zur Startpartition im bios machen würde.
    Wäre schön, wenn mir da jemand zumindest Teilantworten gebe könnte.
    Meine Mailadresse ist:
    xxxxx aus Datenschutzgründen entfernt

    • Günter Born sagt:

      @Fritz: Du hast ja schon einen ganzen Sack an Problemen skizziert. Wenn sich Windows XP nicht auf der Primärpartition, die dem Laufwerk D: zugeordnet ist, installieren lässt, läuft ja schon was mit dem BIOS oder den HDD-Kontrollern schief.

      Zum Fehler in Zusammenhang mit Windows XP gibt es diesen MS KB-Artikel.

      Und es gibt hier noch einen Artikel, der auf fehlerhafte Controller-Einstellungen im BIOS abstellt. Könnte auch ein anderes Hardware-Problem wie RAM-Defekt sein.

      Und zum “von den Microsoft-Entwicklern kann sich niemand vorstellen”: Das ist ein Irrtum deinerseits, zumindest nach meinem bisherigen Bauchgefühl. Du musst unterscheiden zwischen Startdateien und den eigentlichen Betriebssystemdateien. Die Startdateien kommen immer auf die aktive Primärpartition – im Idealfall ist das die Partition “System-reserviert”. Die Betriebssystemdateien können auf eine andere Primärpartition installiert werden. Anschließend muss im BCD-Store ein entsprechender Eintrag auf die Installationspartition des Betriebssystems existieren.

      In dieser Kette kann es viele Fehler geben. Hier habe ich z.B. ein System, wo Winload.exe not found auftritt, wenn ich bestimmte Partitionen zur Installation von Windows verwenden will. Geschuldet ist dies mit hoher Wahrscheinlichkeit einer geclonten Festplatte, wo Offsets nicht sauber gesetzt wurden. Ich mag auch nicht ausschließen, dass es ein Problem mit dem alten Windows XP-NTLDR gibt, der ja aus dem Windows 8 Bootmanager aufgerufen werden muss.

      Ich würde sagen: Mach Tabula Rasa, um festzustellen, ob deine Hardware das überhaupt abkann. Also zuerst (sofern Du zwei Festplatten hast) die Festplatte mit der Windows 7-Installation raus. Dann die Ersatzplatte, die zur Win 8-Installation genutzt werden soll, als Primäres-Bootmedium verwenden. Von der Setup-DVD booten, eine benutzerdefinierte Installation wählen und dann als Ziel die Windows XP-Partition angeben – wobei ich im betreffenden Installationsschritt die Partition löschen würde, so dass das Setup eine neue Primärpartition und ggf. auch eine System-reserviert einrichten kann.

      Das müsste auch klappen, sofern Du nur eine Festplatte hast und als Installationsziel das logische Laufwerk D: verwendest. Da Windows XP auf der Festplatte ist, sollte es danach mit der Aktivierung auch keine Probleme geben. Notfalls in diesem Beitrag meine Bemerkungen lesen.

      Hoffe, das hilft.

  4. Günter Born sagt:

    Falls das Windows Media Center Upgrade fehl schlägt, unter [a] findet sich ein Artikel, der einen Hinweis zur Log-Datei gibt (hab’s aber noch nicht getestet).

    a: https://channel9.msdn.com/Forums/Coffeehouse/Win8-Media-Center-Update-Failed-then-fixed#c75af45c11a8b494988ada10101067632

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.