Inplace Upgrade geht nicht

[DK2000]

C:\ ist nicht die Systempartition, sondern die Startpartition. Das hat Microsoft mal so festgelegt und ist ein klein wenig verwirrend.

Die Systempartition hat im laufenden Betrieb normaler Weise gar keinen Laufwerksbuchtsben. Deswegen bekommt sie hier auch einen temporären Buchstaben:

...Found NT path for system partition: \Device\HarddiskVolume4; assigning temporary drive letter...
...Successfully assigned (temp) drive letter [M:] to [\Device\HarddiskVolume4]

Das ist bis hier hin so erst einmal normal, da das Setup auf die Systemaprtition zugreifen muss.

Aber, wenn \Device\HarddiskVolume4 wirklich die externe Platte ist, wieso denkt das Setup, dass das die Systempartition ist?
Ist das Wirklich die externe Platte?
Befindet sich auf dieser eventuell doch eine Systempartition, welche eventuell auch noch als Aktiv markiert ist?

Wenn im BIOS Mode mehrere aktive Partitionen existieren, kann das schonmal schief gehen. Es sollte grundsätzlich nur eine aktive Systempartition geben.

Aber das ist halt so bei Multiboot Konfigurationen. Hier kann leicht etwas schief laufen, was so eigentlich nicht auffällt.

[Tante Google]

[SurgeonX1]

Nee, M ist wenn ich alles dran lasse eine externe WD Black 1 TB via USB 3.0.
Wurde vor kurzem noch neu formatiert,
und enthält nichts von Windows außer Backups und andere Daten, reiner Datenspeicher.

Primäre Partition ist bei mir C mit dem teils defekten Windows.
Als aktiv markiert ist aber die 300 MB /299 MB) Bitlockerpartition,
die ich oder Windows selbst eingerichtet haben (nach Acronis DD12).
Da steht dann wohl auch irgendwas zum Booten drin.

Aber warum das Setup überhaupt gerade auf M kommt, ist mir schleierhaft.
Auf der primären internen HDD gibt es ja noch C,D, E, F z.B. neben den 3 Datenpartitionen und 2 auf der sekundären internen HDD.

Mag sein, dass ein Doppelboot hier wieder Probleme macht, aber ganz klar ist mir das auch nicht.
Das Windows mit Defekt ist auf C und kann da repariert oder geupgradet werden.
Unabhängig von dem Rest.
Falls was schief geht mit den anderen Partitionen oder dem Doppelboot,
kann man das nachher immer noch konfigurieren oder neu einbinden.

[SurgeonX1]

@Skorpion68:

Die Dateien
rdvidcrl.dll
tsgqec.dll

bleiben immer noch trotz aller Bemühungen als corrupted / cannot repair stehen
nach sfc.
Und immer wieder taucht in dem Zusammenhang das KB 3125574 auf.
Man kann das nicht neu installieren, aber ev. könnte ich es deinstallieren und dann neu installieren !?

[SurgeonX1]

So, ich verabschiede mich nun aus persönlichen Gründen von diesem Thread und bedanke mich bei denen, die mit diskutiert und nach Lösungen gesucht haben ! Danke für die Bemühungen !

[SurgeonX1]

Nachtrag:
Habe das KB 3125574 mal deinstalliert (sog. pseudo SP2).
Danach sollen entsprechende Updates installiert werden, was passt.
Interessanterweise waren dann aber viele Treiber defekt, weil die digitale Signatur angeblich nicht erkannt wurde oder defekt ist.

Geräte Problem nach Deinst KB3125574 1 !.jpg

Geräte Problem nach Deinst KB3125574 2 !.jpg

Zudem:

tdtcp.sys defekt nach Deinstall KB3125574 ! auf Vol 3 !.jpg

Konnte aber alles durch Deinstallation und neu nach Hardware suchen behoben werden.

[skorpion68]

@SurgeonX1
Dein Thema hier wird wohl auf ein Claen Install von Windows 7 hinauslaufen. Zuvor aber noch eine Frage, hast du beim Implace Upgrade die Datei setup.exe aus dem Unterordner sources oder gleich aus dem Stammverzeichnis gestartet? Für ein Inplace Upgrade müsstest du D:\sources\setup.exe ausführen, eventuell dabei den Laufwerksbuchstaben anpassen.

[DK2000]

Das ist eigentlich egal, welches Setup.exe man da ausführt. Wenn man gleich D:\sources\setup.exe ausführt, erscheint halt nicht der Willkommensbildschirm.

