E wrote:
> "E" <eddie180@xlxoxcxaxlxnxextx.com> wrote in message
> news:13tperfhou5v0b1@corp.supernews.com...
> > http://members.localnet.com/~eddie18...i031508-01.dmp
> >
>
>
> I downloaded a debuging utility from MS called WinDbg found here...
> http://www.microsoft.com/whdc/devtoo...g/default.mspx
>
> I loaded individualy all of the 13 minidump files from the
> /windows/minidump folder into WinDbg. I'm no pro at reading this type of
> information. I can only pick out what is obvious to me, but WinDbg seems to
> fault the Sound Blaster card, its driver, or an IRQ problem related to the
> Sound Blaster. Although there are no conflicts listed in system information.
>
> I have saved the output of WinDbg as text files and put them here...
> http://members.localnet.com/~eddie180/Debug/
> Files dated from 12-21-06 and back mention "emu10k1m.sys ".
>
> I started out with the latest dump file dated 03-15-08, the one I linked
> to in my original post, and its analysis was incomplete. WinDbg complained
> that...
>
> >"nt" was not found in the image list.
> >Debugger will attempt to load "nt" at given base 00000000
>
> ...and...
>
> >Unable to load image nt, Win32 error 0n2
> >Unable to add module at 00000000
> >Debugger can not determine kernel base address
>
> Eventually it came up with...
>
> >UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
>
> ...and...
>
> >Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
> >Arg2: f7abfd70
> >Arg3: 00000000
> >Arg4: 00000000
>
> Basicaly the same results from Paul's analysis, with nothing that would,
> to me, point to a specific driver or piece of hardware. Analysis of the
> second youngest dump file dated 05-07-07 gave several...
>
> >Your debugger is not using the correct symbols
>
> ...messages. The most note worthy thing that came out of 05-07-07 was...
>
> >BAD_POOL_CALLER (c2)
> >The current thread is making a bad pool request. Typically this is at a
> bad >IRQL level or double freeing the same allocation, etc.
> >Arguments:
> >Arg1: 00000007, Attempt to free pool which was already freed
> >Arg2: 00000cd4, (reserved)
> >Arg3: 00000028, Memory contents of the pool block
> >Arg4: 82158008, Address of the block of pool being deallocated
>
> As I worked backwards in time through the dump files, I got output
> similiar to the most recent one dated 03-15-08. With the "nt was not found
> in the image list" complaint. But with this exeption...
>
> >DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> >An attempt was made to access a pageable (or completely invalid) address
> >at an
> >interrupt request level (IRQL) that is too high. This is usually
> >caused by drivers using improper addresses.
> >If kernel debugger is available get stack backtrace.
> >Arguments:
> >Arg1: 00000000, memory referenced
> >Arg2: 00000002, IRQL
> >Arg3: 00000000, value 0 = read operation, 1 = write operation
> >Arg4: 815cc3df, address which referenced memory
>
> I then skipped to the very first, dated 09-21-04. The debug output of it
> was the most telling...
>
> >Probably caused by : emu10k1m.sys (
> emu10k1m!>CEFXParamSetNotifySink::Unadvise+e5 )
>
> ...and...
>
> >STACK_COMMAND: kb
>
> >FOLLOWUP_IP:
> >emu10k1m!CEFXParamSetNotifySink::Unadvise+e5
> >f7bee6fb 8d45e0 lea eax,[ebp-20h]
>
> >SYMBOL_STACK_INDEX: 4
>
> >SYMBOL_NAME: emu10k1m!CEFXParamSetNotifySink::Unadvise+e5
>
> >FOLLOWUP_NAME: MachineOwner
>
> >MODULE_NAME: emu10k1m
>
> >IMAGE_NAME: emu10k1m.sys
>
> >DEBUG_FLR_IMAGE_TIMESTAMP: 3b6b5fb2
>
> >FAILURE_BUCKET_ID: 0xD1_emu10k1m!>CEFXParamSetNotifySink::Unadvise+e5
>
> >BUCKET_ID: 0xD1_emu10k1m!CEFXParamSetNotifySink::Unadvise+e5
>
> >Followup: MachineOwner
>
> All the dump files dated 12-21-06 and before, gave output similiar to this
> saying...
>
> >Probably caused by : emu10k1m.sys ( emu10k1m+186fb )
>
> Eddie

It almost seems like two different problems, or like perhaps
a new driver was installed for the sound card, somewhere through
the period covered by the dumps.

You can try removing the sound card, and using the onboard sound
if available. You should be able to go to the support.asus.com
site, and find a driver for onboard sound for the P4P800 SE.

I'd try a test with Prime95, and see how long it will run error
free. I get bored after about four hours of that, so that is
probably enough error free testing, if you want to stop. If
you have a temperature measurement program like Speedfan, you can
watch the temperature while the test is running.

Sometimes, memory develops faulta, as time passes. I've had a
couple pieces of generic RAM bought on sale at local stores,
that lasted a little over a year. And then had a stuck fault
that memtest86+ could find. The replacement RAM from Crucial
has been fine to date.

You could also get a copy of CPUZ from www.cpuid.com/cpuz.php
and check that the clocks used and memory timing values, make
sense for the hardware. That would be a basic check that
something was not fouled up, along the way, in the BIOS.
And you don't want to "clear" the BIOS, without understanding
what the hardware is doing at this moment - studying the system
as it now stands, may help you understand the root cause of the
problems.

Paul