Archive for the ‘Problemlöser’ Category

Was gibt der Registrierungsschlüssel DHCPGatewayHardware her? Oder – wie kann man alternativ per Powershell das DHCP-IPv4-Gateway ermitteln?

28 September 2015

Hier mal etwas für Forensiker. Aus der Not geboren, dass nur eine Fernwartung beim Kunden möglich war – die nur einmal aufgebaut werden konnte, galt es herauszufinden, warum Netzprobleme bei der IPv4-Adressvergabe auftraten. Eigentlich sollten die Clientrechner IP-Adressen im Bereich 192.168.0.X bekommen aber effektiv bekamen fast alle Rechner eine im Bereich 192.168.1.X. Dadurch war kein Internetzugang mehr möglich und auch der Fileserver unter 192.168.0.1 war nicht mehr erreichbar. Da im konkreten Fall ein Speedport mit der Adresse 192.168.0.100 der DHCP-Server war, wurde zunächst eine Station mit einer fixen IP-Adresse im Bereich des Speedport versehen. Von dort aus war dann der Zugriff zum Speedport möglich. Auch das Internet mit einer Fernwartungssitzung klappte dadurch wieder. Jetzt galt es aber rauszubekommen, warum die Rechner teilweise falsche IP-Adresse bekamen. Nur wie macht man das, wenn man auf der einzigen Netzwerkkarte per Fernwartung aufgeschaltet ist?

Zunächst versuchte ich Scapy per Python ans laufen zu bekommen,  um dieses Script ausführen zu können: https://bitbucket.org/secdev/scapy/wiki/doc/IdentifyingRogueDHCPServers. Die Idee war ganz einfach einen Netzwerkmitschnitt über DHCP-Server-Ankündigungen zu machen. Aber leider beschwerte sich Scapy, beim Versuch der Installation, ständig über eine weitere, fehlende Abhängigkeit. Am Ende lief es auf jeden Fall nicht.

Wireshark wäre noch eine Option gewesen, da die WinPCap-Treiber wegen Scapy eh schon installiert waren. Aber Wireshark kann jeder.

Wie immer wäre mir eine Powershell-Lösung die liebste, aber leider gibt es noch nichts Vergleichbares zu Scapy. Bei der Suche nach der Powershell-Lösung bin ich allerdings über diesen Artikel gestolpert: http://www.ingmarverheij.com/read-dhcp-options-received-by-the-client/. Ich hatte zwar beim betreffenden Windows 7 Rechner keinen Eintrag mit DhcpInterfaceOptions aber zumindest der Eintrag DhcpGatewayHardware war vorhanden. Der Eintrag war als REG_BINARY mit dem Wert

c0 a8 01 01 06 00 00 00 e8 fc af ab c0 24

eingetragen. Der Wert von DhcpGatewayHardware ist zu finden unter HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{GUID}.

Per Powershell erreicht man den Wert über

$a = gwmi Win32_NetworkadapterConfiguration
$i = $a | where {$_.Description –like "*Intel*"}

$i.SettingID

$si = $i.SettingID

$ri = Get-ItemProperty -path "registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\$si" -name dhcpgatewayhardware | select DHCPGatewayHardware

$ri

Bei *Intel* sollte man den Hersteller seiner Netzwerkarte eintragen, für Realtek z. B. *Realt*, wenn es mehrere geben sollte, muss natürlich die betreffende herausgefiltert werden. Das entscheidende dabei ist, dass man die GUID der SettingID bekommt, über welche man weiß wo man in der Registrierung bei den Interfaces suchen muss.

Auf jeden Fall bekommt man am Ende bei $ri z. B.  diese Ausgabe:

DhcpGatewayHardware
——————-
{192, 168, 1, 1…}

Man sieht bereits, dies ist der falsche Wert, der am Anfang dafür gesorgt hatte, dass der Kunde nicht arbeiten konnte. Das interessante dabei ist, 192.168.1.1 entspricht hexadezimal genau “c0 a8 01 01”, die grüne Markierung verdeutlicht nochmal den Zusammenhang. Also ist der Zusammenhang schon mal hergestellt. Der hintere Wert e8 fc af ab c0 24 sieht wie eine MAC-Adresse aus, denn warum sonst sollte Microsoft den Eintrag DhcpGatewayHardware nennen?

Also noch die Bytes 8-14 ausgelesen und daraus eine MAC-Adresse gebastelt:

$mac=$ri.DhcpGatewayHardware[8..14]
$mac=$mac| foreach {$new=""} {$new+="{0:x02}:" -f $_} {$new}
$mac=$mac.TrimEnd(":")

$mac

Nun hat man in $mac die MAC-Adresse des DHCP-Servers, welcher die IP-Adresse 192.168.1.1 geliefert hatte.

Also mal Google bemüht und dies gefunden: http://macaddress.webwat.ch/hwaddr/E8:FC:AF. Hier wird E8:FC:AF Netgear zugeordnet:

Device mac address: E8:FC:AF
Base16 encoding: E8FCAF
producer name: NETGEAR INC.,

producer address:

350 EAST PLUMERIA DRIVE
SAN JOSE CALIFORNIA 95134
UNITED STATES

Jetzt galt es nur noch ein Gerät ausfindig zu machen. Aber mit dem Wissen, dass es sich um ein Netgear Gerät handelte, war der weitere Weg wesentlich einfacher, als wenn es irgendein Gerät im Netz gewesen wäre. Vor allem war dadurch auch klar, dass es sich nicht um einen gefakten bzw. Rogue-DHCP-Server handelte, welcher eine Attacke im Netz ritt.

Übrigens: Bei einem korrekt konfigurierten und funktionierendem Netz bekommt man, bei Anwendung obigen Scripts, einfach das Gateway mit der betreffenden MAC-Adresse, wenn DHCP aktiviert ist.

Windows Emergency Management Services (EMS) Konsole

25 September 2015

Mal wieder so eine Sache, die es schon jahrelang gibt, auf die man dann per Zufall stößt. Man kann mittels Emergency Management Services Rechner neu starten, die eigentlich einen Bluescreen darstellen. Offenbar geht dann auch noch Powershell, irgendwie. Da gerade die Zeit fehlt tiefergehende Tests zu machen, hier einfach mal die einschlägigen Ressourcen zum Thema:

https://www.myotherpcisacloud.com/post/Windows-Emergency-Management-Services

Mit dieser (USB):

Bcdedit.exe /EMS ON /EMSSETTINGS BIOS

bzw. dieser (RS-232):

Bcdedit.exe /EMS ON /EMSSETTINGS EMSPORT:COM2 EMSBAUDRATE:9600

Änderung vor einem Problem, kommt man auf die Kiste von extern wieder drauf und es meldet sich die Special Administration Console (SAC), wo man dann eine herkömmliche Shell hat.

Hier bestätigt tatsächlich jemand, dass dort auch Powershell möglich ist: http://serverfault.com/questions/554298/windows-serial-console.

Hier noch Beschreibungen zu den BCDEdit.EXE und EMS-Parameter: https://msdn.microsoft.com/en-us/library/ff542282%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Weitere Infos von MS: http://social.technet.microsoft.com/wiki/contents/articles/2469.windows-server-emergency-management-resources.aspx

Abgelaufene Aktivierungen erschweren einem das Leben unter Windows und wie man diese zurücksetzen kann

30 August 2015

Wer viel mit virtuellen Maschinen zu tun hat, der kennt vielleicht das Problem, man macht schnell eine Kopie eine VHD oder VHDX und setzt eine neue Maschine auf um etwas zu testen. Dann gerät die Sache in Vergessenheit und später fragt man sich, um was ging es eigentlich genau. Es ist ja kein Problem das System nochmals hochzufahren und nachzuschauen. Blöd nur, wenn dann auf einmal Microsoft nach der Aktivierung fragt. Noch blöder ist es, wenn man keine Aktivierung durchführen kann, weil man keine ordentliche Internetverbindung zustande bekommt.

Eine Lösung ist seit Windows Vista die Sache mit UTILMAN.EXE. Man benennt UTILMAN.EXE unter WinPE oder WinRE um und kopiert einfach CMD.EXE auf UTILMAN.EXE. Danach kann man am Anmeldebildschirm die Eingabehilfen aktivieren und schwupps öffnet sich die Eingabeaufforderung. Hier eine ausführliche Beschreibung, wie man zum Ziel kommt: https://www.petri.com/bypass-windows-server-2008-activation, hier etwas einfacher: https://www.technibble.com/bypass-windows-logons-utilman/.