Wenn man die andere Setup.exe ausführt, dann kommt halt der Willkommensbildschirm und wenn man dann auf 'Jetzt installieren' geht, wird über die Autorun.dll die D:\sources\setup.exe gestartet.

Kommt auf das Selbe raus.

Was jetzt bei SurgeonX1 kaputt gegangen ist gute Frage.

Kann sein, dass da etwas mit dem 'C:\Windows\System32\CatRoot' Ordner nicht stimmt.
Eventuell mal schauen, ob die 'C:\Windows\System32\catroot2\dberr.txt' da etwas vermerkt hat.

Aber schwer zu sagen jetzt

[SurgeonX1]

Vom Setup.exe direkt auf der DVD.
Ich denke von wo ist egal.
Nach Deinstallation von KB3125574 die gezeigten Treiberprobleme, Signatur nicht erkannt nach Neustart.
Die Frage ist nur, wie das mit der Deinstallation zusammenhängt, das ! wäre der Punkt !

Habe dann die Treiber deinstalliert, und neu suchen lassen, also wieder alles ok !

Wie kann die Deinstallation von dem KB/SP2 an der Treibersignatur /-erkennung was ändern ??
Nachdem wieder alles i.O. war, noch mal sfc laufen lassen, wieder dieselben manifest Probleme wie vorher.

Vor sfc Pending Renames leer, danach wieder voll ca. 1870 items. Vor der Deinstallation des KB teilweise 13 000 und mehr.

Das Problem bleibt, aber der Rechner läuft. Immerhin durch Hilfe von DK2000 läuft auch die Updatebereinigung, mal sehen ob es so bleibt.

Die Ursache würde mich interessieren ! Vor Juni war eigentlich alles gut, auch sfc lief sauber durch.
Davor gingen mal die Updates nicht, wurde aber repariert, mal war die EAZ kaputt, wurde auch repariert.
Wenn man die Ursache eines Problems weiß bzw. wie es gekommen ist, ist das schon mal die halbe Miete, jedenfalls für mich.
Auch wenn man nicht programmieren kann, kann man als Laie dann anfangen zu denken, und früher habe ich immer irgendwie alle Windowsprobleme irgendwie gelöst, meist selbst durch Internetrecherche.

Ich könnte irgendwann noch mal ein IU versuchen, im Moment reicht es mir aber.
Sonst eben clean neu install, aber da das System läuft, brauche ich es auch noch nicht.

Kontaktnummern hatte ich per PN verschickt, weil ich mal wissen wollte, mit wem ich es zu tun habe,
und wie die Leute zu den Kenntnissen und zum Wissen kommen.

Skorpion68 und DK2000 beides IT-Leute mit Informatikstudium, Skorpion68 zudem mit Programmierkenntnissen ??

VG.

CBS.log

dberr.txt

[DK2000]

Wenn ich mir da die dberr.txt so anschaue, dann ist da irgendwie so einiges nicht ganz rund gelaufen. Aber da der Fehler nichtssagend ist (Falscher Parameter), ist es schwer zu sagen, was da nun schon wieder passiert ist.

Und mit dem IU komme ich da auch noch nicht weiter.

Wenn die 300MB Partition = \Device\HarddiskVolume4 ist, dann passt das soweit. Das wäre dann die Systempartition und diese bekommt während des Upgrades den Buschratte M: Das würde dann soweit passen.

Und dennoch bricht das IU weiterhin mit dem selben Fehler wie auf dem Screenshot ab? Dann geht es um ein anderes Laufwerk.

[skorpion68]

@SurgeonX1
Wie ich sehe, fragst du erneut nach der Ursache für dein Problem und das obwohl ich dich hier Beitrag vom 07.08.2018, 07:42 gebeten hatte, dass du dein System mittels Backup zurücksetzt. Hier Beitrag vom 21.08.2018, 07:54 hatte ich dir mitgeteilt, worin ich den Fehler sehe. Die bissherigen Ursachen bauen offensichtlich alle darauf auf.

Das du zum jetzigen Zeitpunkt das Rollup-Update KB3125574 deinstalliert hast war denkbar unsinnig da du das System teilweise zurück ins Jahr 2010 geschickt hast. Ob ein Rollout gemäß meines Beitrages vom 07.08.2018, 07:42 ein besseres Ergebnis erziehlt hätte möchte ich nicht behaupten, zumindest wäre aber der offizielle Update-Stand gegeben gewesen. Hier hätte man dann mit SFC-Scan und CheckSUR arbeiten können und auch die nicht mehr benötigten Updates deinstallieren können.

