超頻後玩星海藍白當機

十方天

初級會員
已加入
10/19/10
訊息
25
互動分數
0
點數
0
年齡
44
今天超頻後玩星海就藍屏了
可是穩穩進入win 7系統
有高手能幫解釋一下下面錯誤大概是甚麼問題嗎?
我電壓是用1.28v進入系統
然後記憶體1:1 小超8*400 3.2g
玩星海就藍屏.上網看網頁就沒事
請高手大大指點一下迷津
cpu:e6750
主機板ga-ep35-ds3
ram:金士頓2g*2
顯示卡:微星577hawk(沒超頻)


程式錯誤檢查字串 :
程式錯誤檢查代碼 : 0x00000124
參數 1 : 0x00000000
參數 2 : 0x86a45024
參數 3 : 0xf2000000
參數 4 : 0x00000115
驅動程式所導致 : halmacpi.dll
位址所導致 : halmacpi.dll+ef3f
檔案描述 : Hardware Abstraction Layer DLL
產品名稱 : Microsoft® Windows® Operating System
公司 : Microsoft Corporation
檔案版本 : 6.1.7600.16385 (win7_rtm.090713-1255)
處理器 : 32-位元
電腦名稱 :
完整路徑 : C:\Windows\Minidump\110610-12168-01.dmp
處理器數 : 2
主要版本 : 15
次要版本 : 7600
 

max0535

榮譽會員
已加入
9/9/08
訊息
1,263
互動分數
0
點數
36
記憶體有超頻嗎?? 看那編號好像是記憶體!!
 

十方天

初級會員
已加入
10/19/10
訊息
25
互動分數
0
點數
0
年齡
44
報告.我是直接調成2
記憶體頻率:400 1:1
我的是ddr2 800
 

max0535

榮譽會員
已加入
9/9/08
訊息
1,263
互動分數
0
點數
36
2是2N?? 記憶體電壓可以試看看往上調一格 看還會不會藍頻
 

yucharles

進階會員
已加入
9/9/08
訊息
402
互動分數
0
點數
0
轉貼:

A stop 0x124 is fundamentally different from other types of bluescreens because the "we must crash now" trigger is the hardware, not software. The OS passes on the hardware error report as a "stop 0x124" because it can't do anything else once the hardware has signalled an uncorrectable error condition. It's theoretically possible for drivers to indirectly cause hardware to trigger MCEs by "driving" in ways that are confusing to the hardware, but from the point of view of a home user that disctinction is so subtle as to be irrelevant.

It's important to note that there are literally squillions of different possible causes for that hardware error report (it's called a "Machine Check Exception" - MCE), and one person's stop 0x124 is likely to be entirely different to another's. Hence, posts which begin with "I had that error too, and then I reconnected the mini-molex on my FDD to fix it..." are almost always misguided because they're random stabs in the dark which are statistically highly unlikely to help anyone else experiencing MCEs.

It's relatively simple (but painful) to interpret the hardware's error report. It's in the so-called MCi_Status register, the contents of which are actually visible as bugcheck parameters 3 and 4 in that photo of your screen, as well as each of your minidumps. Interpreting the numbers is just a matter of consulting information published by Intel and AMD. (I've done it below based on your first minidump. This is such a common request that I might code a little utility to automate the process.)

The trouble is that the hardware's complaints are never "practical", in the sense that they would tell you what's wrong in layman's terms and include a recommendation for how to fix it. Instead, it's esoteric stuff which only tends to make sense to hardware folks and driver developers. Hence, a basic "0x124 home user troubleshooting strategy" might look something like this:
0) If it's under warranty, take it back to the shop. The hardware is reporting errors and you don't want to run the risk of troubleshooting it yourself with an uncertain outcome - you just want a machine that doesn't report MCE errors. Otherwise...

1) If overclocking, don't. Hardware that is driven beyond its design specs - by overclocking - can malfunction in weird ways.

2) Open up the side of the case and point a mains fan into the guts of the PC to rule out most (lack of) cooling issues.

3) Update all hardware-related drivers: video, sound, RAID (if any), NIC... anything that interacts with a piece of hardware. This is a desparation step, but it's legit once you're faced with having to rip out and replace bits of the machine, plus it's generally good practice to run the latest drivers anyway.

4) From time to time the OS drivers themselves may be contributing to an MCE. The scenarios are very specific and very rare, but try applying the relevant updates anyway. For example:

http://support.microsoft.com/kb/956115

5) Clean and de-dust the inside of the machine. Reseat all connectors and memory modules. Use a can of compressed air to clean out the RAM DIMM connectors as much as possible.

6) If all else fails, start ripping out bits of hardware one-by-one until a culprit is found. Obviously, this is a lot easier if you've got equivalent hardware lying around to perform swaps.



=========================

The MCE info in the first of the minidumps you've posted suggests a bus parity error is being reported:

1011001000000000000000000001100000000110000000000000111000001111
3210987654321098765432109876543210987654321098765432109876543210
___6_________5_________4_________3_________2_________1

63: VAL - MCi_STATUS register valid
61: UC - Error uncorrected
60: EN - Error enabled
57: PCC - Processor context corrupt
36: component has received a parity error on the RS[2:0]# pins for a response transaction.
35: (Reserved)
27/26/25: Bus queue error type = "Response Parity Error" (011)