Soweit so gut. Aktuell war aber eine Small Business Server 2003 R2 zur Mitarbeit zu überreden. Nur leider funktionierte obige Variante dort nicht. Zum Glück gibt es auch hier eine Alternative, die hier beschrieben steht: https://cyberwaves.wordpress.com/2011/06/20/windows-server-2003-aktivierung-umgehen-circumvent-activation/.

Hier nochmal die wesentlichen Punkte: Beim Aktivierungsassistenten drückt man STRG+L, dann auf Durchsuchen, dort gibt man C:\WIDNOWS\SYSTEM32\*.* ein und sucht dann CMD.EXE, klickt dort mit der rechten Maustaste und wählt “Ausführen als” aus. Man muss zwingend den unteren Eintrag mit der expliziten Anmeldung wählen und seine Anmeldedaten eingeben. Nun öffnet sich eine Eingabeaufforderung.

Leider bleibt diese nicht ewig erhalten, sondern LSASS.EXE sorgt dafür, dass nach einiger Zeit die Shell wieder geschlossen wird. Man kann problemlos wieder eine Shell öffnen. Wenn man etwas mehr Zeit braucht, kann man den Sysinternals Prozessexplorer starten, auch Regedit bleibt dauerhaft erhalten. Warum keine Ahnung, aber scheinbar kann man etwas aktivieren, damit die Programme erhalten bleiben. Durch den Prozessexplorer kann man auch LSASS auf den Suspendstatus setzen allerdings gibt es dadurch später irgendwann stress, durch ungewollte Blockierung.

Hier noch weiteres, interessantes Material: http://blog.didierstevens.com/2006/08/21/playing-with-utilmanexe/

Per Zufall bin ich nun noch auf etwas anderes gestoßen, damit ist die Variante perfekt. Also, wie oben die Eingabeaufforderung öffnen und dann diesen Befehl eingeben:

rundll32.exe syssetup,SetupOobeBnk

Der sorgt dafür, dass nach dem erneuten Start des Servers die Anmeldung ganz normal funktioniert!!

Komischer Eintrag im Taskmanager beim Autostartregister

1 August 2015

Der Taskmanager von Windows 8 und Windows 10 kann, wenn man die Detailanzeige aktiviert hat ein Register Autostart anzeigen. In diesem Fenster werden dann alle Programme aufgelistet, die beim Rechnerstart automatisch ausgeführt werden.

Mit der rechten Maustaste kann man zusätzliche Infos zu den Programmen erhalten, indem man die Punkte “Dateipfad öffnen” oder “Eigenschaften” anklickt. Wenn man allerdings einen Eintrag hat, der beide Punkte nicht zulässt, um was handelt es sich dann?

Mittels http://live.sysinternals.com/autoruns.exe kann man sich die Lage genauer anschauen. Dort wird man dann rausfinden, dass das entsprechende Programm einfach nicht mehr existiert, obwohl der automatische Starteintrag noch vorhanden ist. Dies führt dazu, dass die beiden genannten Menüpunkte nicht aufrufbar sind.

Man kann also den Eintrag in Autoruns löschen und wie von magischer Hand verschwindet postwendend auch der Eintrag im Tastmanager.

Man kann den Vorgang auch simulieren, indem man z. B. folgenden Eintrag per Powershell ausführt:

New-ItemProperty -Name Test -Value "C:\temp\test.exe" -Path "HK
CU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

Schupps taucht ein Eintrag beim Autostartregister im Taskmanager auf.

So bekommt man ihn wieder weg:

Remove-ItemProperty -Name Test -Path "HKCU:\SOFTWARE\Microsoft\
Windows\CurrentVersion\Run"

ProgrammXYZ funktioniert nicht mehr

28 Juli 2015

Wenn man aus heiterem Himmel eine Windowsfehlermeldung präsentiert bekommt, dass ProgrammXYZ nicht mehr funktioniert, so kann es dafür massig Gründe geben.

In dem auftauchenden Dialog kann man Problemdetails einblenden. Im konkreten Fall wurde als Fehlermodulname dhcpcsvc6.dll gemeldet, wobei sich dies sicher jederzeit ändern kann. Der Ausnahmecode war c0000005. Das Programm, welches den Fehler auslöste war ein altes VB6 Programm, welches sonst auf zig anderen Rechnern scheinbar klaglos arbeitet. Der Grund für den Fehler dürfte ein zum Prozess geladenes DLL-Modul, womöglich vom Virenscanner sein. Leider war eine schnelle Lösung notwendig und keine langwierige Fehleranalyse möglich.