Was meinst du eigentlich mit Doppelboot, meinst du da die Startkonfiguration Windows 7 und Windows 7-Setup oder meinst du Multi- bzw. Dualboot wo du zusätzlich zu Windows 7 noch Windows 8.1 und / oder Windows 10 installiert hast? Betätige dazu mal die Tastenkombination WIN + R und gib diskmgmt.msc ins Ausführen-Fenster ein, drücke danach die Enter-Taste oder klicke auf OK. Damit öffnet sich die Datenträgerverwaltung welche du auch über Systemsteuerung -> Verwaltung -> Computerverwaltung -> Dateträgerverwaltung erreichst, mache bitte davon mal einen aussagefähigen Screenshot.

@DK2000 hat dir wirklich sehr gut geholfen und auch ich konnte etwas dabei mitnehemn, vorallem wenn ich etwas falsch interpretiere.

[DK2000]

Das blöde in seinem Fall ist ja, dass das Inplace Upgrade irgendwie nicht läuft. Wenn das laufen würde, dann gäbe es einen neuen Komponentenspeicher mit allen drum und dran und könnte so von neuem ohne Neuinstallation weiter machen.

Ist jetzt die Frage, ob ihm da eventuell in der WindowsPE Umgebung ein Treiber fehlt?

Weil die Funktion 'Callback_GatherDiskInfo' läuft einwandfrei durch, solange das Setup sich in Phase 1 befindet. Hier läuft es komplett noch in dem laufenden Windows. Erst in Phase 2, wo das Setup in Windows PE bootet und dort dann weiter macht, versagt 'Callback_GatherDiskInfo' mit Fehler 0x8004240B und das führt dann zum Abbruch des Upgrades. Irgendwie passt da etwas nicht mit der Windows PE Umgebung.

[SurgeonX1]

Sehe ich etwas anders:
Die ältesten Backups, die ich noch hatte, sind von Mitte Mai und Juli 2018.
Ich hätte das von Mai nehmen können, und dann updaten, auch externe Programme, und es wäre wohl ok gewesen.
Habe ich aber nicht gemacht, da das System ja noch gut funktioniert, und das Problem auch andere haben, und ich an einer dezidierten Lösung und Ursachenforschung interessiert war.
Aber es scheint nicht zu gehen, das in Win 7 die entsprechenden dism-Befehle nicht implementiert sind.
Auch das reine sfcfix.exe hilft nicht weiter.
Primär bin ich immer bei PC-Problemen zuerst an den Ursachen ! und Abläufen interessiert, wie schon geschrieben !
Hier allerdings sind Effekte, und man versucht diese zu ändern, es reicht aber nicht bzw. geht nicht.
Die Ursache ist auch noch unklar.
In dem einen Beitrag stand, dass das KB3125574 das Problem ist, was ja auch in den Logs zu sehen war.
Dieses habe ich wohl in 07/2018 mit einem Updatepaket von WF oder DrW installiert, es kann auch sein, dass es vorher drauf war, aber nur, wenn es in den MS Updates angeboten wurde, genau weiß ich das also nicht.
Da es wohl das Problem war, habe ich es deinstalliert, dann komischerweise die Treiberprobleme bekommen, die aber einfach zu beheben waren.
Danach wurden durch MS Updates ein Haufen Updates angeboten, wohl die, die im KB3125574 zusammengefasst waren,
die habe ich dann nachinstalliert.
Danach das System gecheckt, dachte ev. alles ok, da das KB3125574 deinstalliert war, aber nicht der Fall.
War auch nur ein Versuch.
Zudem habe ich ja noch ein Backup von vor der Deinstallation, da ich vor größeren Eingriffen eh immer vorher ein Backup mache.

Insofern finde ich meine Vorgehensweise nicht unlogisch.
Ich kann ja auch jetzt noch durch ein Backup bzw. Recovery den Zustand vor der Deinstallation des KB3125574 wieder herstellen.
Oder das älteste Backup vom Mai nehmen, wahrscheinlich wäre das Problem dann gänzlich weg.
Habe ich nicht gemacht, weil ich an der Analyse und direkten Behebung des Problems interessiert war,
und es könnte ja noch mal auftreten.
Letztlich ist für mich alles im grünen Bereich, das System geht, und man kann noch zuwarten und nachdenken oder am Problem arbeiten !

Ich habe schon seit Urzeit immer Mehrfachbootsysteme, früher z.B. 98/2000/XP, jetzt ein 7//7,
was Vorteile von Dateienaustausch und Reparatur hat, wechselseitigem Virenscan falls nötig uvm.

