[honx]

ich hab immer mal wieder folgende meldung in der ereignisanzeige (hab mal die aktuellste reinkopiert):

Volume "system (C:)" wurde aufgrund eines Fehlers nicht defragmentiert: Es wurde versucht, eine Datei mit einem falschen Format zu laden. (0x8007000B)

oder vollständig:

Spoiler:(zum lesen bitte Text markieren)

Protokollname: Application
Quelle: Microsoft-Windows-Defrag
Datum: 02.08.2021 06:52:00
Ereignis-ID: 257
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Volume "system (C:)" wurde aufgrund eines Fehlers nicht defragmentiert: Es wurde versucht, eine Datei mit einem falschen Format zu laden. (0x8007000B)
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Defrag" />
<EventID Qualifiers="32768">257</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2021-08-02T04:52:00.000000000Z" />
<EventRecordID>141940</EventRecordID>
<Channel>Application</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>system (C:)</Data>
<Data>Es wurde versucht, eine Datei mit einem falschen Format zu laden. (0x8007000B)</Data>
<Binary>0000000041050000F404000000000000629468641336AAB85B55B1B5B038000000000000 </Binary>
</EventData>
</Event>

was genau kann das sein, woran kann das liegen?
google nutzt mir in dem fall leider überhaupt nichts brauchbares, mit dem ich irgendwas anfangen könnte. :(

laut ereignisanzeige tritt dieser fehler recht unregelmässig auf:
der erste eintrag stammt vom 29.06.2017 00:30:34, danach am 02.07. und am 28.09.; im jahr 2017 insgesamt dreimal.
10 einträge im jahr 2018: 13.01, 06.03., 10.04., 20.04., 09.05., 06.06., 03.08., 04.09., 14.09., 15.10. (abstände variieren zwischen 10 tagen und 5 wochen)
5 einträge 2019: 28.02., 07.03., 03.07., 20.08., 22.09.
4 einträge 2020: 12.01., 22.03., 17.04., 16.11.,
und 2021 bereits 3 einträge: 05.01., 21.07. und 02.08.

an der festplatte kann es nicht mehr liegen, denn im märz dieses jahres hab ich beide festplatten tauschen und das system auf neue platten spiegeln lassen, da mich nach einem alter von 10 jahren die panik packte, dass doch mal etwas mit festplatten passieren könnte, welche über ein jahrzehnt alt und in betrieb waren... mit anderen worten, festplatten sind nagelneu.

[honx]

wo könnte ich danach fragen? kennt jemand brauchbare pc-foren, wo man sowas beantwortet bekommt?

schon wieder ein forum wo ich mich werde registrieren müssen, aber geht wohl scheinbar nicht anders...

[jabu]

Wenn Google schon nichts Brauchbares liefert, dann wird es wohl nicht die eine bestimmte Ursache geben.

Allgemein soll der Fehlercode 0x8007000B darauf hinweisen, dass eine ausführbare Datei (incl. DLLs) nicht geladen werden konnte, da sie in einem falschen Format vorgelegen hat. Das passiert typischerweise bei beschädigten Dateien oder bei einem 32/64-Bit Mismatch. Es muss, wie meistens, neben direkten Ursachen auch mit indirekten Ursachen gerechnet werden.

Es könnte z.B.

• ein Antivirus (oder irgendein anderer Kernelmodustreiber) dazwischengegrätscht haben,
• das Dateisystem beschädigt sein,
• eine Systemdatei fehlen, beschädigt sein oder in einer falschen Version vorliegen,
• . . .

Hast du denn schon die Standardmaßnahmen versucht?

Zuerst wäre ein ggf. installiertes Antivirus vollständig zu deinstallieren.
Auch alle (anderen) Kernelmodustreiber, die nicht von Windows selbst stammen und keine direkten Hardwaretreiber sind, wären vollständig zu deinstallieren.

Danach:
Was ist denn z.B. bei den Standardbordwerkzeugen CHKDSK, DISM und SFC (in der Reihenfolge und, wo nötig, mit den passenden Parametern) herausgekommen?

Eine alte und immer noch empfehlenswerte Anleitung von foobar dazu (in der technischen Hilfe zu Risen):
[HOWTO] Arbeitsspeicher und Dateisystem auf Fehler überprüfen

Hinweis zu DISM: Falls du ein Betriebssystem vor Windows 8 benutzt, geht das nicht einfach online. Das Tool bräuchte in dem Fall ein Installations-Image, passend zur Version (Service-Pack- oder Build-Version) von deinem Windows. Weil das chronisch veraltet ist, sind nach einer Reparatur mit DISM Windowsupdates durchführen zu lassen. Evtl. ist, damit die funktionieren, vorher ein Neustart nötig.

Ich tippe zwar nicht auf defekten RAM als direkte Ursache, aber defekter RAM könnte etwas Fehlerhaftes schreiben lassen haben, sodass die dadurch verursachten Fehler nach dessen Entfernen repariert werden müssten.

Falls das HDD mal gewechselt und die Daten dazu bitgenau bzw. sektorweise vom alten auf das neue gespiegelt worden ist, sind die alten Macken (z.B. im Dateisystem oder in den Dateien selbst) natürlich noch erhalten. In dem Fall wären die oben erwähnten Maßnahmen damals erforderlich gewesen, bzw. sind sie in dem Fall jetzt umso angebrachter.

Falls der Fehler nicht bei jedem Defragmentieren auftritt, sondern nur hin und wieder, so könnte man ihn, falls die Maßnahmen nichts bringen, evtl. ignorieren.

wo könnte ich danach fragen? kennt jemand brauchbare pc-foren, wo man sowas beantwortet bekommt?

schon wieder ein forum wo ich mich werde registrieren müssen, aber geht wohl scheinbar nicht anders...

Man recherchiert zu deinem Fehlercode und schreibt sich einen Ast ab, ohne zu wissen, was du selber weißt bzw. schon probiert hast.

Wir wissen nicht mal sicher, welches Windows du verwendest (Fragen z.B.: Immer noch dein altes 7? Ist das aktuell gehalten? usw.) und welche Software so auf deiner Kiste tobt.

Du könntest z.B. mal msinfo32 aufrufen und den Inhalt speichern (als *.NFO), zippen und hier verlinken, damit wir etwas mehr über die Umgebung wissen, unter der das passiert. Dass es hilft, kann ich nicht versprechen, es hilft natürlich wenigstens gegen einen Teil des Nebels, in dem wir stochern.

Edit:
Ich weiß nicht, ob es hilft, ist nur so eine naive Idee, von wegen evtl. falschen Cachings:
Du könntest mal den gesamten Inhalt (also ggf. inkl. versteckten Dateien und Systemdateien) des Prefetch-Ordners von Windows löschen und gleich danach einen Neustart einlegen lassen.

[honx]

soweit ich das beurteilen kann, tritt das nicht regelmässig auf. oftmals vergehen auch mehrere monate dazwischen. manchmal jedoch nur 10 tage, siehe chronologische auflistung. und am 21.07. (als mir das das erste mal aufgefallen ist, während ich nach einem anderen fehler gesucht hab) hab ich danach eine defragmetierung per gui durchlaufen lassen, dauerte ziemlich lang, lief jedoch ohne fehler. soweit ich weiss, wurde dabei zuerst das dateisystem gechecked, bevor mit der defragmentierung begonnen wurde. kann mich allerdings nicht daran erinnern, etwas von einem fehler gelesen zu haben. laut defragmentierung (gui) sind alle vier partitionen zu 0% fragmentiert.
als antivirus-lösung verwende ich microsoft security essentials, kein dritthersteller involviert. betriebssystem ist nach wie vor windows 7 am aktuellsten stand (so aktuell es nach eos eben geht), allerdings war es im juni 2017 definitiv am aktuellsten stand, als der fehler zum ersten mal auftrat (laut ereignisanzeige). vielleicht war der update-stand mai 2017 (ein monat vorher), hab mich bzgl. update-installation damals bereits nach dem ms defcon level von askwoody.com gerichtet, kann daher heute nicht mehr sagen ob am 29.06.2017 bereits grünes licht für damalige juni-patches gegeben wurde.
wegen dism oder sfc muss ich mal sehen, ob ich mich da ran wage (von letzterem höre/lese ich heute zum ersten mal).
gestern nacht um 03:20 uhr trat der fehler übrigens wieder auf, diesmal lagen erstmals nur 3 tage dazwischen.
btw. wie bzw. wo kann ich von dir angesprochene prefetch-dateien löschen? mach ich das in der datenträgerbereinigung?
hab mal eine .nfo-datei angehängt, ist entpackt >2mb gross:
umgebung.7z

//edit: nachdem ich das .nfo hochgeladen hab, hab jedenfalls das system mal neugestartet, lief bereits wieder seit 15.07. ununterbrochen.
ich hatte bereits gespeicherte savestates von winuae in verdacht, da ich am selben tag wieder solche gespeichert hab, als erstmalig nach mehreren monaten besagter fehler wieder auftrat (21.07.) doch das kommt zeitlich nicht hin, denn einen savestate hab ich erst stunden später gespeichert, nachdem jener fehler in der ereignisanzeige auftauchte. das wars also nicht, was das getriggert hat.
geradeeben lasse ich jedenfalls mal die datenträgerbereinigung laufen. diese "berechnung" dauert auch immer ewig...

//edit: nach dem esten neustart ist heute erstmalig ein ganz neuer fehler in der ereignisanzeige aufgetaucht:

Protokollname: System
Quelle: Microsoft-Windows-DistributedCOM
Datum: 06.08.2021 19:54:02
Ereignis-ID: 10010
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Der Server "{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
<EventID Qualifiers="49152">10010</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2021-08-06T17:54:02.000000000Z" />
<EventRecordID>595849</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data Name="param1">{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}</Data>
</EventData>
</Event>

nach einem zweiten neustart erschien diese neue meldung nicht mehr.


und dann gibts mit jedem neustart eine von microsoft security essentials verursachte meldung in der ereignisanzeige, jene ist normal. besagter fehler erscheint seit ich 2019 microsoft security essentials als ersatz der bis dahin genutzten panda endpoint protection installiert hab, etwa einen monat danach gings mit den meldungen in der ereignisanzeige los. der vollständigkeit halber kopiere ich eine solche meldung auch mal mit rein.

Spoiler:(zum lesen bitte Text markieren)

Protokollname: Microsoft-Windows-Kernel-EventTracing/Admin
Quelle: Microsoft-Windows-Kernel-EventTracing
Datum: 06.08.2021 20:32:55
Ereignis-ID: 3
Aufgabenkategorie:Sitzung
Ebene: Fehler
Schlüsselwörter:Sitzung
Benutzer: SYSTEM
Computer: GameWorkstation
Beschreibung:
Die Sitzung "Microsoft Security Client OOBE" wurde aufgrund des folgenden Fehlers beendet: 0xC000000D.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Kernel-EventTracing" Guid="{B675EC37-BDB6-4648-BC92-F3FDC74D3CA2}" />
<EventID>3</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>2</Task>
<Opcode>14</Opcode>
<Keywords>0x8000000000000010</Keywords>
<TimeCreated SystemTime="2021-08-06T18:32:55.744246700Z" />
<EventRecordID>412</EventRecordID>
<Correlation />
<Execution ProcessID="4" ThreadID="176" />
<Channel>Microsoft-Windows-Kernel-EventTracing/Admin</Channel>
<Computer>GameWorkstation</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="SessionName">Microsoft Security Client OOBE</Data>
<Data Name="FileName">C:\ProgramData\Microsoft\Microsoft Security Client\Support\EppOobe.etl</Data>
<Data Name="ErrorCode">3221225485</Data>
<Data Name="LoggingMode">5</Data>
</EventData>
</Event>

einzige "lösung" welche ich für jenes "problem" gefunden hab, besagte man solle mse deinstallieren und neu installieren. das hab ich 2020 tatächlich mal versucht, doch wie man sieht hat es nichts gebracht, besagte meldung erscheint immer noch bei jedem neustart.

//edit (07.08.):
hab heute mal wieder die defragmentierung per gui manuell angestossen, da mir das keine ruhe gelassen hat. lief vollständig und erfolgreich durch. ohne fehler im eventviewer. da steht als abschluss nur:

"Defragmentierung" wurde von der Defragmentierung auf system (C:) abgeschlossen.

[jabu]

soweit ich das beurteilen kann, tritt das nicht regelmässig auf. oftmals vergehen auch mehrere monate dazwischen. manchmal jedoch nur 10 tage, siehe chronologische auflistung.
[...] gestern nacht um 03:20 uhr trat der fehler übrigens wieder auf, diesmal lagen erstmals nur 3 tage dazwischen.

Vielleicht könnte man es trotzdem ignorieren, solange keine ernsten Probleme auftauchen, ist wohl eine Ermessenssache, ob sich der Aufwand für dich lohnt. Die *.nfo-Datei gucke ich mir mal, wenn ich die nötige Ruhe dafür finde, näher an. Bisher habe ich die Infos grob durchgeguckt.

wegen dism oder sfc muss ich mal sehen, ob ich mich da ran wage (von letzterem höre/lese ich heute zum ersten mal).

Der System File Checker ist das Programm zum Überprüfen der Systemdateien.

Eigentlich sollte man, wenn möglich, per DISM vorher die Katalogdateien prüfen und nötigenfalls reparieren lassen, weil SFC sonst u.U. von verfälschten oder unvollständigen Informationen (in Katalogdateien) ausgehen könnte. Aber unter Windows 7 ist DISM auf ein Installations-Image angewiesen, wobei man kaum ein aktuelles Image haben wird (was nach der Reparatur Updates erfordert). Ferner ist das Tool unter Windows 7 noch nicht ganz vollständig. Man müsste also sehen, was trotzdem schon geht. Das war eher als ein Hinweis zur Vollständigkeit gedacht, falls alle Register probiert werden sollen. Vermutlich ist das in deinem Fall nicht unbedingt angebracht.

SFC kannst du trotzdem verwenden, aber es bezieht sich dann eben auf Informationen, bei denen du darauf angewiesen bist, dass sie noch stimmen. Ohne etwas Mut zur Lücke geht es also nicht. Normalerweise geschieht für einen automatischen Reparaturdurchlauf der Aufruf mit dem Parameter /SCANNOW. Man könnte stattdessen vorsichtshalber erst mal mit /VERIFYONLY die Integrität der Systemdateien lediglich testen lassen, um bei Funden selber zu entscheiden, wie verfahren werden soll. Das ist die sicherere Variante, z.B. zum Vorbeugen eines Kaputtreparierens wegen falscher Informationen.

CHKDSK ist vor den anderen Tools anzuwenden und sowieso zum gelegentlichen Gebrauch zu empfehlen. Ich würde mich nicht auf automatische Dateisystemüberprüfungen verlassen, da diese unter laufendem Windows vielleicht nicht gründlich genug sein könnten. Ich glaube z.B. kaum, dass sich die Berechtigungseinträge so schnell überprüfen lassen. Wenn du CHKDSK auf das Systemlaufwerk anwendest, dann wirst du normalerweise gefragt, ob du das beim nächsten Start von Windows ausführen lassen willst (um Zugriffe auf die Partition zu unterbinden). Das geht dann nicht ganz so schnell.

wie bzw. wo kann ich von dir angesprochene prefetch-dateien löschen?

Eingabeaufforderung mit Administratorberechtigungen starten, dort eingeben und jeweils mit Enter bestätigen (vor allem beim DEL-Befehl nicht vertippen, und falls dein Systemlaufwerk nicht C heißt, müsste das angepasst werden):

sc stop SysMain
del /s /f /q C:\Windows\Prefetch\*.*
sc start SysMain

Falls nach der ersten Zeile gemeldet wird, dass der Dienst sowieso nicht läuft (sinngemäß), dann lässt du die dritte Zeile aus. Falls der Dienst ordnungsgemäß beendet wurde, gibst du sie (zum Starten) ein. Anschließend ist ein umgehender Neustart zwar nicht nötig, aber u.U. empfehlenswert.

geradeeben lasse ich jedenfalls mal die datenträgerbereinigung laufen. diese "berechnung" dauert auch immer ewig...

Auch bei ziemlich frischem Windows habe ich schon lange warten müssen. Allerdings kann sich die Wartezeit durch Fehler (z.B. irgendwelche Zugriffsprobleme) noch teils drastisch verlängern. Das unzumutbar lange Warten kann schon von Kleinigkeiten ausgelöst werden. Es ist leider normal, wenn in dieser Phase das Herunterfahren blockiert ist.

//edit: nach dem esten neustart ist heute erstmalig ein ganz neuer fehler in der ereignisanzeige aufgetaucht:

nach einem zweiten neustart erschien diese neue meldung nicht mehr.

Solche DCOM-Zeitüberschreitungsfehler sind teilweise normal. Dieser scheint etwas mit dem Thumbnail-Cache zu tun zu haben und könnte noch mit der zuvor erfolgten Datenträgerbereinigung zusammenhängen, falls angewiesen wurde, diesen Cache zu leeren.

und dann gibts mit jedem neustart eine von microsoft security essentials verursachte meldung in der ereignisanzeige, jene ist normal. besagter fehler erscheint seit ich 2019 microsoft security essentials als ersatz der bis dahin genutzten panda endpoint protection installiert hab, etwa einen monat danach gings mit den meldungen in der ereignisanzeige los. der vollständigkeit halber kopiere ich eine solche meldung auch mal mit rein.

Ja, ignorieren, würde ich sagen. Gut, man könnte testweise die *.etl-Datei löschen (weiß man vorher nicht, ob es was bringt) oder dieses Logging des Kernels einfach deaktivieren (habe ich damals oft mit diversen Loggings unter Vista und 7 gemacht, damit das System etwas flinker reagiert, indem es u.a. weniger auf dem HDD herumrödelt). Es ist aber grundsätzlich damit zu rechnen, dass Windows es irgendwann wieder aktiviert.

hab heute mal wieder die defragmentierung per gui manuell angestossen, da mir das keine ruhe gelassen hat. lief vollständig und erfolgreich durch. ohne fehler im eventviewer.

Erfreulich.

[honx]

kann das sein, dass besagter fehler dann auftritt, wenn das system zu defragmentieren versucht, während virtualbox mit einer linux-vm läuft? bei den letzten beiden malen (im august und zuletzt gestern), als der fehler in der ereignisanzeige auftauchte, lief zu dem zeitpunkt definitiv virtualbox mit einer linux mint vm darin. und wenn ich ich all diese zeiten so durchgehe, als besagter fehler im log sichtbar ist, könnte es durchaus sein, dass zu dem zeitpunkt ebenfalls linux virtualisiert wurde. dazu könnte in etwa auch der zeitpunkt passen, als das zum ersten mal auftrat (juni 2017). in etwa zu jener zeit hab ich angefangen, sehr aktiv mit linux zu arbeiten und auch meine browser-aktivitäten hauptsächlich nach linux zu verlagern. d.h. ab dem zeitpunkt war virtualbox stets mehrere stunden bis teilweise sogar tage am stück am laufen. vor 2017 lief eine virtualisierung immer nur maximal eine stunde oder so, da war ich auch browsertechnisch noch in windows selbst unterwegs. es könnte also durchaus sein, dass eine vom system geplante defragmentierung ab juni 2017 auf einen zeitpunkt fiel, zu dem gerade zufällig eine linux-vm aktiv war.
nun stellt sich folglich die frage: ist es möglich zu verhindern, dass ein defragmentierungsdienst gestartet wird, während eine gewisse anwendung wie z.b. virtualbox aktiv ist? so ne art blacklist oder sowas? denn wenn sich mein verdacht bestätigen sollte, dann dürfte im umkehrschluss besagter fehler niemals wieder auftreten, wenn defrag nur noch ausserhalb der virtualbox-zeiten laufen würde. sollte jener fehler danach immer noch auftreten, dann läge ich mit meiner annahme falsch und müsste an anderer stelle weitersuchen. damit könnte ich zumindest das auschliessen.