Schlagwort-Archive: Fehler

Qt5: LoadLibrary-Fehler mit RDP unter Windows (ATI, OpenGL, Nextcloud)

Das Qt-Framework wird von vielen Projekten genutzt um grafische Oberflächen auf allen Betriebssystemen einheitlich entwickeln zu können. Bekannte Softwarepakete, welche Qt nutzen, sind unter Anderem: Nextcloud-Client, Owncloud-Client, FileZilla, Quassel, Mumble, MiniTube, Bitcoin-Qt, Scribus, LuminanceHDR, Audacious, Clementine, LMMS, VLC, AviDemux-qt, Shotcut, OpenShot, LibreCAD, FreeCAD, OpenSCAD, QOwnNotes, Calibre, KeePassX, KeePassXC, Wireshark und BlueStacks.

Eigentlich eine praktische Sache, jedoch mit einem Haken: Mit Qt5 versuchte man viele grafische Operationen per Hardwarebeschleunigung zu erledigen. Dies sorgt für schnellere Programme und weniger Systemlast. Für die Ansteuerung der Grafikkarte nutzt man hierbei OpenGL, welches auf allen gängigen Betriebssystemen verfügbar ist. Leider tritt man sich hierbei auch einige Probleme ein, so ist z.B. Windows dafür bekannt qualitativ zweifelhafte Treiber zu verteilen, welche stark auf Gaming optimiert sind, aber bei anderen Operationen gerne ins Straucheln kommen.

Ein recht verbreitetes Problem tritt dann auf, wenn eine AMD-Grafikkarte wie z.B. Radeon oder im System steckt, man jedoch auf den Windows-Rechner per Remote Desktop (RDP) zugreift. Windows lädt – auch wenn RDP genutzt wird – die Grafikkartentreiber. Ein Fehler in den ATI-Treibern, welcher bereits seit Ende der 2010er-Jahre bekannt ist, führt jedoch dazu, dass in RDP-Sitzungen Grafikoperationen nicht in Software ausgeführt oder von der Grafikkarte berechnet und zurückgegeben werden, sondern sie versuchen diese Trotzdem komplett in der GPU zu verarbeiten und brechen die Anfrage letztendlich ab. In vielen Anwendungen äußert sich das in fehlenden Grafikelementen oder Fehlermeldungen. So lässt sich z.B. der Nextcloud-Client gar nicht starten und Quittiert den Versuch die GUI per RDP zu öffnen mit einem fatalen Fehler. Es ist somit nicht möglich die Software per RDP zu starten.

Fehlermeldung NextCloud-Client: „LoadLibrary failed with error 87: The parameter is incorrect.“

Glücklicherweise kann man sich hierbei einer Eigenheit von „Shared Libraries“ zu nutze machen, welche peeter123 auf GitHub vorschlägt: Jede App bevorzugt seine eigene Version, nur wenn sie selbst nichts mitliefert wird auf jene des Systems zurückgegriffen. Im Falle des OpenGL-Bugs kann man also einfach statt der Microsoft/ATI-Version eine weniger kaputte nutzen. Hierzu eignet sich z.B. die Variante des Mesa-Projektes, welche die OpenGL-Operationen nicht direkt an die Grafikkarte sendet. Um diese nun einzubinden lädt man auf der Releases-Seite die letzte Release-Version für mingw herunter (mesa3d-xx.yy.zz-release-mingw.7z), öffnet diese (z.B. mit 7Zip) und kopiert aus dem Ordner x64 (für 64-Bit-Systeme) die Datei „opengl32.dll“ in den Ordner des betroffenen Programms, also z.B. C:\Program Files\Nextcloud. Hierdurch greift die Änderung nur für diese eine App und beeinflusst nicht alle installieren Programme. Fortan sollten die Operationen der Software ohne GPU-Treiber laufen und die Applikation somit auch per RDP lauffähig sein.

Durch diese Änderung verliert man zur potentiell etwas Geschwindigkeit in der betroffenen App, dies sollte bei aktuellen Systemen aber nicht groß auffallen – insbesondere, wenn man diese ohnehin nicht häufig aktiv nutzt. Immerhin ist die Software so auch remote nutzbar. Mit fortschreitender Migration auf Qt6 sollte sich das Problem mit der Zeit auch ganz von selbst erledigen: Dies nutzt statt OpenGL die jeweiligen Funktionen des Betriebssystems, welche auch auf Windows nicht ganz so kaputt sind.

Windows-Update – Fehler 0x800f0831 beheben

