Hierbei handelt es sich um Fehler, die sich ggf. über mehrere Versionen von Windows ziehen und bei Microsoft nicht als "Fehler" deklariert sind, und daher vorerst nicht per Update beseitigt werden. 

Die Fehlermeldungen beziehen sich vorwiegend auf die aktuelle Windows 10 Version (21H2) und Windows 11
Eine Fehlerliste bei der MS per Update nachbessern muss, findet man unter: https://docs.microsoft.com/de-de/windows/release-information/status-windows-10-21H2



Seit Windows 10 (und auch in Windows 11) kommt es vor, dass bei jedem Login immer leere Temp-Ordner (mit "tw-" beginnend) angelegt werden (z.B. tw-20e5-3c1c-206d5f.tmp). So können schon mal ein paar tausend Ordner zusammen kommen. Die Namen variieren immer mit jedem neuen Login am Tag. 

Zu finden sind die Ordner unter:

C:\Windows\System32\config\systemprofile\AppData\Local


Der Auslöser für diese Ordner ist anscheinend eine Aufgabe in der Aufgabenplanung unter 

Microsoft » Windows » Management » Provisioning 

Dort findet man die Aufgabe "Logon" und genau die erstellt immer diese dubiosen tw-Ordner.
Oft wird empfohlen, diese Aufgabe zu deaktivieren, auswirkungen (außer das keine neuen Temp-Ordner angelgt werden) sind nicht bekannt.
Wer sich nicht traut, die Aufgabe zu deaktivieren, kann die Ordner ggf. manuell löschen, falls sie überhand nehmen, oder mit einem Script im selben Ordner, diese automatisch löschen.

bat




In den ersten Ausgaben der Windows 10 2004 hat Microsoft wohl vergessen die Log Protokollierung zu Deaktivierung.
Dieser Fehler ist seither in allen Windows 10 Versionen (und in Windows 11) vorhanden.

Die Log-Datei ist nur von Interesse, wenn man mit dem Debugger ein Live Kernel Debugging durchführt (seit Windows 8).
Und daher Im Normalbetrieb uninteressant und sollte normal nicht vorhanden sein bzw. als Systemdatei versteckt.

Falls diese Datei unter C:\ stört (wenn Systemdateien eingeblendet), kann diese in der Registry deaktiviert werden.

RegEdit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Dabei muss der Wert "EnableLogFile" auf 0 gesetzt werden.
Danach kann die Datei 'DumpStack-log.tmp' unter C:\ gelöscht werden



Diese Fehlermeldung in der Ereignisanzeige ESENT Ereignis-ID 455 taucht schon seit vielen Windows Versionen auf und sagt aus, dass Windows nichts in die EDB.log protokollieren kann.
Der Fehler ist "kosmetischer" Natur und behindert die Leistung von Windows in keinster Weise. Wer nicht in die Ereignisanzeige schaut, sollte es gar nicht mitbekommen.

Dieser kann ganz schnell behoben werden:

  • Datei Explorer öffnen und zu  C:\ WINDOWS \ system32 \ config \ systemprofile \ AppData \ Local  navigieren.
  • Hier nun einen neuen Ordner TileDataLayer anlegen und öffnen
  • Hier nun einen neuen Ordner Database anlegen.

Wer neugierig ist, kann den Ordner beobachten und ein paar Minuten warten.
Die EDB.log und weitere Protokolldateien können nun automatisch angelegt werden und die Ereignisanzeige bleibt von einer Fehlermeldung verschont.




Leider kommt es gerade bei der .Net Framework 3.5 Installation unter Windows immer wieder zu Fehlermeldung (meist mit dem Fehlercode 0x80072EFE).

Der genaue Fehlertext vom Error 0x80072EFE lautet:

Die angeforderten Änderungen konnten nicht abgeschlossen werden.
Die Änderungen konnten nicht abgeschlossen werden. Starten Sie den Computer neu, und wiederholen Sie den Vorgang.
Fehlercode: 0x80072EFE


In der Regel bringt der Neustart keine Besserung und es kommt immer wieder zum Fehler 0x80072EFE.

Eine Lösung ist der DISM-Befehl, über die Eingabeaufforderung.
Dafür muss eine ISO-Installationsdatei der installierten Windows 10/11 Version eingebunden werden.
In dem Beispiel wurde die Windows ISO-Datei auf Laufwerk E: gemountet
(seit Windows 8 genügt es die ISO-Datei per Doppelklick als Laufwerk einzubinden).

Danach muss über ein Eingabeaufforderung (als Administrator) folgenden Befehl absetzen:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:e:\sources\sxs

Bitte beachten, dass am Ende bei  /Source:e:\sources\sxs  der zugewiesene Laufwerksbuchstabe (in dem Beispiel e:), der eingebundenen ISO-Datei angepasst werden muss.
Anschließend führt DISM die Installation des fehlenden .Net Framework Features aus.

Gegebenenfalls muss am Ende der Installation Windows neu gestartet werden, damit die Installation abgeschlossen werden kann.




Damit Programme und Anwendungen unter Windows laufen können, müssen häufig bestimmte Dateien vorhanden sein.
Doch manchmal ist es der Fall, dass Anwendungen und meist Spiele die mit älteren Visual C++ Studio erstellt wurden (bzw. aus dem Windows XP / Windows 7 Zeitalter stammen), wegen fehlenden dynamische Programmbibliotheken in Windows, nicht funktionieren.

