Random BSODS after upgrade (hal.dll+12a3b)(0x124)

romulow22

New member
Joined
Jul 3, 2015
Posts
3
Location
Brazil
Hi! i'm from Brazil, so my english is a bit rustic! =P

Last month i upgraded some parts of my desktop (psu, ram, vga) and my nightmare began...

Here are some information about my pc:

Windows 7 Professional SP1 x64 retail

Age of system: Mobo/cpu about 3 years and psu/ram/vga brand new

CPU: AMD Phenom II X6 1090T (Stock Clock)
Mobo: Asus M4A89GTD PRO/USB3 (with last bios)
HD1: Kingston Hyperx 120gb
HD2: Hitachi 512gb 2.5"
HD3: Seagate 1TB 3.5"

Old Vga: Ati Sapphire HD4830 512MB GDDR3
New Vga: Gigabyte Radeon R9 270 OC WindForce

Old ram: 2x2Gb Kingston 1333mhz
New ram: 1x8Gb Markvision 1333mhz

Old psu: Corsair cx400w
New psu: Corsair cx500w

With the old configs, my pc worked all fine for the last 3 years..
When i upgraded it, random bsod's started to happen.
As i had some spare parts i've been testing it for the last month, but i didn't find what's going on.
I know that is hardware failure and the last 2 options are cpu and mobo, because i've tested it with the old vga,ram,psu
and the bsod's didn't stop.

When i did the SysnativeBSODCollectionApp i had this configs:

Same cpu and mobo.
vga: onboard hd4290 that my mobo has
Hd1: Samsung HD502IJ
Ram: 1x8Gb Markvision 1333mhz
psu: Corsair cx500w


I had 4 bsod's in half a hour with this config using a formated harddrive.

Anyone can help me reading this dumps? Thank you!

View attachment SysnativeFileCollectionApp.zip
View attachment report.rar
 
I hate to be the bearer of bad news, but this is likely a hardware problem.

There's a few bug checks actually, so I may as well just go through them.

Code:
1: kd> .bugcheck
Bugcheck code 000000D1
Arguments fffff800`12886720 00000000`00000002 00000000`00000008 fffff800`12886720

Code:
1: kd> knL
 # Child-SP          RetAddr           Call Site
00 fffff880`049ea118 fffff800`02cd0169 nt!KeBugCheckEx
01 fffff880`049ea120 fffff800`02ccede0 nt!KiBugCheckDispatch+0x69
02 fffff880`049ea260 fffff800`12886720 nt!KiPageFault+0x260
03 fffff880`049ea3f0 fffffa80`098d09f0 0xfffff800`12886720
04 fffff880`049ea3f8 fffffa80`098d09f0 0xfffffa80`098d09f0
05 fffff880`049ea400 fffffa80`00000000 0xfffffa80`098d09f0
06 fffff880`049ea408 fffff800`00000001 0xfffffa80`00000000
07 fffff880`049ea410 00000000`00000000 0xfffff800`00000001

We're hitting a pagefault coming straight from user-mode code which is interesting.

Code:
1: kd> .trap fffff880`049ea260
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=00000000000003f0
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80012886720 rsp=fffff880049ea3f0 rbp=0000000000000000
 r8=fffff80002c5b000  r9=0000000000000000 r10=0000000000000001
