Archiv für Windows

Desaster Recovery

Nach 3 Tagen erfolgreich…

Das ist passiert:
HP-Rechner von 2005 mit Win10 64bit war nach einem versehentlichen Standby plötzlich nicht mehr zu starten. Windows 10 versuchte Reparatur, zeigte aber maximal einen schwarzen Startbildschirm mit Maus-Zeiger / Cursor bzw. nach einigen Versuche einen blauen Bildschirm mit Mauszeiger, aber ohne Interaktionsmöglichkeiten. Auch Tips im Web mit blind das Passwort eintippen etc. haben nicht gebracht.

In weiterer folge bootete das System plötzlich überhaupt nicht mehr, was mich zunächst stutzig machte und ich mir mittels Diskpart die Festplatte genauer vornahm. Dabei viel auf, dass die Partition 2 nur mehr im RAW-Format vorlag, obwohl diese wie die Boot-Partition (100MB Win-Standard) natürlich in NTFS formatiert war.
Das Problem jetzt: Die Partition reparieren, ohne die Daten zu gefährden (gab natürlich kein Backup).

Hier hat nur geholfen über eine (ältere) Acronis-Version vom Stick zu booten – Linux konnte den offenbar defekten MBR der Systemplatte ohne Probleme lesen und somit konnte ich die Daten zunächst in Sicherheit bringen.

Nachdem die Sicherung fertig war begann ich dann mit dem eigentlichen Wiederherstellen des Systems. Das Reparieren mittels bcdedit /fixboot /fixmbr funktionierte nicht und auch /scanos lieferte kein Ergebnis – irgendwie logisch, da die Partition im RAW-Format ja nicht von Windows erkannt wird (da könnte MS noch von Linux lernen…).
Folgende Lösungsvarianten mit der Windows Wiederherstellungskonsole (über Win10-USB-Stick) kamen nach Web-Recherche in Frage:
convert
checkdsk

Nachdem Checkdisk lt. Berichten manchmal mehr Schaden anrichtet als es hilft, probierte ich zunächst die convert-Variante.
Hier stellt sich heraus dass mit convert „C: /FS:NTFS /X“ Windows plötzlich doch erkennt, dass die Partition bereits im NTFS-Format vorliegt – also kein Fortschritt… (im Hinterkopf hatte ich hier umwandeln in FAT und dann zurück in NTFS, war aber ein Worst-Case Szenario)

Nachdem die Daten gesichert waren, wagte ich mich somit an Checkdisk (chkdsk C: /f /r) und ließ es mal 1,5 Stunden laufen.
Nach dem Lauf direkt über diskpart die Datenstruktur überprüft und siehe da, plötzlich ist Laufwerk C wieder NTFS, obwohl Checkdisk keine Fehler gefunden/angezeigt hatte. Damit war der Weg für einen erfolgreichen Windows-Bootvorgang allerdings wieder geebnet. Sicherheitshalber hab ich die Boote-Partition (versteckte 100MB-Partition) noch mittels Diskpart als Active markiert -> Neustart

BOOTMGR fehlt

Ok, so ganz einfach ist es nicht, der Bootmanager ließ sich mit bcdedit dann allerdings wiederherstellen, nachdem das Partitions-Format wieder richtig erkannt wurde. Hier würde auch helfen von einem Windows-Bootmedium zu starten, dann sollte die automatische Reparatur auch den Bootloader korrekt wiederherstellen können…

Vielleicht hilft dieser Kurzbericht bei ähnlichen Fällen und wenns wieder mal passiert zum Nachlesen der Hintergründe 😉

Windows 10 – eine Update-Erfahrung

Dieses Wochenende ist es so weit – auch mein Haupt-Rechner wird mit dem neuen Windows ausgestattet. Nachdem ich schon einige PCs erfolgreich umgestellt habe und immer wieder auf kleine Inkompatibilitäten gestoßen bin gehe ich mit gemischten Gefühlen ans Update.
Dazu kommt, dass mein Rechner schon mit Windows 7 an die Aktualitätsgrenzen gestoßen ist, was Treiber betrifft (speziell älteres Motherboard, MS-Tastatur) und auch bei verwendeter Software (Rainmeter, Flight Simulator 2004).