Die Reihenfolge jetzt lautet:
Win 7 1 / 300MB Bitlockerpartition / Win 7 1 Programme / Win 7 2 / Win 7 2 Programme / Daten 1 / Daten 2 / Daten 3.
(ein Teil der Programme sind aus gewissen Gründen in einer extra Partition, wesentliche und wichtige Programme jedoch immer auf der Systempartition jeweils)

Auf einer 2. HDD im System ist Daten 4 / Daten 5.

Ich hatte zudem beiden Beteiligten eine Telefonnummer geschickt, weil ich mir mal ein Bild machen wollte, mit wem ich es zu tun habe,
und wie diese zu ihren Kenntnissen kommen, weil mich das interessieren würde,
und auch zudem, um deren Denken und Vorschläge einschätzen zu können.
Macht natürlich keiner.
Warum, verstehe ich nicht, ich belästige keine Leute, und die meisten profitieren eher von mir in vielen anderen Bereichen.
Zudem kann man am Telefon manches sehr viel schneller herunterrattern und besprechen !
Ich erwarte zudem eigentlich keinerlei direkte Hilfe, mein blödes Problem zu lösen,
sondern suche im Netz eigentlich immer nur Tipps zur Selbsthilfe, da der User auch selbst entscheiden muss, was er tut oder nicht,
denn es kann ja auch mal schief gehen !
Zudem meine ich, sollte man auch immer selbst verstehen, was man tut !
Selbst wenn ich einen teuren Super-PC-Service vor Ort finden und in Anspruch nehmen würde, würde ich den wie in anderen technischen Dingen im Leben nicht einfach machen lassen, sondern nur, wenn ich genau verstehe, was da abgeht und warum, das mache ich immer so.

Insofern sollte sich hier niemand aufregen, oder in seiner Ehre gekränkt fühlen !
Wie gesagt, ich kann z.B. ein Backup vom Mai nehmen und das dann updaten, und alles wäre erst mal ok.

Beim Skorpion68 habe ich bisher einige kleinere Einzelreparaturen wahrgenommen, ohne das Große und Ganze zu sehen,
bei DK2000 ein etwas anderes Denken.
IU wäre auch noch mal zu probieren, aber ging ja bisher auch nicht durch.
Falls ich richtig liegen, liegt das Problem immer noch im korrupten CBS Store / fehlerhaften Manifesten, Hash Mismatches etc pp
und nicht in ersetzbaren defekten Einzeldateien geringer Anzahl.

MfG.

[DK2000]

KB3125574 ist im WF Updatepack nicht enthalten, da es kein Sicherheitsupdate ist. Was im DrW Update Pack enthalten ist, weiß ich nicht. Das hatte ich noch nicht.Update Packs für Windows 7 verwende ich eigentlich kaum noch. Die Teile zu Pflegen ist ein riesen Zeitaufwand, um am Ende wirklich ein sauberes Update Pack zu enthalten. Das WF Updatepack z.B. installiert in den Komponentenspeicher einfach mal so um die ca. 130 Updates oder sogar mehr, welche Windows in der Bootphase sofort wieder entfernt, weil überflüssig. Die Installation dieser Updates hätte man sich gleich von Anfang an sparen können. Und das ist für mich nicht akzeptabel.

Warum das Deinstallieren des KB3125574 bei Dir Treiberprobleme in Zusammenhang mit den Signaturen verursacht hat, kann ich gerade nicht sagen. Vermute da aber, dass es da Probleme im CatRoot bzw CatRoot2 Ordner gab. Dort werden die Signaturen abgelegt. Das müsste ich mal in der VM versuhen nachzustellen, also Windows 7 SP1 mit KB3125574 und allen anderen Updates installieren, Updatebereinigung durchführen und danach KB3125574 wieder deinstallieren. Eventuell führt da zu irgendwelchen Erkenntnissen.

Was Deine Multiboot-Konfiguration angeht, sehe ich da im Moment auch keine Probleme. Solange die 300MB Partition in der Datenträgerverwaltung mit 'Aktiv' und 'System' gekennzeichnet ist, dann passt das. Das wäre dann die Partition mit dem Bootmanager für beide Systeme. Die beiden Partitionen mit Windows sofern das Windows dort läuft mit 'Startpartition' markiert sein.

Aber wie auch immer, sehe da eigentlich keine Probleme mit dieser Konfiguration. Sowas hatte ich auch mal und dann auch mit verschiedenen Systemen und das lief auch immer einwandfrei, auch mit Inplace Upgrades oder Neuinstallation. Wobei ich die Neuinstallation in dem Falle immer ohne Setup durchgeführt habe.