r11=fffffa80066ea3c2 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
fffff800`12886720 ??              ???

Looking at the trapframe for the exception that occurred on frame #02, we can see it's a pretty bogus instruction - i.e. a misaligned instruction pointer.

Code:
Verify Flags Level 0x0000092b

  STANDARD FLAGS:
    [X] (0x00000000) Automatic Checks
    [X] (0x00000001) Special pool
    [X] (0x00000002) Force IRQL checking
    [X] (0x00000008) Pool tracking
    [ ] (0x00000010) I/O verification
    [X] (0x00000020) Deadlock detection
    [ ] (0x00000080) DMA checking
    [X] (0x00000100) Security checks
    [X] (0x00000800) Miscellaneous checks

Verifier was enabled too, so that's just additional proof that the MIP was caused most likely by hardware than a driver being terrible.

Code:
4: kd> .bugcheck
Bugcheck code 0000001A
Arguments 00000000`00041287 00000000`000000e1 00000000`00000000 00000000`00000000

So we again had a pagefault occur, just this time the bug check is different as the situation in which the exception (pagefault) occurred was different, which was holding working set synchronization.

Code:
4: kd> dt nt!_MMPFN 00000000000000e1
   +0x000 u1               : <unnamed-tag>
   +0x008 u2               : <unnamed-tag>
   +0x010 PteAddress       : ???? 
   +0x010 VolatilePteAddress : ???? 
   +0x010 Lock             : ??
   +0x010 PteLong          : ??
   +0x018 u3               : <unnamed-tag>
   +0x01c UsedPageTableEntries : ??
   +0x01e VaType           : ??
   +0x01f ViewCount        : ??
   +0x020 OriginalPte      : _MMPTE
   +0x020 AweReferenceCount : ??
   +0x028 u4               : <unnamed-tag>
Memory read error 0000000000000101

Code:
TRAP_FRAME:  fffff880043daa00 -- (.trap 0xfffff880043daa00)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000000000e1 rbx=0000000000000000 rcx=fffff6fb7dbedf88
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002c95a62 rsp=fffff880043dab90 rbp=fffffa8008757010
 r8=fffff6fb7e280028  r9=0000000000000008 r10=fffff6fb7dbf1400
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po cy
nt!MmProbeAndLockPages+0x3e2:
fffff800`02c95a62 6c              ins     byte ptr [rdi],dx ds:00000000`00000000=??
Resetting default scope

Once again, misaligned IP.

Code:
1: kd> .bugcheck
Bugcheck code 00000124
Arguments 00000000`00000000 fffffa80`07a97028 00000000`b4002000 00000000`c0000135

Code:
===============================================================================
Section 2     : x86/x64 MCA
-------------------------------------------------------------------------------
Descriptor    @ fffffa8007a97138
Section       @ fffffa8007a972c0
Offset        : 664
Length        : 264
Flags         : 0x00000000
Severity      : Fatal

Error         : DCACHEL1_DRD_ERR (Proc 1 Bank 0)
  Status      : 0xb4002000c0000135
  Address     : 0x000000001a273830
  Misc.       : 0x0000000000000000

L1 cache data read error, processor #1 and bank 0. There's consistency as well with the 2nd 0x124 crash dump:

Code:
===============================================================================
Section 2     : x86/x64 MCA
-------------------------------------------------------------------------------
Descriptor    @ fffffa8008563148
Section       @ fffffa80085632d0
Offset        : 664
Length        : 264
Flags         : 0x00000000
Severity      : Fatal

Error         : DCACHEL1_DRD_ERR (Proc 1 Bank 0)
  Status      : 0xf611c000fe000135
  Address     : 0x000000016c176a70
  Misc.       : 0x0000000000000000

Notice change in address, yet processor and bank remain the same #'s.

So, overall, pretty safe bet on a bad CPU or bad RAM. I'd check RAM first with 8 rounds of memtest passes.


Memtest86+:

Download Memtest86+ here:

Memtest86+ - Advanced Memory Diagnostic Tool

Which should I download?

You can either download the pre-compiled .ISO that you would burn to a CD and then boot from the CD, or you can download the auto-installer for the USB key. What this will do is format your USB drive, make it a bootable device, and then install the necessary files. Both do the same job, it's just up to you which you choose, or which you have available (whether it's CD or USB).

Do note that some older generation motherboards do not support USB-based booting, therefore your only option is CD (or Floppy if you really wanted to).

How Memtest works (you don't need to read, it's only for those interested in the specifics):

Memtest uses algorithms (specifically two), namely moving inversion & what is deemed Modulo-X. Essentially, the first algorithm fills the memory with a pattern. Starting at the low address, it checks to see if the pattern was changed (it should not have been), writes the patterns complement, increments the address, and repeats. Starting at the highest address (as opposed to the lowest), it follows the same checklist.

The reason for the second algorithm is due to a few limitations, with the first being that not all adjacent cells are being tested for interaction due to modern chips being 4 to 16 bits wide regarding data storage. With that said, patterns are used to go ahead and ensure that all adjacent cells have at least been written with all possible one and zero combinations.

The second is that caching, buffering and out of order execution will interfere with the moving inversions algorithm. However, the second algorithm used is not affected by this. For starting offsets of 0-20, the algorithm will write every 20th location with a pattern, write all other locations with the patterns complement, repeat the previous one (or more) times, and then check every 20th location for the previously mentioned pattern.

Now that you know how Memtest actually works, it's important to know that the tests it goes through all mean something different. It goes from Test 0 through Test 12, many of which use either one or the other algorithm discussed above, among many other things.

Any other questions, they can most likely be answered by reading this great guide here:

FAQ : please read before posting
 
Thank you for your help Patrick... i had my ram checked with memtest 3-4 days ago and it was Ok but i'll do it again just to double check it!
I thought it was my mobo that was dying, never passed through my head that was the cpu!
I think it's safer to get a new combo (mobo/cpu) instead getting another phenom cpu, because the only option i have here it's getting an used cpu and i don't trust it.
I will post the ram test results when it finishes
 
Yeah, Phenom processors are quite old now (2007).
An upgrade will be a good idea.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top