Question : BSOD - caused by hardware, RAM passed Memtest - any clues in dump analysis?

Previously asked about BSOD on this same machine, see:
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/XP/Q_23041191.html

Previous Question:
"Bought a new system with Vista, put in new hard drives (Raid 1) and ghosted my XP system over which had been stable for years. Repaired installaion of XP and loaded recommended drivers. System now reboots or hangs spontaneously. Dump file appears to point to audio driver. Can someone review my debuglog and help me resolve this? Thanks, a great community here."

Machine continues to BSOD, although less frequently. Minidump analysis follows. I suspect this is a bad motherboard or CPU, as the RAM passes multiple cycles of Memcheck. Anyone got a better idea?
Code Snippet: 
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:
117:
118:
119:
120:
121:
122:
123:
124:
125:
126:
127:
128:
129:
130:
131:
132:
133:
134:
135:
136:
137:
138:
139:
140:
141:
142:
143:
144:
145:
146:
147:
148:
149:
150:
151:
152:
153:
154:
155:
156:
157:
158:
159:
160:
161:
162:
163:
164:
165:
166:
167:
168:
169:
170:
171:
172:
173:
174:
175:
176:
177:
178:
179:
180:
181:
182:
183:
184:
185:
186:
187:
188:
189:
190:
191:
192:
193:
194:
195:
196:
197:
198:
199:

Loading Dump File [C:\WINDOWS\Minidump\Mini012308-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
 
Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt
Built by: 2600.xpsp_sp2_rtm.040803-2158
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Wed Jan 23 21:42:28.134 2008 (GMT-8)
System Uptime: 0 days 21:55:53.496
Loading Kernel Symbols
...................................................................................................................................................................
Loading User Symbols
Loading unloaded module list
.........................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
 
Use !analyze -v to get detailed debugging information.
 
BugCheck 1000007F, {8, bab50d70, 0, 0}
 
 
 
Probably caused by : hardware ( nt!MiCheckPdeForPagedPool+2e )
 
Followup: MachineOwner
---------
 
1: kd> !analyze -v 
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
 
UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: bab50d70
Arg3: 00000000
Arg4: 00000000
 
Debugging Details:
------------------
 
 
 
 
BUGCHECK_STR:  0x7f_8
 
CUSTOMER_CRASH_COUNT:  1
 
DEFAULT_BUCKET_ID:  DRIVER_FAULT
 
TRAP_FRAME:  ad875204 -- (.trap 0xffffffffad875204)
ErrCode = 00000002
eax=0000bb40 ebx=ad875394 ecx=204d3b52 edx=00000001 esi=ad875340 edi=20263458
eip=804fe12b esp=ad875278 ebp=ad875324 iopl=0         nv up ei ng nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010286
nt!KeContextToKframes+0x489:
804fe12b 0064a124        add     byte ptr [ecx+24h],ah      ds:0023:204d3b76=??
Resetting default scope
 
EXCEPTION_RECORD:  ad8751b0 -- (.exr 0xffffffffad8751b0)
ExceptionAddress: 804fe12b (nt!KeContextToKframes+0x00000489)
   ExceptionCode: 10000004
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 204d3b76
 
MISALIGNED_IP: 
nt!KeContextToKframes+489
804fe12b 0064a124        add     byte ptr [ecx+24h],ah
 
LAST_CONTROL_TRANSFER:  from 8051edd9 to 80513118
 
STACK_TEXT:  
ad875008 8051edd9 ad874ea8 ad8751b0 ad875194 nt!MiCheckPdeForPagedPool+0x2e
ad87505c 80543568 00000001 ad874ea8 00000000 nt!MmAccessFault+0x309
ad87505c 804fe170 00000001 ad874ea8 00000000 nt!KiTrap0E+0xd0
ad875194 80541075 ad8751b0 00000000 ad875204 nt!KiDispatchException+0x1a
ad8751fc 80541026 ad875324 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad875204 804fe12b badb0d00 00000001 73d5a937 nt!KiExceptionExit+0x18a
ad875324 80541075 ad875340 00000000 ad875394 nt!KeContextToKframes+0x489
ad87538c 80541026 ad8754b4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad875394 804fe12b badb0d00 00000001 45196870 nt!KiExceptionExit+0x18a
ad8754b4 80541075 ad8754d0 00000000 ad875524 nt!KeContextToKframes+0x489
ad87551c 80541026 ad875644 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad875524 804fe12b badb0d00 00000001 410a7301 nt!KiExceptionExit+0x18a
ad875644 80541075 ad875660 00000000 ad8756b4 nt!KeContextToKframes+0x489
ad8756ac 80541026 ad8757d4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad8756b4 804fe12b badb0d00 00000001 2b2b2b00 nt!KiExceptionExit+0x18a
ad8757d4 80541075 ad8757f0 00000000 ad875844 nt!KeContextToKframes+0x489
ad87583c 80541026 ad875964 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad875844 804fe12b badb0d00 00000001 01504f01 nt!KiExceptionExit+0x18a
ad875964 80541075 ad875980 00000000 ad8759d4 nt!KeContextToKframes+0x489
ad8759cc 80541026 ad875af4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad8759d4 804fe12b badb0d00 00000001 2f290037 nt!KiExceptionExit+0x18a
ad875af4 80541075 ad875b10 00000000 ad875b64 nt!KeContextToKframes+0x489
ad875b5c 80541026 ad875c84 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad875b64 804fe12b badb0d00 00000001 050003cb nt!KiExceptionExit+0x18a
ad875c84 80541075 ad875ca0 00000000 ad875cf4 nt!KeContextToKframes+0x489
ad875cec 80541026 ad875e14 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad875cf4 804fe12b badb0d00 00000001 07061401 nt!KiExceptionExit+0x18a
ad875e14 80541075 ad875e30 00000000 ad875e84 nt!KeContextToKframes+0x489
ad875e7c 80541026 ad875fa4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad875e84 804fe12b badb0d00 00000001 33645a0f nt!KiExceptionExit+0x18a
ad875fa4 80541075 ad875fc0 00000000 ad876014 nt!KeContextToKframes+0x489
ad87600c 80541026 ad876134 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad876014 804fe12b badb0d00 00000001 00200020 nt!KiExceptionExit+0x18a
ad876134 80541075 ad876150 00000000 ad8761a4 nt!KeContextToKframes+0x489
ad87619c 80541026 ad8762c4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad8761a4 804fe12b badb0d00 00000001 ff6672c7 nt!KiExceptionExit+0x18a
ad8762c4 80541075 ad8762e0 00000000 ad876334 nt!KeContextToKframes+0x489
ad87632c 80541026 ad876454 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad876334 804fe12b badb0d00 00000001 d8600f04 nt!KiExceptionExit+0x18a
ad876454 80541075 ad876470 00000000 ad8764c4 nt!KeContextToKframes+0x489
ad8764bc 80541026 ad8765e4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad8764c4 804fe12b badb0d00 00000001 085e4c6e nt!KiExceptionExit+0x18a
ad8765e4 80541075 ad876600 00000000 ad876654 nt!KeContextToKframes+0x489
ad87664c 80541026 ad876774 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad876654 804fe12b badb0d00 00000001 00000008 nt!KiExceptionExit+0x18a
ad876774 80541075 ad876790 00000000 ad8767e4 nt!KeContextToKframes+0x489
ad8767dc 80541026 ad876904 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad8767e4 804fe12b badb0d00 00000001 48e9ffff nt!KiExceptionExit+0x18a
ad876904 80541075 ad876920 00000000 ad876974 nt!KeContextToKframes+0x489
ad87696c 80541026 ad876a94 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad876974 804fe12b badb0d00 00000001 fffabb95 nt!KiExceptionExit+0x18a
ad876a94 80541075 ad876ab0 00000000 ad876b04 nt!KeContextToKframes+0x489
ad876afc 80541026 ad876c24 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad876b04 804fe12b badb0d00 00000001 8b000000 nt!KiExceptionExit+0x18a
ad876c24 80541075 ad876c40 00000000 ad876c94 nt!KeContextToKframes+0x489
ad876c8c 80541026 ad876db4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad876c94 804fe12b badb0d00 00000001 00000001 nt!KiExceptionExit+0x18a
ad876db4 80541075 ad876dd0 00000000 ad876e24 nt!KeContextToKframes+0x489
ad876e1c 80541026 ad876f44 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad876e24 804fe12b badb0d00 00000001 6f0f6600 nt!KiExceptionExit+0x18a
ad876f44 80541075 ad876f60 00000000 ad876fb4 nt!KeContextToKframes+0x489
ad876fac 80541026 ad8770d4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad876fb4 804fe12b badb0d00 00000001 5b5e5fb5 nt!KiExceptionExit+0x18a
ad8770d4 80541075 ad8770f0 00000000 ad877144 nt!KeContextToKframes+0x489
ad87713c 80541026 ad877264 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad877144 804fe12b badb0d00 00000001 0016c48e nt!KiExceptionExit+0x18a
ad877264 80541075 ad877280 00000000 ad8772d4 nt!KeContextToKframes+0x489
ad8772cc 80541026 ad8773f4 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad8772d4 804fe12b badb0d00 00000001 fbfd0ff3 nt!KiExceptionExit+0x18a
ad8773f4 80541075 ad877410 00000000 ad877464 nt!KeContextToKframes+0x489
ad87745c 80541026 ad877584 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad877464 804fe12b badb0d00 00000001 33154d25 nt!KiExceptionExit+0x18a
ad877584 80541075 ad8775a0 00000000 ad8775f4 nt!KeContextToKframes+0x489
ad8775ec 80541026 ad877714 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad8775f4 804fe12b badb0d00 00000001 000020e0 nt!KiExceptionExit+0x18a
 
 
STACK_COMMAND:  kb
 
FOLLOWUP_IP: 
nt!MiCheckPdeForPagedPool+2e
80513118 56              push    esi
 
SYMBOL_STACK_INDEX:  0
 
SYMBOL_NAME:  nt!MiCheckPdeForPagedPool+2e
 
FOLLOWUP_NAME:  MachineOwner
 
DEBUG_FLR_IMAGE_TIMESTAMP:  0
 
IMAGE_NAME:  hardware
 
MODULE_NAME: hardware
 
FAILURE_BUCKET_ID:  IP_MISALIGNED
 
BUCKET_ID:  IP_MISALIGNED
 
Followup: MachineOwner
---------
Open in New Window Select All

Answer : BSOD - caused by hardware, RAM passed Memtest - any clues in dump analysis?

From the stack trace, I find the following repeating pattern. Windows recovery routine encounter recursive abend caused the stack overflow and finally windows is crashed with double fault.  The reason why windows recovery crashes because of the faulty ram.  

ad87745c 80541026 ad877584 804fe12b badb0d00 nt!CommonDispatchException+0x4d
ad877464 804fe12b badb0d00 00000001 33154d25 nt!KiExceptionExit+0x18a
ad877584 80541075 ad8775a0 00000000 ad8775f4 nt!KeContextToKframes+0x489
ad8775ec 80541026 ad877714 804fe12b badb0d00 nt!CommonDispatchException+0x4d

Some faulty ram can pass memtest. Reseat the ram to another memory slot may resolve the problem.
Random Solutions  
 
programming4us programming4us