Gestern ist es passiert: Ich will morgens einen Kaffee zum Frühstück und die Nespresso Maschine füllt die Tasse nicht mehr richtig. Es kommt nur ein paar Sekunden Kaffee, dann stoppt die Maschine.
Ich bekam heute einen verzweifelten Anruf von meiner Mutter. Sie hat ein Problem mit ihrem Windows 10 Version 1909: Ihr Brother Drucker druckt nicht mehr.
Ich dachte zuerst an ein Problem mit dem USB Kabel. Vielleicht ist es ja beim Staubsaugen rausgerutscht. Oder die Tinte ist leer. Auch dann ist ja oft kein Ausdruck mehr möglich, auch nicht in schwarz-weis.
Das Problem war dann aber doch hartnäckiger. Windows hat den Drucker im USB einwandfrei erkannt. Auch der Statusmonitor des Druckers hat zwar einen niedrigen Tintenstand gemeldet, sonst aber kein Problem. Öffnen der Abdeckung wurde im Statusmonitor sofort erkannt. Ein Kommunikationsproblem schien es nicht zu sein.
Die Symptome waren sehr sonderbar. Eine gedruckte Datei war kurz in der Druckerwarteschlange zu sehen, aber nach einer Sekunde schon wieder verschwunden. Nur der Drucker druckt nicht.
Ein Blick in den Windows Eventviewer brachte mich dann auf eine Spur:
|
1 2 3 4 5 6 7 8 9 10 11 |
Name der fehlerhaften Anwendung: PrintIsolationHost.exe, Version: 10.0.18362.1, Zeitstempel: 0x8a048925 Name des fehlerhaften Moduls: gdi32full.dll, Version: 10.0.18362.900, Zeitstempel: 0xed06892c Ausnahmecode: 0xc000041d Fehleroffset: 0x00000000000d11b0 ID des fehlerhaften Prozesses: 0x1858 Startzeit der fehlerhaften Anwendung: 0x01d63fd99fcbaa61 Pfad der fehlerhaften Anwendung: C:\windows\system32\PrintIsolationHost.exe Pfad des fehlerhaften Moduls: C:\windows\System32\gdi32full.dll Berichtskennung: 95f153f9-d574-4050-99fc-2412665cd8e2 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist: |
Es stürzte bei jedem Versuch der Windows Dienst “PrintIsolationHost.exe” ab. Der Absturz passiert in der DLL gdi32full.dll. Interessant dabei ist die Versionsnummer der Datei: 10.0.18362.900
Diese Version wurde mit dem Windows Update KB4560960 ausgeliefert. Tatsächlich hatte der Computer vor kurzem dieses Update installiert. Microsoft weist auch in den Release Notes etwas versteck auf einen Zusammenhang mit Druckern hin:
Es verbessert die Sicherheit bei Verwendung externer Geräte (z. B. Gamecontroller, Drucker und Webkameras) und Eingabegeräte (z. B. Maus, Tastatur oder Stift).
Klar: Ein Gerät, das nicht mehr funktioniert ist vermutlich am sichersten.
Nach der Deinstallation des KB4560960 hat der Drucker dann wieder einwandfrei funktioniert.
So weit so gut. Leider würde Windows aber den fehlerhaften Fix beim nächsten Update wieder installieren und das Problem wäre wieder da. Updates grundsätzlich abschalten wollte ich auch nicht, da es ja andere wichtige Fixes geben könnte die installiert werden sollen.
Um zu verhindern, dass der Computer das update gleich wieder automatisch installiert habe ich vorerst das Update als “Hidden” markiert. Mit Bordmitteln scheint das bei einem aktuellen Windows 10 nicht mehr zu funktionieren. Daher habe ich ein Tool von Microsoft dafür verwendet.
Damit ist jetzt dieses spezielle Paket deaktiviert. Falls es einen Fix geben wird kann ich mit dem gleichen Tool die Installation des Paketes wieder erlauben.
Mittlerweile gab es vermutlich so viele Einzelfälle, dass Microsoft das Problem nicht mehr ignorieren konnte. Auf der Seite des Updates werden die Druckerprobleme jetzt als bekanntes Problem erwähnt und auf den KB4567512 als Fix verwiesen. Ich habe keine größere Eile den Fix auszuprobieren und werde das Update beim nächsten Maintenance-Termin bei meiner Mutter einspielen. Es gibt aber mehrere Berichte im Netz dass dadurch die Problem behoben sind. Vor einem Uninstall des KB4560960 empfehle ich also den KB4567512.
Weil in den Kommentaren die Version 2004 erwähnt wurde und das mittlerweile auch automatisch verteilt wird auch dazu ein Hinweis: Das Problem ist in allen Windows Versionen enthalten die ein Update bekommen haben. Es gibt auch jeweils einen Fix von Microsoft der auf der jeweiligen Seite verlinkt wurde. Wenn das Problem im Windows 1909 behoben wurde ist es nach einem Update auf 2004 erneut wieder da. In 2004 kann man dann direkt das Update KB4567523 installieren um das Problem zu beheben.
Ein Smartphone mit WhatsApp zeigte plötzlich nur noch die Telefonnummern und nicht mehr die Namen der Kontakte an.
Wie sich herausstellte hatte die App nicht mehr die Permission auf die Kontakte zugreifen zu dürfen. Es ist unklar wie es verschwunden ist, lies sich aber einfach reparieren.
Im Smartphone die Einstellungen öffnen, dann bei Apps & notifications zu WhatsApp auf die Detailseite gehen. Dort die Permissions anzeigen lassen. Am sichersten ist es, der App alle gewünschten Permissions zu geben. Erforderlich ist auf jeden Fall Contacts.
Danach WhatsApp öffnen und auf das new chat icon klicken. Im Menü “⋮” dann Refresh auswählen. Danach sollten die Kontakte wieder mit Namen angezeigt werden.
Der Google Kalender zeigte bei mir keine Geburtstage meiner Kontakte an. Nicht auf Android und nicht im Browser.
Komisch daran war, dass es nur manche Kontakte betroffen hat. Andere Geburtstage waren sichtbar. Weiterlesen
Ich hatte bei mir ein neues NAS eingerichtet und mich gewundert, dass die Festplatten nicht schlafen gehen. Es hat sich herausgestellt dass es an der “Schnellformatierung” lazy_itable_init vom ext4 Dateisystem liegt. Damals wolle man das neue Dateisystem schnell benutzbar haben. Im Commit sind nähere Details erklärt.
Wenn man nichts speziell einstellt ist auch noch Stunden später immer wieder ein Zugriff auf die Platte sichtbar. In dieser Zeit werden im Hintergrund die inodes im Dateisystem auf 0 gestellt. Dadurch sind die Festplatten auch nicht idle und gehen nicht schlafen.
Lösbar ist das ganze auf drei Arten.
Man kann einfach einige Stunden (oder Tage) abwarten, dann erledigt sich das Ganze von selbst. Es gibt leider keine “schöne” Möglichkeit festzustellen wie weit der Prozess schon fertig ist. Mit dumpe2f auf das block device (z.B. dumpe2fs /dev/md0 ) kann man nachsehen wie viele der groups schon fertig sind (INODE_ZEROED) oder noch nicht initialisiert sind (INODE_UNINIT).
Wenn man rechtzeitig daran denkt, dann kann man das Dateisystem auch gleich beim Formatieren initialisieren lassen. Man stellt die lazy_itable_init option ab. Das dauert dann ein wenig länger, danach ist aber alles erledigt. Bei 4TB RAID1 waren es bei mir circa 15 Minuten:
|
1 |
mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/md0 |
Der Hintergrundprozess mach per default 10 mal so lange Pause wie das letzte Schreiben gedauert hat. Dieser Parameter lässt sich mit einer mount option beeinflussen. Wenn man init_itable auf 0 stellt, dann initialisiert der Kernel worker ohne Pause die inodes. Entweder beim initialen Mount mit angeben oder remounten. Dabei sollen natürlich keine Dateien geöffnet sein.
|
1 |
mount -o remount,init_itable=0,rw,relatime,data=ordered /mnt/md0 |