Hinweis: Die Screenshots sind von einem älteren System, die Meldungen, Pfade und Vorgehensweisen sollten sich jedoch auch auf aktuelle Versionen übertragen lassen.

Und wieder das übliche Bild: Auf einem Windows-System sind nicht alle Updates installiert. Keine gute Idee, insbesondere bei Systemen, die an einem Netzwerk betrieben werden. Also schnell in die Einstellungen und Updates installieren – in der Theorie. Leider passiert es nach meiner Beobachtung immer wieder, dass Updates quer sitzen und sich nicht installieren lassen. Auch im aktuellen Fall sah man bereits: „Failed“ war im letzten Installationsversuch zu erkennen.

8 offene Windows-Updates, letzter Installationsversuch fehlgeschlagen

Auch ein manueller Versuch über „Install updates“ brachte kein Erfolg. Der Assistent schien fehlerfrei zu laufen, nach dem im Anschluss angeforderten Reboot war jedoch das Bild wieder identisch: Die Updates standen erneut als offen drin. Also erster Blick: Welche waren überhaupt betroffen. In den Details fanden sich neben den meist wenig aussagekräftigen Bezeichnungen auch die KB-Nummern, welche bei Microsoft die zugehörigen Dokumentationen beschreiben.

Liste der offenen Updates mit KB-Nummern

Hier kam dann der Microsoft Catalog unter https://www.catalog.update.microsoft.com/ ins Spiel: Über diese Webseite lassen sich per KB-Nummer einzelne Updates suchen und per Hand herunterladen. Hierbei etwas aufpassen: Oft sind die Updates für verschiedene Betriebssystemversionen und CPU-Architekturen mit der selben KB-Nummer eingestellt, beim Download lohnt es sich also doppelt hin zu schauen.

Microsoft Update Katalog-Webseite mit einzelnen Updates

Die zum Download angebotenen MSU-Dateien sollten sich direkt per Doppelklick öffnen lassen und einen Setup-Assistenten zeigen. Leider brachte auch die händische Installation keine Besserung – am Ende des Assistenten vermeldete das Ergebnis ein wenig aussagekräftiges „The following updates were not installed„. Auch die Ereignisanzeige des Betriebssystems verriet nicht mehr als eben jene wenig hilfreiche Statusmeldung.

An dieser Stelle wird oft eine Reparatur mit DISM.exe /Online /Cleanup-image /Restorehealth bzw. Sfc /scannow oder gar eine Neuinstallation empfohlen. Ist jedoch klar, dass das System keine weiteren Probleme hat, ist eine gezielte Reparatur jedoch oft weniger Zeitintensiv als eine vollständige Neuinstallation, insbesondere wenn die betroffenen Systeme nicht über ein Konfigruationsmanagement/Orchestration zur automatischen Installation verfügen.

Glücklicherweise erstellt Windows Update an diversen Stellen erweiterte Protokolle, welche die Fehlersuche erleichtern. Bei Installationsfehlern sind die CBS-Logs meist die hilfreichste Anlaufstelle. Die Korrekte Datei findet sich unter %systemroot%\Logs\CBS\CBS.log. Eine Suche nach “ Error “ (mit ein paar Leerzeichen dahinter) sollte die relevante Stelle schnell sichtbar machen. In diesem Fall handelte es sich um eine Inkonsistenz im Updatespeicher, die zugehörige KB-Nummer ist in solchen Fällen in der Fehlermeldung erkennbar. Wer diese vergleicht wird feststellen, dass es sich hierbei nicht um eins der zur Installation vorgemerkten Updates handelte. Stattdessen betraf es ein älteres Update, welches für die aktuelle Installation benötigt wurde. Das genannte, ältere Update war laut System installiert, fehlte in Realität jedoch. Ein solcher Zustand ist oft zu finden, wenn bei einem vorherigen Update der Rechner abstürzte.

Ausschnitt CBS-Log. Vorausgesetzte KB-Nummer in der Fehlermeldung erkennbar

Also zurück zum Catalog, dort kann man das defekte Update manuell herunterladen und nochmals installieren. Ist dies Erfolgreich sind Updatespeicher und Realität an dieser Stelle wieder auf einem konsistenten Stand und die Installation der neueren Updates kann fehlerfrei erfolgen. Möglicherweise muss der Vorgang für mehrere ältere Updates wiederholt werden. Hier kann es helfen in der Updatehistorie zu prüfen, welche Updates mit dem Betroffenen zeitgleich installiert wurden und diese – sofern nicht ersetzt – präventiv ebenfalls neu zu installieren. Am Ende sollten sich alle Updates installieren und das System so auf einen aktuellen Stand bringen lassen.