Diese Windows-Bibliotheken (Dynamic Link Library) sind dabei Grundvoraussetzung und enthalten zahlreiche Informationen, Programmcodes und Ressourcen, auf die eine EXE-Datei beim Programmstart zurückgreifen muss.

Im Normalfall bringen die entsprechenden Anwendungen die erforderlichen "Runtime Redistributable Package" zur Installation mit oder installieren diese automatisch.
Vor allem bei älteren Spielen kommt es jedoch vor, dass diese Windows-Bibliotheken fehlen und ggf. manuell nachinstalliert werden müssen.

Dafür stellt Microsoft sogenannte "Visual C++ Runtime Redistributable Package" zu Verfügung (https://support.microsoft.com/de-de/help/2977003/the-latest-supported-visual-c-downloads), in denen die dynamischen Programmbibliotheken hinterlegt sind.

  • Visual Studio C++ 2005 Version 8.0      (msvcm80.dll, msvcp80.dll, msvcr80.dll u.v.m.)
  • Visual Studio C++ 2008 Version 9.0      (msvcm90.dll, msvcp90.dll, msvcr90.dll u.v.m.)
  • Visual Studio C++ 2010 Version 10.0    (msvcm100.dll, msvcp100.dll, msvcr100.dll u.v.m.)
  • Visual Studio C++ 2012 Version 11.0    (msvcm110.dll, msvcp110.dll, msvcr110.dll u.v.m.)
  • Visual Studio C++ 2013 Version 12.0    (msvcm120.dll, msvcp120.dll, msvcr120.dll u.v.m.)
  • Visual Studio C++ 2015, 2017, 2019 und 2022 (msvcm140.dll, msvcp140.dll, msvcr140.dll u.v.m.)

Hinweis Visual C++ 2015, 2017, 2019 und 2022 haben die gleichen weitervertreibbaren Dateien.

Bis Visual Studio 2013 enthielt jedes Hauptrelease der C++-Compiler und -Tools eine neue, eigenständige Version der Microsoft C-Laufzeitbibliothek (CRT). Diese eigenständigen Versionen der CRT waren unabhängig voneinander und teilweise nicht miteinander kompatibel.
Ab Visual Studio 2015 und höhere Versionen von Visual Studio, verwenden diese eine universelle CRT.

Bereitstellung unter Microsoft Windows XP / Vista

Visual Studio 2015 bis 2019 unterstützen die Entwicklung von Software für Microsoft Windows XP mit SP3 weiterhin.
Um diese Entwicklung zu unterstützen, kann eine Version der Universal CRT verwendet werden. Das Betriebssystem Microsoft Windows XP wird nicht mehr grundlegend oder erweitert unterstützt, deshalb unterscheidet die zentrale Bereitstellung der universellen CRT sich von der unter anderen Betriebssystemen.

Die letzte Version von C++ Redistributable für Visual Studio 2015-2019, die unter Windows XP funktioniert, wurde in Visual Studio 2019 Version 16.7 ausgeliefert.



Durch die Kernisolierung kann es vorkommen, dass Windows einen Treiber nicht mehr in den Speicher laden kann. Es kommt daraufhin zu einer Fehlermeldung in der Art 'Ein Treiber kann auf diesem Gerät nicht geladen werden.'

Diese Meldung erscheint, weil in den Windows-Sicherheitseinstellungen die Option Speicher-Integrität das Laden eines Treibers auf dem Gerät verhindert. Ursache für die Blockade ist, dass der Treiber sich nicht an die Vorgaben Microsofts hält und versucht, direkt auf den isolierten Kernel zu zugreifen. Das wird aber durch den Schutzmechanismus 'Kernisolierung' verhindert. In Folge dessen wird der Treiber nicht geladen und es kommt durch den fehlenden Treiber ggf. zu Fehlfunktionen im Windows (Meist davon betroffen, ältere Grafiktreiber).

Microsoft schlägt im KB-Beitrag einige Optionen vor, die man ausprobieren kann, um diesen Treiber doch noch zu verwenden:

  • Schauen, ob ein aktualisierter und kompatibler Treiber über Windows Update oder vom Treiberhersteller verfügbar ist. Das ist die bevorzugte Lösung.
  • Wenn das nicht funktioniert, kann man versuchen, die Speicherintegritätseinstellung in der Windows-Sicherheit zu deaktivieren.

Für die letztgenannte Option muss im Defender 'Gerätesicherheit' die Option (Kernisolierung) Speicher-Integrität ausgeschalten werden.
Nach einem Windows Neustart, sollte damit der Treiber wieder geladen werden.

Ein Bug verhindert das Abschalten

In Windows kommt es hin und wieder zu einem Bug, der eine einmal aktivierte (Kernisolierung) HVCI-Funktion (Hypervisor-protected code integrity) sich über den Defender nicht mehr abschalten lässt. In diesem Fall schafft nur ein Eingriff in die Registry Abhilfe:

RegEdit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity

Dort ist der DWORD-Wert Enabled auf 0 zu setzen und Windows danach neu zu starten.




  • Keine Stichwörter