Die erste große Sorge nach dem Update (dass nur etwa 1 Stunde gedauert hat): EasyTune 6
Da mein Motherboard keine vernünftige Lüftersteuerung hat und meine 6-Kern CPU mit X% bei weitem nicht ausgelastet ist muss das über Software an das Motherboard gemeldet werden – das klappt nur mit EasyTune 6 richtig.
Im Internet wird man schnell fündig, dass ET nicht mit Win10 kompatibel ist – ich musste aber feststellen, dass das Ausführen der GUI.exe vom vorhandenen Verzeichnis der Win7-Installation schon reicht, um alle Funktionen und vor allem die Lüfter-Steuerung wieder in den Griff zu bekommen. Nach einem Restart funktioniert auch der Autostart wieder und die Soundtreiber-Inteferenzen, die unter Windows 7 in Form von Rauschen zu hören waren sind auch verschwunden -> besser als zuvor!

Microsoft Multimedia Tastatur:
Das Einstellungs-Programm bedurfte zwar einem Benutzer-Zugriff für die Installations-Optionen, lief dann aber perfekt durch und hat alle Einstellungen der programmierbaren Tasten übernommen.

Calculator öffnen mit Shortcut geht nicht mehr. Windows schreibt nur, ich brauche eine neue App zum Öffnen von Calculator – nach einem Restart funktioniert auch diese Taste mit dem neuen Windows-eigenen Taschenrechner.

Sympathischerweise funktioniert Rainmeter sofort wieder perfekt nach dem Update und alles ist an seinem alten Platz ohne Darstellungsfehler (das Update auf die letzte Version hat sich hier offenbar ausgezahlt).

Seltsam, dass das Firmen-Eigene One-Drive hier etwas ins Straucheln kommt – die Synchronisierung funktioniert nämlich nicht mehr. Erst nach einem Neustart weiß der Cloud-Dienst wieder, wo er die Dateien gespeichert hat, muss aber nichts nachsynchronisieren, also letztendlich auch problemlos.

Wichtig ist mir auch das DirectOutput des X52 Flight Systems, dass offenbar auch einwandfrei funktioniert bei der Installation wie im älteren Blog-Eintrag beschrieben.

Ein kurzer Test der VB6-Entwicklungsumgebung zeigt, dass grundsätzlich alles funktioniert. Ist zwar unter Windows 7 schon speziell zu installieren, nach wie vor aber die einzige IDE, die seit Windows 98 auf allen Windows-BS ohne Probleme läuft – zumindest bei meinen kleinen Hilfs-Programmen gabs noch keine Probleme.

Treiber wurden alle problemlos erkannt/übernommen, lediglich meine FS-Tools-Symbolleiste existiert nicht mehr, ist aber mit wenigen Klicks wieder hinzugefügt. Die Programm/Dateizuordnungen müssen natürlich auch wieder aktiviert werden (.cfg-Dateien mit Editor öffnen etc.).

Alles in allem hat das Update aber einwandfrei geklappt, zumindest was so auf den ersten Blick erkennbar ist. Mal schauen, ob im Arbeitsbetrieb da noch was ans Licht kommt.

Bootable Device erstellen

Offenbar ist das Grundprinzip ganz einfach und mit Windows-Boardmitteln zu bewerkstelligen:

1. Das Boot-Medium muss eine aktive Primary Partition haben.
Das geht am einfachsten mit diskpart über die CMD bzw. lässt es sich damit auch überprüfen, ob das Volume bereits richtig formattiert ist (bei UAC mit entsp. Rechten!)

