Windows-Befehlsprozessor funktioniert nicht mehr

[Bccc1]

[Erledigt] Windows-Befehlsprozessor funktioniert nicht mehr

Problem gelöst, siehe Post #7

Moin zusammen,

ich hab hier ein schräges Problem: Ich kriege zu verschiedenen Anlässen die Meldung "Windows-Befehlsprozessor funktioniert nicht mehr".


Die Meldung krieg ich seit längerem schon bei Systemstart mehrfach, aber ich war mit meiner Bachelorthesis zu sehr beschäftigt als das ich was am System ändern wollte. Jetzt bin ich durch und hab Zeit für den Mist. Nachdem ich Blustacks, Andy, ein paar Programme von Autodesk und Dropbox gelöscht habe, sind die Meldungen bei Systemstart weg gewesen. Da ich auf Dropbox nicht verzichten wollte, habe ich das jetzt wieder installiert und direkt nach Abschluss der Installation krieg ich wieder die Meldung.

Wie man hier im Screenshot sieht, ist der Auslöser der Aufruf von Dropbox mit den Parametern firstrun 1 und dem dbdata kram. Was aber die Ursache ist, verstehe ich nicht. Hat jemand ne Idee woran es liegen könnte oder zumindest wie ich rausfinden kann, was überhaupt die Ursache des Problems ist?
Um das nochmal klarzustellen, das Problem kann nicht ausschließlich bei Dropbox liegen, andere Programme, die ich jetzt gelöscht habe, machten auch solche Probleme. Ich kann zB auch nicht die Oculus Runtime installieren, da gibts auch solche Meldungen wenn er versucht den Service zu installieren.

Vielen Dank im Voraus

 

[cumulonimbus8]

Wie sehen denn die Eigenschaften von CMD aus (Win+R, CMD, Enter, Rechtsklick in Titelleiste - Eingenschaften)?

CN8

 

[Bccc1]

Keine Ahnung was du da rauslesen willst, aber bitte:

 

[cumulonimbus8]

Nicht viel

«Forum » vBulletin-Systemmitteilung

vBulletin-Systemmitteilung
Ungültige Angabe: Anhang
Wenn du einem normalen, gültigen Link im Forum gefolgt bist, wende dich bitte an den Webmaster.»

Da ist was schiefgelaufen. Meine Idee ist allerdings simpel: wenn die Einstellungen nicht meinen entsprechen könnten sie das Problem sein. Richtig glauben tue ich, zugegeben, an so was Einfaches auch nicht…

CN8

 

[Bccc1]

Jetzt ist das Bild hoffentlich verfügbar. Keine Ahnung was da schiefgelaufen ist.

 

[miac]

Verifiziere mal die Versionen der cmd.exe Dateien. 6.xxx erscheint mir falsch. Müßte 10.xxx sein.

Führe auch mal SFC /scannow aus.

 

[Bccc1]

Zu den CMD Versionen: Die von Dropbox ausgeführte Version ist ja laut ProcessExplorer 6.3.10240.16384. Sie liegt sie unter C:\Windows\SysWOW64\cmd.exe. Laut Eigenschaften ist die Version 10.0.10240.16384.

Wenn ich die cmd starte, kommt die Fehlermeldung.




Ich hab Scannow ausgeführt und entsprechend dem KB Eintrag Alle [SR] Einträge in eine Datei geschrieben:

C:\WINDOWS\system32>sfc /scannow

Systemsuche wird gestartet. Dieser Vorgang kann einige Zeit dauern.

Überprüfungsphase der Systemsuche wird gestartet.
Überprüfung 100 % abgeschlossen.

Vom Windows-Ressourcenschutz wurden beschädigte Dateien gefunden, und
einige davon konnten nicht repariert werden. Weitere Informationen finden Sie in der Datei "CBS.Log" unter "windir\Logs\CBS\CBS.log",
z.B. "C:\Windows\Logs\CBS\CBS.log".
Hinweis: Bei der Offlinewartung wird die Protokollierung derzeit nicht unterstützt.

C:\WINDOWS\system32>findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"

Die Dateien hab ich hochgeladen:
https://drive.google.com/file/d/0B62p4pb_l-FUR19PaC1IYmlrZGc/view?usp=sharing
https://drive.google.com/file/d/0B62p4pb_l-FUWk0xT3BrZUdSTEU/view?usp=sharing

Ich steig da nicht ganz durch, scheinbar sind bei mir Hauptsächlich eine menge Verknüpfungen kaputt? Abgesehen davon, dass ich da keinen Zusammenhang sehe, wie repariert man das?
Einige andere Sachen hat er ja gefunden und selber repariert. Die einzigen Einträge die ich gefunden habe, die nicht nur eine Veknüpfung zu sein scheinen und nicht automatisch repariert werden konnten, waren die hier:

2015-12-25 22:02:43, Info                  CSI    000045c0 [SR] Cannot repair member file [l:20{10}]"opencl.dll" of microsoft-windows-RemoteFX-clientVM-RemoteFXWDDMDriver-WOW64-C, Version = 10.0.10240.16384, pA Host= amd64 Guest= x86, nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35} in the store, hash mismatch
2015-12-25 22:02:44, Info                  CSI    000045c9 [SR] Cannot repair member file [l:20{10}]"opencl.dll" of microsoft-windows-RemoteFX-clientVM-RemoteFXWDDMDriver-WOW64-C, Version = 10.0.10240.16384, pA Host= amd64 Guest= x86, nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35} in the store, hash mismatch
2015-12-25 22:02:44, Info                  CSI    000045ca [SR] This component was referenced by [l:258{129}]"Microsoft-Windows-RemoteFX-VM-Setup-Package~31bf3856ad364e35~amd64~~10.0.10240.16384.RemoteFX clientVM and UMTS files and regkeys"
2015-12-25 22:02:44, Info                  CSI    000045cd [SR] Could not reproject corrupted file [ml:48{24},l:46{23}]"\??\C:\WINDOWS\SysWOW64"\[l:20{10}]"opencl.dll"; source file in store is also corrupted

2015-12-25 22:04:04, Info                  CSI    0000586b [SR] Cannot repair member file [l:20{10}]"opencl.dll" of microsoft-windows-RemoteFX-clientVM-RemoteFXWDDMDriver-WOW64-C, Version = 10.0.10240.16384, pA Host= amd64 Guest= x86, nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35} in the store, hash mismatch

2015-12-25 22:04:04, Info                  CSI    00005876 [SR] Cannot repair member file [l:20{10}]"opencl.dll" of microsoft-windows-RemoteFX-clientVM-RemoteFXWDDMDriver-WOW64-C, Version = 10.0.10240.16384, pA Host= amd64 Guest= x86, nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35} in the store, hash mismatch

2015-12-25 22:04:04, Info                  CSI    0000587a [SR] Could not reproject corrupted file [ml:48{24},l:46{23}]"\??\C:\WINDOWS\SysWOW64"\[l:20{10}]"opencl.dll"; source file in store is also corrupted

Ist das zwingend schlecht, dass die OpenCL.dll ein hash mismatch hat? Ich hatte mit OpenCL bisher keine Probleme, der Luxmark läuft auch durch.

Ergänzung (26. Dezember 2015)

Ohh man, ich Depp -.-

Ich habs gefunden. Ich hab irgendwann Ansicon installiert, ein Tool um Konsolenausgaben gefärbt auszugeben. Das war Schuld. Nach einem einfachen ansicon.exe -u im passenden Pfad <PathToAnsicon>\ansi160\x64\ war das Thema erledigt und alles läuft wieder. Und wieder mal ein Benutzerfehler, Windows ist unschuldig