Was auffiel, war, dass bei weiteren Tests auf einmal der Fehlermodulname StackHash_055e auftauchte. Ein ungewöhnlicher Name für ein Modul, zumal ohne Extension. Etwas googeln brachte dann dieses zutage: http://tdistler.com/2009/04/10/stackhash-and-application-crashes-on-windows, http://group-mail.com/microsoft-windows/windows-7-and-vista-stackhash-or-appcrash-error-fix/ und http://answers.microsoft.com/en-us/windows/forum/windows_other-windows_programs/problem-event-name-bex-error-message/cf5baf73-0877-4070-abfb-a2c3a17a9e10?auth=1.

Das Problem hatte also mit DEP zu tun: https://technet.microsoft.com/en-us/library/cc738483(v=ws.10).aspx.

Die schnelle Lösung war also DEP für das ProgrammXYZ einfach auszuschalten. Zwar nicht die feine Art aber damit lief es zunächst wieder.

Änderungen an Windows Firewall protokollieren mit Vergleich vorher/nachher

18 Juli 2015

Wenn man manchmal Programme installiert, dann ändern diese Einstellungen an der Firewall. Wenn man nun protokollieren möchte, was geändert wurde, so kann man sich – wie immer – Powershell bedienen.

Seit Windows 8 gibt es die Network Security Cmdlets, dort findet sich Get-NetFirewallRule. Hiermit kann man folgendes machen:

$fwVorher = Get-NetFirewallRule

Damit erzeugt man quasi einen Snapshot $fwVorher mit den alten Einstellungen der Firewall. Hier ein paar kurze Infos zum Status:

PS C:\Windows\system32> $fwVorher.Count
384
PS C:\Windows\system32> ($fwVorher|where enabled -eq True).Count
138

Es gibt also insgesamt 384 Firewallregeln, davon sind schon 138 aktiviert.

Jetzt geht man her und nimmt Änderungen am System vor. Hier aktiviere ich in einem neu eingerichteten Windows 8.1 Pro den RemoteDesktop und frage danach nochmal obige Informationen ab. Ich speichere es aber wieder in einer Variablen.

PS C:\Windows\system32> $fwNachher=Get-NetFirewallRule
PS C:\Windows\system32> ($fwNachher|where enabled -eq True).Count
141

Es sind also drei Regeln aktiviert worden. Stellt sich die Frage, welche das waren? Hier kommt nun wieder die Mächtigkeit von Powershell zum Tragen, denn wir kennen den Zustand davor und danach, somit können wir Powershell beauftragen die Unterschiede zu finden:

PS C:\Windows\system32> diff $fwVorher $fwNachher

InputObject                                                 SideIndicator
———–                                                 ————-
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>

Ja toll, super das wussten wir davor schon, dass es drei Regeln sind. Die Informationsaussage ist gleich 0. Nächster Versuch, das Compare-Object Cmdlet welches dem diff-Alias zugrunde liegt kennt einen Parameter Property mit dem kann man die Eigenschaft bestimmen, welche verglichen werden soll. Vielleicht klappt es ja damit:

PS C:\Windows\system32> diff $fwVorher $fwNachher -Property Enabled

                                                    Enabled SideIndicator
                                                    ——- ————-
                                                       True =>
                                                       True =>
                                                       True =>

Nicht viel besser wie die erste Variante.

OK, die Lösung des Problems ist ein weiterer Paramater: Passthru

Hier die Variante, wo alles schön ausführlich ausgibt:

diff $fwVorher $fwNachher -Property Enabled -PassThru

Eine etwas besser lesbare Variante wäre die hier:

PS C:\Windows\system32> (diff $fwVorher $fwNachher -Property Enabled -PassThru)| select dis*, des*, ena* | Fl *