Kern-Punkt für das Booten ist der Boot-Code, den man nicht so einfach kopieren kann. Dafür ist der bootsect.exe benötigt, die auf der Windows-Installations-DVD zu finden ist.
Mit dieser kann man mit dem Befehl

bootsect /nt60 X:

auf das entsprechende Laufwerk einen Bootsektor erstellen und den benötigen Boot-Code schreiben lassen.

Danach kann man mittels xcopy die Datein von einem vorhandenen/entpackten Image direkt auf das Medium kopieren mit

xcopy Quelle:\*.* /S /H /F Ziel:\“

Und schon hat man ein bootfähiges Medium, vorausgesetzt die kopierten Dateien beinhalten einen funktionierenden Bootloader.

USB Hub Stromverbrauch überschritten

Problem:
Beim anschließen eines USB-Hubs (13fach, aktiv) kommt die Meldung von Windows, dass der USB-Hub Stromverbrauch überschritten ist.

Bei Google wird man schnell fündig, vorausgesetzt man setzt Citrix ein:
http://wp.me/p4CvV5-2Y

Tatsächlich verschwindet der Fehler auch bei unserem System sofort, wenn man den Citrix Receiver (Version 4.2) deinstalliert.
Da unser System aber grundlegend auf Citrix aufbaut, ist das nur eine temporäre Lösung. Interessant ist auch, dass auf älterer Hardware mit der selben Citrix-Version (4.2.0.10) das Problem nicht auftritt.

Der Fehler findet sich auch in den Citrix-Doks:
http://docs.citrix.com/de-de/receiver/windows/4-3/receiver-for-windows-4-x-fixed-issues.html

Offenbar ist der Fehler erst ab Citrix Receiver Version 4.3.100 behoben.

Sie wurden mit einem temporären Profil angemeldet

Seit Windows 7 bzw. auch vermehrt durch die Umstellung von WinXP auf Win7 taucht diese „Fehler“-Meldung immer mal wieder auf.

Das Problem bei einem temporären Profil ist, dass alle getroffenen Einstellungen beim Abmelden wieder verloren gehen, obwohl ein lokales Profil bereits existiert.

Passieren dürfte das wenn Windows mit den Profil-Pfaden in der Registry durcheinander kommt. Leider schafft es Windows (7) bisher nicht, sich selbst zu korrigieren, obwohl die Logik dahinter recht einfach ist.

In einem beeindruckend guten KB-Artikel von Microsoft findet sich die Lösung (inkl. Screenshots):

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

