[SOLVED] Error(s) found: Code 80070246 Windows Update ran into a problem.

Code:
SFCFix version 2.4.3.0 by niemiro.
Start time: 2015-02-18 08:32:39.804
Microsoft Windows 8.1 Update 1 - amd64
Using .txt script file at E:\Desktop\SFCFixScript.txt [0]


BitShift::
No corruptions detected.
BitShift:: directive completed successfully.


Successfully processed all directives.
SFCFix version 2.4.3.0 by niemiro has completed.
Currently storing 3 datablocks.
Finish time: 2015-02-18 08:32:59.982
Script hash: hBI6Mql4H4Bclpn1EppfVE6OvuMnGbPTS9YilWvhfmA=
----------------------EOF-----------------------
 
Currently at 2+2 passed tests and counting. Dropped my gopro camera on the keyboard and aborted runs, so had to start over :D
So far so good.. taking some time. 5 hours total and counting. Update: Make that 2+3 passed runs now.

2015-02-18 22.38.13.jpg
 
Last edited:
Please follow the instructions for MemTest86+, for atleast 10 passes. Let me know the results.

I will have to do this after your bedtime, so see you tomorrow :D Currently at work, and there is only so much you can do from remote desktop ;-)

I dont have a bed time.....I just got to be when my fiance makes me :1grin:

Currently at 2+2 passed tests and counting. Dropped my gopro camera on the keyboard and aborted runs, so had to start over :D
So far so good.. taking some time. 5 hours total and counting. Update: Make that 2+3 passed runs now.

View attachment 10910


Hopefully shouldn't be to much longer, but this can take a while.
 
I see people in the memtest86+ thread reporting problems with test #7, amd I started seeing errors from test #7 aswell. Don't know if it's because of the bugs they are reporting or if it is real errors? It was something about mulithreading. I ran it in forced mulithread mode. Will start it again in standard single core mode and see how it goes. I guess a single core test is taking a lot longer vs 8 cores..
2015-02-19 10.15.17.jpg
 
Update from single core run coming in 12 hours, when I get out of bed tomorrow morning.
5 passed runs so far, no errors. 9 hours running.
 
I always take errors detected by memtest seriously, but I will contact someone who knows a lot more about hardware than I do.
 
Last edited:
I always take errors detected by memtest seriously, but I will contact someone who knows a lot more about hardware than I do.
What you are seeing is expected with multi threading mode. The multi threaded tests in memtest are buggy and have problems with test 7.

See my post here: https://www.sysnative.com/forums/hardware-tutorials/3909-test-ram-with-memtest86.html#post65593

I tested my RAM using Memtest86+ last night and this was my first time using version 5.01. There is one thing I would like to note about this release.

It seems there is a bug with v5.01 with regards to the newly introduced Multi-Core (SMT) testing. This is a feature designed to dramatically speed up test times by using all the cores of the CPU. Normally, memtest86+ only uses a single core, which makes it quite slow. By using the many cores available in modern processors it can cut this time.

To enable this SMT mode, press the F2 key within a few seconds of booting into Memtest. If you do not press this, Memtest will resort to 'Fail-Safe' mode, where it will work the same as it always has.

However, this new feature has an issue. It seems to crash whilst performing Test #7. Whilst this doesn't affect all systems, users are reporting it to affect quite a few. There are a few posts on the memtest forum:

5.01 freezes -
fleapickle said:
CPU: Intel Ivybridge 3570k 3.4Ghz
RAM: Mushkin 996995 8GB
Motherboard: Z77A-G43

Firstly am I supposed to force SMT? Memtest86+ seems to think my PC is single core otherwise.

Secondly, after choosing SMT, the test freezes less than two minutes in. The few blinking symbols on-screen keep blinking, but the timer freezes, and the program doesn't respond to keypresses...

In case this is important: I installed MT86+ to USB from my Windows 8.1 computer using the installer.

norwoods said:
I have 2 servers: Intel Xeon E3-1220 V2, SuperMicro X9SCI-LN4F, SuperTalent 2x8GB DDR3-1600 ECC and Intel Xeon E3-1220 V3, SuperMicro X10SLM-LN4F, SuperTalent 4x8GB DDR3-1600 ECC. When I press F2 to get SMP mode the systems freeze in Test 7 about 20% to 25% through the test doing a Block Move of 4096M-6144M. Things seem fine with SMP Disabled.
norwoods said:
When I press F3 to get SMP mode the Intel Xeon E3-1220 V2 gets past Test 7 but the Intel Xeon E3-1220 V3 does not.

Inky said:
CPU: i5 750 @ 2.88 GHz
RAM: G. Skill Sniper 9-9-9-28 @ 1805 MHz, 1.45V
Mobo: Asus P7P55D EVO

With SMT disabled, it passes all the tests.
With SMT enabled, the tests proceed at warp speed and freeze at Step 7, just like norwoods above.

If I use 5.00 RC1, SMT works fine.

And so on and so forth...

Memtest86+ is freezing while running test #7
memtest86+ 5.01 shutdown w forced multithread around start of test 7

False positives given whilst running in SMT - v5.01 gives errors in multi thread mode, but not in default mode

So I recommend NOT using SMP mode until a fix is made. Just let Memtest run as normal.

Stephen
 
Thanks Stephen!

So we now have these errors:
Code:
2015-02-17 08:38:48, Info                  CSI    000003cc@2015/2/17:07:38:48.112 PopulateComponentFamiliesKey - Begin
2015-02-17 08:38:48, Error                 CSI    000003cd@2015/2/17:07:38:48.934 (F) base\lstring\lblob.cpp(2219): Error STATUS_ILLEGAL_CHARACTER originated in function RtlTranscodeLBlobs expression: __rv.UcsCharacter != (0xffffffff)

Looking at your hive, there are 2 folders inside HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\VersionedIndex 6.3.9600.17031 (winblue_gdr.140221-1952) and 6.3.9600.17129 (winblue_gdr.140516-1506). There is only supposed to be one folder in here.

I will get back to you soon.
 
Last edited:
It turns out this is actually normal on very outdated Windows 8 machine. On Windows Vista and windows 7 there was only ever one, but then Windows 8 appeared and there were multiple versions of VersionIndexed keys. But as Windows 8 updated over time the duplicates were removed.

The issue is we have a bit flip key somewhere in the registry, unfortunately SFC /SCANNOW or DISM is not telling us where. The developer of SFCFix is actually running you hive through a beta version of the tool to try and find this bit shift.
 
It turns out this is actually normal on very outdated Windows 8 machine. On Windows Vista and windows 7 there was only ever one, but then Windows 8 appeared and there were multiple versions of VersionIndexed keys. But as Windows 8 updated over time the duplicates were removed.

The issue is we have a bit flip key somewhere in the registry, unfortunately SFC /SCANNOW or DISM is not telling us where. The developer of SFCFix is actually running you hive through a beta version of the tool to try and find this bit shift.

Crossing fingers for the beta version!
 
Back
Top