MCA [15:0]:
0000 1110 0000 1111
000F 1PPT RRRR IILL
F: "Normal" filtering (0)
PP: Generic (11)
T: Request did not time out (0)
RRRR: Generic Error (0000)
II: Other transaction (11)
LL: Memory hierarchy level "generic" (11)
 

十方天

初級會員
已加入
10/19/10
訊息
25
互動分數
0
點數
0
年齡
44
記憶體如你所說調加1格已經沒有發生錯誤
但是變成直接重開.我自已在猜是不是換成電壓不足的因素(1.28v)??
我這樣的猜測不知道對不對?
感謝你的回覆
 

十方天

初級會員
已加入
10/19/10
訊息
25
互動分數
0
點數
0
年齡
44
轉貼:

A stop 0x124 is fundamentally different from other types of bluescreens because the "we must crash now" trigger is the hardware, not software. The OS passes on the hardware error report as a "stop 0x124" because it can't do anything else once the hardware has signalled an uncorrectable error condition. It's theoretically possible for drivers to indirectly cause hardware to trigger MCEs by "driving" in ways that are confusing to the hardware, but from the point of view of a home user that disctinction is so subtle as to be irrelevant.

It's important to note that there are literally squillions of different possible causes for that hardware error report (it's called a "Machine Check Exception" - MCE), and one person's stop 0x124 is likely to be entirely different to another's. Hence, posts which begin with "I had that error too, and then I reconnected the mini-molex on my FDD to fix it..." are almost always misguided because they're random stabs in the dark which are statistically highly unlikely to help anyone else experiencing MCEs.

It's relatively simple (but painful) to interpret the hardware's error report. It's in the so-called MCi_Status register, the contents of which are actually visible as bugcheck parameters 3 and 4 in that photo of your screen, as well as each of your minidumps. Interpreting the numbers is just a matter of consulting information published by Intel and AMD. (I've done it below based on your first minidump. This is such a common request that I might code a little utility to automate the process.)

The trouble is that the hardware's complaints are never "practical", in the sense that they would tell you what's wrong in layman's terms and include a recommendation for how to fix it. Instead, it's esoteric stuff which only tends to make sense to hardware folks and driver developers. Hence, a basic "0x124 home user troubleshooting strategy" might look something like this:
0) If it's under warranty, take it back to the shop. The hardware is reporting errors and you don't want to run the risk of troubleshooting it yourself with an uncertain outcome - you just want a machine that doesn't report MCE errors. Otherwise...

1) If overclocking, don't. Hardware that is driven beyond its design specs - by overclocking - can malfunction in weird ways.

2) Open up the side of the case and point a mains fan into the guts of the PC to rule out most (lack of) cooling issues.

3) Update all hardware-related drivers: video, sound, RAID (if any), NIC... anything that interacts with a piece of hardware. This is a desparation step, but it's legit once you're faced with having to rip out and replace bits of the machine, plus it's generally good practice to run the latest drivers anyway.

4) From time to time the OS drivers themselves may be contributing to an MCE. The scenarios are very specific and very rare, but try applying the relevant updates anyway. For example:

http://support.microsoft.com/kb/956115

5) Clean and de-dust the inside of the machine. Reseat all connectors and memory modules. Use a can of compressed air to clean out the RAM DIMM connectors as much as possible.

6) If all else fails, start ripping out bits of hardware one-by-one until a culprit is found. Obviously, this is a lot easier if you've got equivalent hardware lying around to perform swaps.



=========================

The MCE info in the first of the minidumps you've posted suggests a bus parity error is being reported:

1011001000000000000000000001100000000110000000000000111000001111
3210987654321098765432109876543210987654321098765432109876543210
___6_________5_________4_________3_________2_________1

63: VAL - MCi_STATUS register valid
61: UC - Error uncorrected
60: EN - Error enabled
57: PCC - Processor context corrupt
36: component has received a parity error on the RS[2:0]# pins for a response transaction.
35: (Reserved)
27/26/25: Bus queue error type = "Response Parity Error" (011)

MCA [15:0]:
0000 1110 0000 1111
000F 1PPT RRRR IILL
F: "Normal" filtering (0)
PP: Generic (11)
T: Request did not time out (0)
RRRR: Generic Error (0000)
II: Other transaction (11)
LL: Memory hierarchy level "generic" (11)

謝謝大大回復...可是我有點看不懂..連結進去不懂..??
 

Blank

榮譽會員
已加入
11/13/03
訊息
3,608
互動分數
0
點數
36
年齡
44
cpu電壓不夠
 

十方天

初級會員
已加入
10/19/10
訊息
25
互動分數
0
點數
0
年齡
44
cpu電壓不夠

請問大大是回我這篇嗎:

記憶體如你所說調加1格已經沒有發生錯誤
但是變成直接重開.我自已在猜是不是換成電壓不足的因素(1.28v)??
我這樣的猜測不知道對不對?
感謝你的回覆
 

Blank

榮譽會員
已加入
11/13/03
訊息
3,608
互動分數
0
點數
36
年齡
44
0x00000124我測的都99%都是cpu要加壓, 所以

既然你說記憶體都加壓過了, 最後也只剩cpu啦.
 
▌延伸閱讀