Für lokale Profile empfiehlt sich die Methode 1 (das Ersetzen der Registry-Einträge unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Bei Firmennetzwerken mit Mandatory Profiles blockiert ein defektes Lokales Profil auch das weitere Anmelden (selbst bei aktivierter GPO „Zwischengespeicherte Kopien von servergespeicherten Profilen löschen“).
Hier ist die Methode 3 am schnellsten, einfach den Registry-Key mit dem def. Profil löschen und schon kann wird das Profil beim Anmelden wieder neu geladen.

Superbar-Probleme, Verknüpfungspfeil und was dabei schief gehen kann

Ich hatte kürzlich das Problem, dass sich auf einem Notebook plötzlich keine Icons mehr in die Windows 7 Superbar andocken ließen. Die Entstehung des Problems liegt lt. zahlreicher Google-Ergebnisse an einem veränderten Verknüpfungs-Verhalten von Windows (zB. ausgetauschter oder ausgeblendeter Verknüpfungspfeil).

Im Verdacht steht bei mir die Optimierungssoftware „TuneUp Utilities“, da diese als einzige einen solchen Systemeingriff vornehmen könnte. Die Version war nicht aktuell (2007) und konnte daher die Einträge nicht korrekt verändern.

Die Suche nach dem richtigen Schlüssel ist aufgrund der vielen Probleme etwas mühsam.
Folgende Registry-Einträge sind dabei falsch geändert worden (Restore-Key):

Die“ txt-Datei runterladen und in .reg umbenennen: SuperBar-Repair“ (inkl. Vorschau)

 

Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht verifiziert werden

Dieses Problem ist mir heute erstmalig begegnet und obwohl der“ erste Google-Treffer ein MS KB-Eintrag war (http://support.microsoft.com/kb/162797/de) konnte ich daraus keine Lösung des Problems erzielen.

Problembeschreibung:
Ein Windows7-Rechner mit fixer IP-Adresse“ in einer Windows Server“ 2003 Domäne brachte die Meldung der Vertrauenseinstellung plötzlich beim Anmelden.

Der Trick mit dem neu Zuordnen der Domäne funktioniert zwar, allerdings nicht von Dauer. Nach Analyse des Domänen-Kontos des betroffenen PCs konnte ich keinen Fehler feststellen und auch das entfernen und neu anlegen lassen des Kontos hat das Problem nicht behoben.
Die ausgedehnte Überprüfung (und ein zusätzliches Problem der Fernwartungssoftware) brachten mich auf ein Problem mit dem DNS-Eintrag, welcher überraschender Weise nicht mehr existierte.

Mittels AD-Konsole wurde der fehlende DNS-Eintrag auf die fixe IP des Rechners wieder eingetragen und sofort waren alle Fehler beseitigt.

Intel Management Engine Interface Installationsprobleme

Es kann vorkommen, dass sich der Treiber für das Intel Management Engine Interface nicht installieren lässt.

Äußern tut sich das im Gerätemanager als „unbekanntes Gerät“ mit den Hardware ID’s: PCI\VEN_8086&DEV_29B4

Häufige Ursache für die Verweigerung des Treibers ist die Namensgleichheit eines bestehenden Treiberpakets. Die Abhilfe dafür relativ einfach:

Im Treiber-Ordner (nach“ fehlgeschlagener Installation im C:\swsetup\SP38609\HECI) die HECI.inf Datei mit dem Editor öffnen und dort unter [Strings] die Einträge verändern:

Provider = „Intel“ MfgName = „Intel“
HECI_DeviceDesc = „Intel(R) Management Engine Interface XY“ HECI_SvcDesc = „Intel(R) Management Engine Interface XY
Location = „Intel(R) Management Engine Interface“

Danach die Installation erneut aufrufen und in den meisten Fällen läuft der Installationsvorgang ohne Fehler durch.

Wenn trotzdem noch Fehler auftreten, muss man etwas tiefer graben:

Möglichkeit 1:
In der Systemeinstellung alle Softwarepakete des „Management Engine Interface“ deinstallieren

Möglichkeit 2:
manueller Registry-Eingriff – Suchen nach „Management Engine“ und die RegKey-Werte umändern/umbenennen.

Danach aus dem Gerätemanager über die manuelle Pfadangabe“ eines Treibers prüfen, ob der „Management Engine Interface“-Treiber vom System erkannt wird, auswählen und Windows die Installation übernehmen lassen. Wenn das ohne die Meldung „Gleicher Treibertyp / Treibername vorhanden“ klappt, sollte der Eintrag aus dem Gerätemanager verschwinden und der Treiber ordnungsgemäß installiert sein.

XP Mode von Windows 7

Wenn ein Programm unbedingt eine Windows XP Umgebung benötigt, damit es funktioniert, kann man den Windows 7 „XP-Mode“ dafür verwenden.

Wird das Programm aber nicht installiert, sondern nur ein Ordner kopiert, dann erscheint die Verknüpfung für den direkten Start unter Windows 7 nicht automatisch.
Man muss die Verknüpfung allerdings nur im XP-Mode unter „c:/Dokumente und Einstellungen/All Users/Startmenü/Programme“ ablegen, dann erscheint die sonst automatisch generierte Verknüpfung auch im Windows 7 im Startmenü-Eintrag des XP-Modes.

Als nächstes werde ich versuchen, meinen alten Lexmark-Scanner damit wieder zugreifbar zu machen, für den es leider keine 64bit-Win7-Treiber gibt.