Archive for the ‘Problemlöser’ Category

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.

Wenn Maus und Tastatur an einem Windows Rechner nicht mehr reagieren

14 Dezember 2014

Ein Kunde hatte ein Problem mit seinem Windows 7 Rechner. Das interessante daran war, dass Tastatur und Maus nicht mehr funktionierten, wenn Windows hochgefahren war. Er hatte die Passworteingabe beim Hochfahren deaktiviert, so dass der Rechner immer bis zum Desktop bootete. So konnte man schon beobachten, dass alles sauber geladen wurde nur am Ende war keinerlei Maus und Tastatureingabe möglich. Der Mauszeiger konnte nicht einmal bewegt werden.

Der Rechner konnte problemlos durch drücken des Ausschaltknopf sauber heruntergefahren werden. Die Maus und Tastatur konnten an anderen Ports eingesteckt werden und es erschien die Meldung, dass Treiber installiert werden und dass das Gerät nun benutzt werden kann. Jedoch war dies nie möglich.

Bei weiteren Versuchen stellte es sich heraus, dass auch eine PS/2-Tastatur nicht funktionierte. Ein generelles Hardwareproblem konnte aber ausgeschlossen werden, da Maus und Tastatur problemlos unter WindowsPE oder im BIOS funktionierten. Ein weiterer Aspekt war, dass Multimediatasten wie E-Mail, Calculator usw. einer Multimediatastatur auch funktionierten.

Ein Starten des Rechners im abgesicherten Modus brachte leider auch nichts.

Also alles neu installieren? Nein.

Zwei Dinge helfen:
Die Verwendung der erweiterten Startoptionen und Aufruf von Computer reparieren. http://windows.microsoft.com/de-de/windows/advanced-startup-options-including-safe-mode#1TC=windows-7. Hier kann man die Systemwiederherstellung aufrufen, damit ein früherer Zustand aktiviert werden kann, der funktionierte – soweit vorhanden.

Die zweite Lösung wäre das entfernen von Kaspersky Maus und Tastaturtreibern. Dazu musste man nur in der Registrierung unter Upperfilters nach klkbdflt und klmouflt suchen und diese entfernen. Detailliert hier beschrieben: http://support.kaspersky.com/general/products/10663#block7. Diese Lösung funktionierte, weil der Kunde davor versucht hatte Kaspersky zu installieren und dabei scheinbar etwas schiefgegangen war. Hat man die Kaspersky-Treiber entfernt, stehen nur noch kbdclass und mouclass in der Registrierung. Übrigens muss man nicht zwingend die Kaspersky Rescue Disk verwenden, sondern kann auch mit einem WinPE oder Windows Bootmedium booten und die Registrierungseinträge darüber ändern.

Fehlermeldung von Windows Fax und Scan wegen fehlendem Faxkonto bei Druck über Faxserver

26 November 2014

Bekommt man an einem Windows Client beim Druck über einen Faxserver folgende Fehlermeldung an den Latz geknallt:

—————————

Windows-Fax und -Scan

—————————

Sie müssen erst ein Faxkonto erstellen, um Faxe mit dem ausgewählten Drucker senden zu können. Suchen Sie nach "Computer zum Senden und Empfangen von Faxen einrichten" in Hilfe und Support", um weitere Informationen zu erhalten.

—————————

OK  

—————————

 

So kann man sich behelfen, indem man zunächst bei Windows Fax und Scan im Menü unter Extras->Faxkonten den bestehenden Eintrag entfernt. Anschließend das Programm zumachen und noch bei Drucker und Faxgeräten den betreffenden Druckertreiber, der fürs Faxen über den Server eingerichtet war, über “Gerät entfernen” loswerden.

 

Nun wieder über Windows Fax und Scan über das Extra-Menü Faxkonten aufrufen, Hinzufügen anklicken und “Verbindung mit einem Faxserver im Netzwerk herstellen” auswählen. Dann den Servernamen eingeben usw. Danach sollte es ohne obige Fehlermeldung klappen.


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.