Blog-Leser Philipp B. hatte sich vor einer Woche per E-Mail bei mir gemeldet, weil er in seinem Rechnerpark auf einen nervigen GDI+ Fehler gestoßen ist. Der Leser schreibt, dass es in seinem Umfeld Windows 11 24H2-Maschinen betrifft, und er möchte wissen, ob ggf. weitere Blog-Leser entsprechende Beobachtungen gemacht haben.
Eine Lesermeldung
Der Leser ist IT-Techniker und schrieb mir, dass er seit einigen Woche vor einem Problem steht, was bei ihm im Haus ca. 10 Windows 11 24H2-Installationen (von mehreren Hundert Clients, auch bei Kunden) betrifft. Die Maschinen haben Probleme mit der Grafikausgabe – Philipp nennt es einen GDI+ Fehler.
Windows GDI+ ist eine klassenbasierte API für C/C++-Programmierer. Diese ermöglicht Anwendungen, Grafiken und formatierten Text sowohl auf der Videoanzeige als auch auf dem Drucker zu verwenden. In diesem Kontext scheint es Probleme mit verschiedenen Programmen unter Windows 11 24H2 zu geben. Das Fehlerbild stellt sich folgendermaßen dar:
- In diversen Softwareprogrammen (z.B. Remote Desktop Manager von Devolutions oder auch Greenshot) werden diverse .net-Fehlermeldungen angezeigt, die auf ein Problem mit GDI+ hindeuten.
- In allen Office 365-Applikationen äußert sich das Fehlerbild so, dass sämtliche Schriften (z.B. Button-Beschriftungen oder die Baumansicht in Outlook) weiß sind. Ein Neustart der betroffenen Applikation behebt das Problem nur kurzfristig.
Dabei ist es unabhängig, ob die Geräte neu mit Windows 11 24H2 installiert oder von einer älteren Windows 11-Version aktualisiert wurden. Geräte mit einem älteren Versionsstand als Windows 11 24H2 funktionieren mit den gleichen Softwareprogrammen fehlerfrei.
Der Leser merkt an, dass er im Internet nicht wirklich was über das Fehlerbild gefunden habe. Ihn würde interessieren, ob andere Benutzer auch betroffen sind.
Ergänzende Informationen
Inzwischen hat mir der Leser noch drei Screenshots der Probleme zukommen lassen, die ich nachfolgend einstelle. Nachfolgender Screenshot zeigt eine Benachrichtigung in Outlook-Classic, wo mutmaßlich keine Schriftart mit darstellbaren Zeichen gefunden wurde.
Der nachfolgende Screenshot zeigt das Fenster von Microsoft Outlook – spontan hätte ich gesagt, dass die Multifunktionsleiste nicht sauber dargestellt wird. Die Multifunktionsleiste wird unter den Symbolen nicht durch eine horizontale Linie abgeschlossen, sondern die Gruppen-Separatoren ziehen sich bis nach unten.
Als letzten Screenshot hat mir der Leser noch die nachfolgende Darstellung des Windows 11 24H2 Startmenüs zukommen lassen.
Auch hier ist eine kaputte Darstellung des Startmenüs zu sehen, die Zeichen der Startmenü-Einträge werden durch viereckige Platzhalter ersetzt, Icons erscheinen nicht. Da ist was im Argen.
Unterschiedliche Hardware-Konstellationen
Ursprünglich hatte der Leser nichts zur verwendeten Hardware und zu den Grafiktreibern geschrieben. Das hat er in seiner ergänzenden Mail, in der auch die Screenshots enthalten waren, nachgetragen. Seiner Aussage betrifft es sowohl Hardware mit Intel Grafikkarten (Notebooks Fujitsu / Dell) als auch virtuelle VMs mit Windows 11 24H2 unter VMware by Broadcom.
Die in nachfolgenden Kommentaren geäußerte Vermutung, dass es mit einem Grafiktreiber zusammen hängt, dürfte damit vom Tisch sein. Auch der Aufhänger am Programm Greenshot trifft es imho nicht, da der Leser ja auch Office als betroffen angibt. Die Theorie, dass es mit .NET oder einem anderen fehlenden Update zusammen hängt, ist irgendwie auch "wackelig". Der Leser schrieb mir (bzw. bestätigte in einem Telefonat), dass die Maschinen voll gepatcht sind. Zudem dürfte das Windows 11 24H2 Startmenü auch nicht das in obigem Screenshot sichtbare Verhalten zeigen.
Aktuell gibt es aus meiner Sicht noch keinen Plan, was diese Störungen verursacht. Wie oben beschrieben, betrifft es nur quasi "ein Dutzend" Windows 11 24H2-Systeme in unterschiedlichen Ausprägungen.
MVP: 2013 – 2016
Nvidia ist aktuell betroffen bei älteren Maschinen vom RowHammer
vielleicht mal angepassten Treiber von Hersteller verwenden?
HP stellt teilweise unterschiedliche Treiber für 23H2 und 24H2 bereit.
ansonsten einfach mal Grafikkarte deinstallieren im Geräte Manager, mit 24H2 gibt's einige Zicken mit Geräten (Bluetooth, Smartcard,…)
Die konkreten Fehlermeldungen wären jetzt interessant gewesen. Vor allem haben .NET-Programme doch typischerweise ihre eigene Oberflächenbibliothek wie WinForms oder WPF, basieren die überhaupt auf GDI+?
WinForms nutzt zb. für die Bitmap und Graphics Klasse intensiv GDI+. Da kann man sich schon gut vorstellen das zb. Greenshot zum speichern eines Screenshots GDI+ verwendet um ein PNG zu erstellen. Auch das zeichnen auf dem Screenshot kann durch GDI+ erfolgen.
Ich gebe Dir aber recht, eine konktete Fehlermeldung wäre schon interessant.
Hier habe ich eine Intel-Monokultur (nur Chipsatzgraphik in verschiedenen Versionen ganz unterschiedlichen Alters) und keine Probleme dergleichen gehabt.
Das klingt doch eher nach fehlenden .net (Desktop) Runtimes?
Das erwähnte Programm "Greenshot" basiert auf "NET Framework 2.0" (*1).
Diese Version ist nicht mehr im ISO von Windows 11 enthalten, man kann es nicht mehr direkt auf Windows 11 installieren, sondern man muss das Feature "NET Framework 3.5" on-demand online nachinstallieren, denn da ist die v2.0 enthalten (*2).
Bei Windows 10 ist NET v3.5 noch direkt ohne es on-demand von den Microsoft-Servern nachladen zu müssen aktivierbar.
NET Framework 4.x ist nicht direkt abwärtskompatibel zu NET v2, aber laut den Greenshot-Programmierern funktioniert es auch mit NET v4.x, allerdings kann Windows diese Kompatibilität nicht selber feststellen und meckert dann, wenn NET v3.5 fehlt. Das betraf auch schon Windows 8 (*3).
Manchmal schlägt die Installation von NET 3.5 fehl, dann muss das Feature mit dism installieren bzw aktivieren (*4):
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All
Falls das auch nicht funktioniert, dann muss man NET 3.5 in ein Offline-Image nach-installieren bzw dort aktivieren und Windows 11 dann mit der neuen ISO mit dem bereits voraktivierten Feature installieren (*4).
Ob dieses "GDI+"-Problem damit allerdings gelöst ist weiß ich auch nicht.
Man muss NET 3.5 aber trotzdem nachinstallieren und das Feature aktivieren (also anhaken).
Also mal machen und berichten, ob der Fehler weg ist.
Quellen:
(*1):
getgreenshot. org/faq/are-there-any-dependencies-to-other-software-frameworks/
(*2):
learn. microsoft. com/en-us/dotnet/framework/install/dotnet-35-windows
(*3):
getgreenshot. org/faq/why-does-windows-8-suggest-to-install-earlier-net-versions-when-starting-greenshot/
(*4):
learn. microsoft. com/en-us/windows-hardware/manufacture/desktop/deploy-net-framework-35-by-using-deployment-image-servicing-and-management–dism?view=windows-11
Zitat von Microsoft:
GDI+ is the portion of the Windows operating system
[…]
The GDI+ managed class interface (a set of wrappers) is part of the .NET Framework
learn. microsoft. com/en-us/dotnet/desktop/winforms/advanced/about-gdi-managed-code
In Windows 11 24H2 ist "NET Framework 4.8.1" integriert.
Die selbe Net Framework Version ist allerdings schon seit Windows 11 22H2 integriert.
learn. microsoft. com/de-de/dotnet/framework/install/versions-and-dependencies
Daraus folgt:
a) GDI+ ist Teil von "NET Framework 4.8.1" (nicht von "NET Desktop")
b) das fehlende "NET Framework 2.0" verursacht die GDI+ Fehler nicht direkt, wegen a)
c) Weil "NET Framework 4.8.1" schon seit Windows 11 v22H2 integriert ist liegt der GDI+-Fehler nicht direkt an dieser Version.
2.
Paint.NET benutzt seit v4.3.3 die "NET Desktop Runtime 6".
Diese wird aber mitgeliefert und muss nicht manuell installiert werden.
HandBrake benutzt seit v1.4.2 die "NET Desktop Runtime 6".
Diese wird nicht mitgeliefert und muss manuell nachinstalliert werden.
"NET Framework 4.8.1" alleine reicht in beiden Fällen nicht aus.
Problem:
Das letzte Update für "NET Desktop 6" gab es im November 2024.
Das letzte Update für "NET Desktop 7" gab es im Mai 2024 (also EOL von v7 schon vor v6).
Windows 11 unterstützt nur noch "NET Desktop 8 und 9", aber nicht mehr "NET Desktop 6 und 7":
learn. microsoft. com/en-us/dotnet/core/install/windows
Ob die Kombination "NET Deskop Runtime 6" und Windows 11 noch fehlerfrei funktioniert wird von Microsoft nicht garantiert.
3.
"Remote Desktop Manager von Devolutions" benutzt "Microsoft .NET 9.0".
docs. devolutions. net/de/server/overview/system-requirements/
Also muss man die "NET Desktop Runtime 9" nachinstallieren.
Microsoft .NET Desktop Runtime 9.0.7:
dotnet. microsoft. com/en-us/download/dotnet/9.0
Dort in der rechten Fensterhälfte in der Tabelle ".NET Desktop Runtime 9.0.7", in der Zeile "Windows", Spalte "Installers" auf "x64" klicken um die richtige Version runterzuladen.
4.
Es gibt auch noch "ASP.NET Core Runtime" (für Web-Apps statt Desktop-Apps, jeweils v6-9) und ".NET Runtime" (ohne "Desktop", jeweils v6-9).
Dieser Wust von NET Variationen und Versionen und teilweiser nicht vorhandener Abwärts- und Aufwärts-Kompatibilität erstens innerhalb NET selber und zweitens gegenüber Windows ist Schwachsinn zum Quadrat.
Daher sollte man am Besten NET (irgendwas) gar nicht mehr benutzen.
1+
Greenshot hat seit 2 Tagen eine neue Version, vielleicht hilft es.
Greenshot 1.3.292, 16 Jul 2025
https://getgreenshot.org/downloads/
Nachtrag zu Greenshot:
https://www.deskmodder.de/blog/2025/07/18/greenshot-1-3-290-als-finale-version-freigegeben-korrigiert-eine-sicherheitsluecke-cve-2023-34634/
Was ich mir durchaus auch vorstellen kann ist, das die gdiplus.dll in den System Ordnern, durch was auch immer, entweder durch eine ältere oder defekte Version ausgetauscht wurde. Auf einem Windows PC tummeln sich soviele unterschiedliche Versionen der gdiplus.dll. Ein Programm sucht zuerst die DLL im eigenen Programmordner und wenn dort keine ist, wird in den anderen bekannten Ordnern gesucht. Es gab soviele unterschiedliche Versionen der DLL mit diversen Bugs. Auch gab es Versionen wo einige Funktionen noch nicht enthalten waren.
Zwei Beispiele für Programme, die eine eigene gdiplus.dll im eigenen Programmordner mitbringen:
Ashampoo Burning Studio 2025:
gdiplus.dll,
Version: 5.1.3102.1360,
Dateidatum: 14.10.2024,
Dateigröße: 1.645.320 Bytes,
Signatur "Microsoft" vom 04.Mai 2024
Softmaker Flexi PDF 2022:
gdiplus.dll,
Version: 5.1.3102.1360,
Dateidatum: 08.04.2024,
Dateigröße: 1.642.752 Bytes,
Signatur "Iceni Technology Ltd." vom 09.November 2009
Warum unterschiedliche Dateigröße trotz identischer Version (liegt das an der Signatur)?
Warum unterschiedliches Datum trotz identischer Version?
Warum Signatur einmal nicht von Microsoft, sondern von "Iceni"?
DIESE gdiplus.dll könnte ja irgend etwas anderes sein, verdächtig.
Warum packt Softmaker bzw "Iceni" keine normale von Microsoft signierte gdiplus.dll dort rein?
Signaturdatum einmal von vor 16 Jahren und einmal vom vorigen Jahr?
Alle Microsoft-Updates automatisch installiert,
Und Standard-Frage: Zeigt
winget update
keinerlei fehlende Updates?
Welche Antivirensoftware?
Gebetsmühlenartig kann ich leider nur wiederholen wir immer, dass es bei uns und all unseren Kunden keinerlei Probleme gibt wir üblich. Intel und AMD Systeme, alle Win11 24H2 (egal wie alt die Hardware ist) und nur ESET, Office 365, DATEV u. v. m. (nahezu alle unterschiedlich, aber das die umfangreichsten Produkte).
sfc /scannow und dism… schon mal probiert?
Danke für die Rückmeldungen; es betrifft ja nicht nur Greenshot, sondern auch andere Applikationen (wie auch z.B. Office365-Apps); ich hatte an Hr. Born ein paar Screenshots geschickt, evtl. kann er diese noch im Post ergänzen.
Gerade im devolutions Remote Desktop Manager aufgetreten:
ExternalException – A generic error occurred in GDI+.
at System.Drawing.Graphics.CheckErrorStatus(Status status)
at System.Drawing.Graphics.DrawString(String s, Font font, Brush brush, RectangleF layoutRectangle, StringFormat format)
at Devolutions.RemoteDesktopManager.Services.BusinessImageService.GetAvatarImage(String displayName, Boolean round, Int32 size)
at Devolutions.RemoteDesktopManager.Services.BusinessImageService.GetUserImage(String display, Int32 size, String email, String gravatarEmail)
at Devolutions.RemoteDesktopManager.Managers.AvatarManager.GetUserLargeImage(String display, String email, String gravatarEmail)
at Devolutions.RemoteDesktopManager.Managers.HtmlExportManager.GenerateAdditionalInfoSectionRows(ConnectionEngine engine, Connection connection, HtmlExportParameters parameters)
at Devolutions.RemoteDesktopManager.Managers.HtmlExportManager.GenerateEntryModel(ConnectionEngine engine, List`1 connections, String title, HtmlExportParameters parameters)
at Devolutions.RemoteDesktopManager.Managers.HtmlExportManager.Export(ConnectionEngine engine, List`1 connections, String title, HtmlExportParameters parameters)
at Devolutions.RemoteDesktopManager.Frames.FreDashBoardBase.SetOverviewHtml(ConnectionEngine engine, Connection connection, FreWebView webBrowser)
at Devolutions.RemoteDesktopManager.Frames.FreDashBoardBase.c__DisplayClass220_0.b__1()
at Devolutions.RemoteDesktopManager.Managers.ThreadManager.PushTimer_Tick(Object sender, EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(HWND hWnd, MessageId msg, WPARAM wparam, LPARAM lparam)
———————— extended stack ————————
at Devolutions.RemoteDesktopManager.Forms.FrmErrorMessage.ShowErrorMessage(ConnectionEngine engine, Exception exception, String message, String title)
at Devolutions.RemoteDesktopManager.Forms.FrmErrorMessage.ShowErrorMessage(ConnectionEngine engine, Exception exception, String title)
at Devolutions.RemoteDesktopManager.Managers.LogManager.OnThreadException(Object sender, ThreadExceptionEventArgs t)
at System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception ex)
at System.Windows.Forms.NativeWindow.Callback(HWND hWnd, MessageId msg, WPARAM wparam, LPARAM lparam)
at Windows.Win32.PInvoke.DispatchMessage(MSG* lpMsg)
at System.Windows.Forms.Application.LightThreadContext.FPushMessageLoop(msoloop uReason)
at System.Windows.Forms.Application.LightThreadContext.RunMessageLoop(msoloop reason, Boolean fullModal)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(msoloop reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(msoloop reason, ApplicationContext context)
at Devolutions.RemoteDesktopManager.Program.Main(String[] args)
Hast du ".NET Desktop Runtime 9.0.7" installiert oder nicht?
Genau so ein fehlendes Updates zeigt z. B.
winget update
an oder somit auch UniGetUI.
Sofern alle über denselben Grafikkartenhersteller verfügen: Auch hier muss man von Zeit zu Zeit ggf. manuell nachschauen. Wir nutzen vornehmlich AMD-CPUs mit integrierter Grafik (wir haben nur Geschäftskunden ohne High-End-Grafik-Bedarf/GPU-Leistung), werden per Newsletter von AMD informiert und installieren dann auf allen System einfach den Allround-Updater von https://www.amd.com/de/support/download/drivers.html
Ich kann nur vermuten, dass all unsere Nicht-Probleme bei allen Kunden mit ordentlichem Patch Management zusammen hängen, da alles andere ansonsten nicht einheitlich ist.
Die Kunden mit mehr Clients und die Intune einsetzen für zentrales und (teil)automatisches Patch Management, haben einen eigenen Mitarbeiter vor Ort, der sich darum kümmert.
Ja, die .net-Version wird zusammen mit dem RDM installiert.
Version 9.0.35017
Zitat aus dem Artikel:
"Leider hat er nichts zur verwendeten Hardware und zu den Grafiktreibern gesagt. Aber vielleicht trägt er es in den Kommentaren nach."
—
?
Das Thema hängt noch – es war Wochenende – und nun möchte ich erst einen Spaziergang machen – wenn ich dann Zeit und Motivation habe, trage ich die Screenshots des Lesers nach. Müsst ihr verstehen, dass ich aktuell die Prioritäten anders setze.
Das ging gar nicht gegen dich, sondern es war eine Aufforderung an Philipp, diese Infos nachzutragen in einem Kommentar.
Er hatte mir die Infos geliefert – die sind nun als Screenshot mit einigen Erläuterungen im Beitrag eingearbeitet – danke für eure Geduld (ab Donnerstag habe ich mir eine ruhigere Kugel gegönnt und nur den SharePoint-Sachverhalt noch aufbereitet – Garten und Frau hatten Priorität – jetzt regnet es hier in Strömen und man kann eh nichts draußen machen ;-).
Unter dem Strich: So, wie es sich aktuell darstellt, sieht die Geschichte richtig krass aus. Ich könnte mir noch vorstellen, dass eine auf den Clients installierte Software da Mist macht. Da ist aber die Frage, ob Philipp die Chance hat, eine betroffene Maschine neu aufzusetzen (bei Notebooks möglich, vorher aber ein Backup ziehen, um ein Zurücksetzen zu ermöglichen).
Bei einer VM bestände die Möglichkeit, diese zu sichern bzw. zu clonen. Im Clone schauen, ob der Effekt auftritt und dann die Anwendungssoftware schrittweise deinstallieren und prüfen, ob der Effekt weg geht.
Hier wäre auch eine Reparatur-Installation per InPlace-Upgrade denkbar, um zu testen, ob das Drüber-Installieren kaputte Dateien im GDI+ repariert.
Oha, wenn man mal etwas recherchiert, dann gibt es da tatsächlich ein paar fiese Probleme mit Windows 11 v24H2 und NET, die teilweise Bugs sind und teilweise Absicht von Microsoft sind, damit neuere NET-Programme inkompatible werden mit Linux und MacOS.
1.
NET reagiert tatsächlich unterschiedlich, je nachdem ob es auf Win11 v24H2 oder 23H2 läuft.
NET Framework 4.8.x funktioniert sowohl auf 23H2 als auch auf 24H2 identisch.
NET 8 und 9 hingegen (vermutlich auch 6 und 7) funktioniert auf 23H2 fehlerfrei, während das gleiche Programm auf v24H2 Fehler zeigt.
siehe die 7 Screenshots ab User "Olina-Zhang" und folgendem User:
github. com/dotnet/winforms/issues/12910
Das ist also praktisch die Bestätigung für dein Problem.
2.
NET wirft Fehler aus, wenn Lese- oder Schreibrechte für Ordner fehlen:
"Check if IIS user has write permission to the specified folder."
learn. microsoft. com/en-us/answers/questions/1053738/c-the-dreaded-a-generic-error-occurred-in-gdi-exce
"First of all make sure, that the desired folder has Read/Write permissions. Changing the permissions solved this problem for me."
stackoverflow. com/questions/15571022/how-to-find-reason-for-generic-gdi-error-when-saving-an-image
"If you are getting that error , then I can say that your application doesn't have a write permission on some directory."
stackoverflow. com/questions/1053052/a-generic-error-occurred-in-gdi-jpeg-image-to-memorystream
3.
"System.Drawing.Graphics"
In ".NET Framework 4.8.1" gehört die Funktion "System.Drawing.Graphics" zum Namespace "System.Drawing" und das steckt in der Assembly "System.Drawing.dll":
learn. microsoft.com/en-au/dotnet/api/system.drawing.graphics?view=netframework-4.8.1
In NET 8 und 9 hingegen steckt der selbe Namespace "System.Drawing" in einer anderen Assembly "System.Drawing.Common.dll"
learn. microsoft. com/en-au/dotnet/api/system.drawing.graphics?view=windowsdesktop-9.0&viewFallbackFrom=dotnet-plat-ext-9.0
Probleme dabei:
– "System.Drawing.Common.dll" wird nicht immer mitgeliefert, sondern es gibt ein extra NuGet-Packet dafür, das man nachinstallieren muss, falls das Assembly fehlen sollte:
nuget. org/packages/System.Drawing.Common/#package-manager
– Net Framework und NET bis einschließlich NET 5 ist mit Linux und MacOS prinzipiell noch kompatibel, weil die GDI+-Funktionalität in der Bibliothek "libgdiplus" für Linux und MacOS nachgerüstet werden kann.
Ab einschließlich NET 6 funktioniert das nicht mehr, denn:
"In .NET 6 und höheren Versionen wird das NuGet-Paket System.Drawing.Common nur unter Windows-Betriebssystemen unterstützt."
siehe roter Kasten mit den Hinweisen:
learn. microsoft. com/de-de/dotnet/api/system.drawing?view=net-8.0
Da hat Microsoft absichtlich eine Inkompatibilität eingebaut, damit neuere NET-Programme nicht mehr unter Linux und MacOS laufen können.
Gibt es denn im Umfeld von Phillip auch funktionierende "Windows 11 24H2-Installationen" oder betrifft das alle "Windows 11 24H2-Installationen"?
Präzise Sprache wäre wichtig.
Die v23H2-Versionen zählen nicht.
– Support-Ticket bei Microsoft eröffnen, denn Microsoft kann dank Telemetrie viel besser sehen, woran das liegt.
– Auf den defekten Systemen mal einen neuen sauberen lokalen User mit Adminrechten anlegen und schauen, ob es am Profil liegt oder an fehlenden Lese- oder Schreibrechten
– Falls es alle 24H2 Installationen betrifft, dann würde ich mal die Win11-24H2-ISO neu erstellen, die Checksumme der ISO prüfen und alle Systeme neu installieren.
Ok, ist mein Fehler, ich dachte es wäre klar aus dem Text hervor gegangen (ist zu viel bei mir im Hinterkopf, was ich implizit als gegeben an Wissen voraussetze). Hier mein Wissensstand:
– Nur Windows 11 24H2 ist betroffen – aber auf unterschiedlichen Maschinen mit unterschiedlicher Hardware.
– Nein, es sind nicht alle Windows 11 24H2 Clients Inhouse und bei Kunden betroffen, sondern irgendwo um die 10 Stück unter Kontrolle des Lesers.
Der Fehler beschäftigt Philipp auch schon einige Wochen – er hat einiges probiert. Ob die ein eigenes Image verwenden, weiß ich nicht. Da er aber hier mit liest, wird er vielleicht kommentieren, was er diesbezüglich schon probiert hat. Danke für den Hinweis.
Moin zusammen,
das Phänomen betrifft sowohl Neuinstallationen mit 24H2 (neuestes ISO von Microsoft, kein Custom-Image), als auch Installationen die von 23H2 aktualisiert wurden. Dabei ist es unerheblich, ob es sich um eine Installation auf Hardware handelt (Notebooks verschiedener Hersteller) oder um virtuelle Maschinen.
Die Maschinen bzw. VMs sind allesamt komplett gepatched, Mitglied einer klassischen Windows-Domäne. Es wird weder im Eventlog, noch in sonstigen Log-Files etwas vermerkt; kein Absturz, keine Exception, etc.
Lediglich der RemoteDesktopManager von Devolutions meldet ab und an einen Crash und die im vorherigen Kommentag veröffentlichten Error-Report. Habe diesen (nochmals) an den Hersteller geschickt; die letzten Anfragen in diese Richtung verliefen eher ins Leere.
Grüße
Gibt es denn bei euch auch funktionierende "Windows 11 24H2-Installationen" oder sind alle "Windows 11 24H2-Installationen" von diesem Fehler betroffen?
Kann die Gemeinsamkeit "Mitglied einer klassischen Windows-Domäne" als Ursache ausgeschlossen werden?
Werden die betroffenen Systeme von der Domäne falsch konfiguriert, durch irgend eine Gruppenrichtlinie oder durch defekte Profile, die die Clients vom Server runterladen?
Falls es auch funktionierende "Windows 11 24H2-Installationen" bei euch gibt, was ist der Unterschied in der Konfiguration?
Tritt der Fehler auch im Inselbetrieb ohne Domänenanbindung auf und auch mit einem neuen lokalen Profil mit Admin-Rechten?
Wurde ein Support-Ticket bei Microsoft eröffnet?
Kleines Update: inzwischen treten die Phänomene auch bei Kunden-Systemen auf – und zwar nach der Installation von LanCrypt (einer Software zur Verschlüsselung von Dateien und Ordner). Der Hersteller streitet alles ab, aber die "Beweise" sprechen leider gegen ihn… Ich halte euch auf dem Laufenden.