DisplayName  : Remotedesktop – Schatten (TCP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, um das Spiegeln einer vorhandenen Remotedesktopsitzung
               zuzulassen. (TCP eingehend)
Enabled      : True

DisplayName  : Remotedesktop – Benutzermodus (UDP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, die RDP-Datenverkehr zulässt [UDP 3389]
Enabled      : True

DisplayName  : Remotedesktop – Benutzermodus (TCP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, die RDP-Datenverkehr zulässt. [TCP 3389]
Enabled      : True

Damit hat man nun ein schönes Protokoll, welche Firewallregel aktiviert bzw. deaktiviert wurde.

Übrigens Windows 10 Build 10158 bringt in der Pro Fassung 626 Firewallregeln mit! Da geht was…

Batchdatei als Administrator ausführen funktioniert nicht und was dies mit dem &-Zeichen im Benutzernamen zu tun hat

27 Februar 2015

Windows hat so seine Eigenheiten. Aktuell bin ich mal wieder über eine solche gestolpert, wo man sich fragt: Was geht da ab? Kurz zur Geschichte, ein Kunde hatte Probleme mit dem Adobe Reader Update: https://newyear2006.wordpress.com/2014/07/03/adobe-reader-installation-meldet-umgltiges-laufwerk-und-bricht-die-installation-ab/. Meine Antwort darauf war, eine Batchdatei anzulegen und diese mit Adminrechten auszuführen. Nur funktionierte die Variante nicht. Nach einigem hin und her wurde es dann klar, dass keinerlei Batchdatei des Kunden, welche über den Windows Explorer mit rechter Maustaste und “Als Administrator ausführen” angefordert wurde, klappte.

Dazu wurde eine einfach Test.BAT-Batchdatei im Benutzer-Verzeichnis C:\USERS\M&M geschrieben:

@ECHO Hallo
PAUSE

Also nichts weltbewegendes. Führt man diese Batchdatei in der Commandline aus, funktioniert alles wie gewünscht, ob mit oder ohne Adminrechte. Führt man die Batchdatei jedoch im Windows Explorer aus, funktioniert nur die Variante ohne Adminrechte. Bei der Variante mit den Adminrechten wird zwar nach dem Zulassen von CONSENT.EXE mit dem bekannten UAC-Dialog gefragt aber es wird effektiv nichts ausgeführt.

Bei der näheren Analyse mittels Procmon.EXE fiel dann folgendes auf, der Punkt  wo der CMD.EXE-Prozess erzeugt wird, wird die richtige Commandline übergeben:

Parent PID: 1996, Command line: "C:\Windows\System32\cmd.exe" /C "C:\Users\M&M\Test.bat" , …

Einige Zeilen später, wo die .BAT-Datei auf Vorhandensein geprüft wird, findet sich auf einmal diese Zeile:

QueryDirectory  C:\Users\M.*

Wo doch der Benutzer M&M heißt und nicht M.*!!

Und genau da entsteht nun das Problem, so dass wieder einige Zeilen später, der Versuch die Batchdatei zu lesen ins Leere läuft:

CreateFile C:\Windows\system32\M\Test.bat PATH NOT FOUND

Echt interessant! D. h. hier wird der Pfadname quasi in zwei Teile aufgelöst, einmal in C:\Users\M und einmal in M\Test.Bat, was eigentlich C:\Users\M&M\Test.Bat lauten sollte.

Dies bedeutet, dass keine Batchdatei des Benutzers M&M als Administrator ausgeführt werden kann! Sobald man aber hergeht und z. B. ein Verzeichnis C:\TestDir anlegt, dort die Test.BAT-Datei ablegt und diese als Administrator ausführt klappt wieder alles.

Was lernen wir daraus: Verwende unter Windows niemals einen Benutzernamen mit einem &-Zeichen!

Dieses Phänomen tritt von Windows 7 bis Windows 10 auf, wahrscheinlich sind aber generell auch ältere Versionen davon betroffen. Man könnte es zwar durch Escapen des &-Zeichen lösen aber im Punkt bei “Ausführen als Administrator” sind einem die Hände gebunden. Hier wird das Escapen beschrieben: http://www.robvanderwoude.com/escapechars.php.

Probleme beim Drucker umbenennen unter Windows

22 Januar 2015

Bei einem Kunden mit Windows 8.1 gab es beim Umbenennen eines Druckers folgende Meldung:

[Window Title]
Druckereigenschaften

[Main Instruction]
Die Druckereinstellungen konnten nicht gespeichert werden.

Es ist bereits ein Drucker oder eine Druckerfreigabe mit diesem Namen vorhanden. Verwenden Sie einen anderen Namen für den Drucker.

[OK]

Wenn man aber bei den Druckern geschaut hat, war nix von einem Drucker mit diesem Namen zu sehen. Es war allerdings davor ein Drucker mit diesem Namen da, denn dieser wurde zuvor gelöscht. Blöd war nur, dass in dessen Druckerwarteschlange noch ein kaputter Druckvorgang war und somit scheinbar der Druckvorgang nicht abgeschlossen werden konnte. Wie ich auf diese gewagte These komme?

Na ganz einfach so: Mittels dieses Artikels https://newyear2006.wordpress.com/2014/07/09/gruppierung-bei-windows-druckern-aufheben/ über diesen Punkt

shell:::{2227A280-3AEA-1069-A2DE-08002B30309D}

die Ansicht geändert, dass alle Druckertreiber einzeln dargestellt wurden. Dabei war aber noch nichts vom Ghost-Druckertreiber zu sehen. Nun aber die versteckten Dateien eingeblendet. Also ALT-Taste gedrückt, damit das Menü “Datei Bearbeiten Ansicht Extras” erscheint und dort bei Extras die Ordneroptionen aufgerufen. Hier wiederum das Register Ansicht ausgewählt und den Punkt “Ausgeblendete Dateien, Ordner und Laufwerke anzeigen” aktiviert. Schwups war der Ghostdruckertreiber zu sehen und konnte nun entfernt werden. Denkste!

Beim Versuch den Druckertreiber zu löschen erschien diese Fehlermeldung:

[Window Title]
Druckereigenschaften

[Main Instruction]
Die Druckereigenschaften können nicht angezeigt werden.

Überprüfen Sie den Druckernamen, und stellen Sie sicher, dass der Drucker mit dem Netzwerk verbunden ist.

[OK]

Was jetzt? Logischerweise Neustart des Rechners oder vielleicht nur Neustart der Druckerwarteschlange, dann ist der Ghost-Druckertreiber weg und das Umbenennen des ursprünglichen Druckertreibers ist möglich.

Wenn sich mal wieder die BIOS Einstellungen nicht speichern lassen

30 Dezember 2014

Nur für künftige Aktionen, damit ich das nächste Mal nicht unnötig Batterien verbrenne. Wenn das BIOS die Meldung:

CMOS Settings Wrong
CMOS Date/Time Not Set
Press F1 to run SETUP

erscheint, so sollte man die Motherboard-Batterie austauschen, wenn es danach aber immer noch nicht klappt, hilft ein CMOS-Reset! Scheinbar war es dem NVRAM davor nicht möglich die Daten ordentlich zu speichern, obwohl beim Verlassen des BIOS keine negative Meldung angezeigt wurde, dass die Daten nicht gespeichert werden konnten.

Mit den BIOS Einstellungen kann man viel Spaß haben: https://newyear2006.wordpress.com/2012/11/27/rechner-geht-einfach-nach-anzeige-von-starting-windows-aus/

Erweitertes Bootmenü bei Start von Windowsrechnern anzeigen

28 Dezember 2014

Bei neueren Rechnern und optimalen Bios bzw. UEFI-Einstellungen ist es manchmal recht schwer bzw. unmöglich beim Starten des Rechners das erweiterte Bootmenü mittels F8 zu aktivieren.

Wenn der Rechner bereits hochgefahren ist, kann man sich aber behelfen, indem man einen speziellen Parameter mittels BCDEDIT.EXE setzt. Dadurch wird das erweiterte Bootmenü immer angezeigt, bis es wieder explizit abgeschaltet wird:

bcdedit /set {bootmgr} displaybootmenu yes

Zum Ausschalten verwendet man dann später wieder:

bcdedit /set {bootmgr} displaybootmenu no

Nun kann man zwischen den Bootvorgängen in aller Ruhe das passende Auswählen. Hier noch eine bebilderte Anleitung: http://support2.microsoft.com/kb/2809468/en.

Die Variante klappt übrigens auch bei Windows 7. Besonders wertvoll ist es auch bei Verwendung von virtuellen Maschinen, wo man oft noch nicht den passenden Tastaturfokus hat.

Hier die aktuellste Beschreibung von BCDEDIT /set und die möglichen Parameter: http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202(v=vs.85).aspx.

Eine kurze Erklärung zu {bootmgr} erhält man über:

bcdedit /? ID

Hier noch der Link zur offiziellen BCDEDIT-Befehlszeilenreferenz: http://technet.microsoft.com/en-us/library/cc731662.aspx. Leider wie so oft ziemlich unbrauchbar.

Unter Windows 8 und Server 2012 bzw. dessen Nachfolger kann man mittels

bcdedit /set {current} onetimeadvancedoptions on 

das Menü auch nur einmalig für den nächsten Bootvorgang aktivieren.


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.