1

My computer freezes randomly from time to time and will not respond again until I completely power off the system. I am running Windows 8.1 x64 (dual booted with Linux if that's important). Below is the resulting of running sfc /scannow and findstr /i /c:"[SR]" "%windir%\Logs\CBS\CBS.log" | findstr /i /v /c:"verify" (this was suggested on this post). I have tried DISM.exe, SFCFix.exe, and the steps listed here. None of these have been able to fix the corrupt files, although all report back that the problem has been successfully resolved. The exception is the post I referenced above, which did not even create the fixes.txt file created in step 5 of Manual repair. I have run chkdsk and I did not notice any errors, so I do not believe the problem is caused by the hard drive. I am getting a little tired of this computer freezing and losing work, any suggestions would be appreciated.

2015-06-26 09:04:21, Info                  CSI    000004b0 [SR] Cannot repair member file [l:24{12}]"utc.app.json" of Microsoft-Windows-Unified-Telemetry-Client, Version = 6.3.9600.17842, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2015-06-26 09:04:21, Info                  CSI    000004b2 [SR] Cannot repair member file [l:66{33}]"telemetry.ASM-WindowsDefault.json" of Microsoft-Windows-Unified-Telemetry-Client, Version = 6.3.9600.17842, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2015-06-26 09:04:23, Info                  CSI    000004b4 [SR] Cannot repair member file [l:24{12}]"utc.app.json" of Microsoft-Windows-Unified-Telemetry-Client, Version = 6.3.9600.17842, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2015-06-26 09:04:23, Info                  CSI    000004b5 [SR] This component was referenced by [l:154{77}]"Package_1_for_KB3068708~31bf3856ad364e35~amd64~~6.3.1.0.3068708-1_neutral_GDR"
2015-06-26 09:04:23, Info                  CSI    000004b7 [SR] Cannot repair member file [l:66{33}]"telemetry.ASM-WindowsDefault.json" of Microsoft-Windows-Unified-Telemetry-Client, Version = 6.3.9600.17842, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2015-06-26 09:04:23, Info                  CSI    000004b8 [SR] This component was referenced by [l:154{77}]"Package_1_for_KB3068708~31bf3856ad364e35~amd64~~6.3.1.0.3068708-1_neutral_GDR"
2015-06-26 09:09:17, Info                  CSI    000008de [SR] Repairing 1 components
2015-06-26 09:09:17, Info                  CSI    000008e1 [SR] Cannot repair member file [l:24{12}]"utc.app.json" of Microsoft-Windows-Unified-Telemetry-Client, Version = 6.3.9600.17842, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2015-06-26 09:09:17, Info                  CSI    000008e3 [SR] Cannot repair member file [l:66{33}]"telemetry.ASM-WindowsDefault.json" of Microsoft-Windows-Unified-Telemetry-Client, Version = 6.3.9600.17842, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2015-06-26 09:09:17, Info                  CSI    000008e5 [SR] Cannot repair member file [l:24{12}]"utc.app.json" of Microsoft-Windows-Unified-Telemetry-Client, Version = 6.3.9600.17842, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2015-06-26 09:09:17, Info                  CSI    000008e6 [SR] This component was referenced by [l:154{77}]"Package_1_for_KB3068708~31bf3856ad364e35~amd64~~6.3.1.0.3068708-1_neutral_GDR"
2015-06-26 09:09:17, Info                  CSI    000008e8 [SR] Cannot repair member file [l:66{33}]"telemetry.ASM-WindowsDefault.json" of Microsoft-Windows-Unified-Telemetry-Client, Version = 6.3.9600.17842, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2015-06-26 09:09:17, Info                  CSI    000008e9 [SR] This component was referenced by [l:154{77}]"Package_1_for_KB3068708~31bf3856ad364e35~amd64~~6.3.1.0.3068708-1_neutral_GDR"
2015-06-26 09:09:17, Info                  CSI    000008eb [SR] Repair complete
2015-06-26 09:09:17, Info                  CSI    000008ec [SR] Committing transaction
c1moore
  • 143
  • 4
  • DISM is suppose to determine if your WinSxS folder is corrupt, while SFC will actually fix your system files by using the contents of the WinSxS, these errors indicate you do infact have system file corruption ( obviously ). Have you tryed downloading a Windows 8.1 and using its WinSxS folder to repair the WinSxS on your drive. In my experience a healthy drive, one in which should not be replaced, does not generate these types of errors. – Ramhound Jun 26 '15 at 14:10
  • I thought that was basically what the post of linked to was trying to accomplish. I do have an installation disk though. Should I just copy and paste all the files in the Sources\sxs folder to the WinSxS folder? These folders seem similar, but do not have all the same files/folders. – c1moore Jun 26 '15 at 14:27
  • Just copy and paste, no, do what I suggested. You have to manually indicate to both SFC and DISM you want ot use another source directory. Look up the syntax if you don't know it. – Ramhound Jun 26 '15 at 14:59
  • I'm sorry, that was not clear to me. The problem appears to persist even after doing this. I executed `DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:E:\Sources\sxs /LimitAccess` which displayed the message `The restore operation completed successfully. The component store corruption was repaired.`, but `sfc /scannow` found corrupt files it was unable to fix. The same files appear to be corrupt. – c1moore Jun 26 '15 at 16:04

1 Answers1

0

This is a expected output. Microsoft wrote this in the following KB article:

Update for customer experience and diagnostic telemetry
https://support.microsoft.com/en-us/kb/3068708

This update contains the following two manifests that are occasionally updated by the Diagnostic Tracking Service:

telemetry.ASM-WindowsDefault.json
utc.app.json 

The two files are marked as static files in the update. When an advanced user runs the System File Checker Tool (sfc.exe), the files are unintentionally flagged as corrupted. There is no impact or actual corruption on a device that is running this update, and this issue will be fixed in a later service update.

So ignore the issue until Microsoft fixed it with a new update.

magicandre1981
  • 97,301
  • 30
  • 179
  • 245
  • Then what would be causing the system to randomly freeze? – c1moore Jun 26 '15 at 17:07
  • something else. Press the CAPS LOCK key during the freeze and look if the light on the keyboard toggles or not. – magicandre1981 Jun 27 '15 at 06:29
  • I have before, nothing happens. All lights (and sounds) that were on when the computer freezes stay on until powered off. – c1moore Jun 27 '15 at 14:27
  • in this case you have a hardware issue. Test RAM with memtest86+ and CPU with Prime95. – magicandre1981 Jun 27 '15 at 17:50
  • Unfortunately, memtest86+ is not supported on UEFI systems (mentioned [here](http://askubuntu.com/questions/258991/where-is-the-memtest-option-on-the-12-04-64-bit-live-cd)). I did run the memory tester installed with Windows (described [here](http://windows.microsoft.com/en-us/windows7/diagnosing-memory-problems-on-your-computer)) using the extended option, which did not detect any errors. Should I try memtest86, which does work with UEFI? Prime95 has been running for 14+ hrs now and has not detected any issues. I also ran chkdsk and verified the hd using Linux, but neither found problems. – c1moore Jun 29 '15 at 11:51