Momentan wundert es mich halt, dass das IU in Phase 2 die Datenträgerinformationen nicht abrufen kann, obwohl im Phase 1 der SATA Controller als Kompatibel angesehen wird. Nun weiß ich aber nicht, ob der 'Intel(R) Mobile Express Chipset SATA AHCI Controller' von den Standard-Treibern in Windows unterstützt wird oder nicht oder ob das Problem in Phase 2 ganz andere Gründe hat. Das Log von Windows 7 ist da etwas schwer zu lesen.

Bin momentan noch am Überlegen, wie man diese Warungen bewerten muss:

Code: Alles auswählen

2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\CopySetupFiles] Value name [WimPath]. Path name O:\Sources.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\DiskInfo\Disk0\RegionAtOffset2097152] Value name [DrivePath]. Path name S:\.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\DiskInfo\Disk0\RegionAtOffset201947107328] Value name [DrivePath]. Path name K:\.
2018-08-23 20:53:49, Info                  IBSLIB RewriteBlackboardPaths:Rewrote BB value \DiskInfo\Disk1\RegionAtOffset1048576!DrivePath; [C:\] ==> [X:\]
2018-08-23 20:53:49, Info                  IBSLIB RewriteBlackboardPaths:Rewrote BB value \DiskInfo\Disk1\RegionAtOffset219301281792!DrivePath; [M:\] ==> [C:\]
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\DiskInfo\Disk1\RegionAtOffset219615009792] Value name [DrivePath]. Path name D:\.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\DiskInfo\Disk1\RegionAtOffset243007705088] Value name [DrivePath]. Path name E:\.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\DiskInfo\Disk1\RegionAtOffset406057431040] Value name [DrivePath]. Path name F:\.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\DiskInfo\Disk1\RegionAtOffset427813298688] Value name [DrivePath]. Path name H:\.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\DiskInfo\Disk1\RegionAtOffset499545965568] Value name [DrivePath]. Path name I:\.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\DiskInfo\Disk1\RegionAtOffset613375614976] Value name [DrivePath]. Path name J:\.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\InstallSource] Value name [InstallSourcesPath]. Path name O:\Sources.
2018-08-23 20:53:49, Warning               IBSLIB RewriteBlackboardPaths:Corresponding path not found. Key name [\ImageInfo\WinPEImage] Value name [FilePath]. Path name O:\Sources\boot.wim.

Da müsste ich auch erst einmal ein Referenz-Log erteilen und mal schauen ob das dort auch so aufgeführt ist. Kann sein, dass das was zu bedeuten hat oder dass man es ignorieren kann.

[skorpion68]

Die Dateien
rdvidcrl.dll
tsgqec.dll
bleiben immer noch trotz aller Bemühungen als corrupted / cannot repair stehen nach sfc.

Dazu habe ich mir nun doch noch mal das LOG sfcdetails.txt vom 20.08.2018 (15.08.2018) angesehen und muss dir leider sagen, dass hier der Fehler offensichtlich bei mir lag. Ich habe die beschädigten DLL-Dateien rdvidcrl.dll und tsgqec.dll aus folgendem Ordner vergessen

Code: Alles auswählen

Inhalt von ..\x86_microsoft-windows-t..s-clientactivexcore_31bf3856ad364e35_7.2.7601.23403_none_ec27f64366b2f4ee

20.08.2018  08:31    <DIR>          .
20.08.2018  08:31    <DIR>          ..
25.03.2016  18:10         6.130.688 mstscax.dll
03.06.2015  22:16             2.055 mstscax.mof
25.03.2016  18:10           855.552 rdvidcrl.dll
25.03.2016  18:10            53.248 tsgqec.dll

da ich folgendes nicht gelesen habe

Code: Alles auswählen

2018-08-15 12:02:45, Info                  CSI    00000412 [SR] Could not reproject corrupted file [ml:48{24},l:46{23}]"\??\C:\Windows\SysWOW64"\[l:20{10}]"tsgqec.dll"; source file in store is also corrupted
2018-08-15 12:02:45, Info                  CSI    00000415 [SR] Could not reproject corrupted file [ml:48{24},l:46{23}]"\??\C:\Windows\SysWOW64"\[l:24{12}]"rdvidcrl.dll"; source file in store is also corrupted

Könntest du vom jetzigen Stand mal die LOGs PackesList.txt und sfcdetails.txt anfügen.

[SurgeonX1]

@sk68:
Aber diese Rep. reparieren nur einzelne Dateien, das Gesamtproblem lösen sie nicht, oder liege ich da falsch ??

PackagesList.txt

sfcdetails.txt