Blue screen - Can someone read a minidump *.dmp file?

http://members.localnet.com/~eddie1...ni031508-01.dmp

I built a computer for a relative that has an occasional blue screen and
memory dump. I changed out the video card and RAM about a year ago. She
still had an occasional blue screen. I then changed out the power
supply. The PC worked fine for a few months, until yesterday morning it
blue screened again. It seems that it can blue screen at any time, no
matter what task is being performed. She tolerated it until the last two
recent episodes, when after it blue screened, the system would not boot.
Just a black screen and no POST. When I brought it home, and hooked it
up to my monitor, keyboard etc... it came on with no problem. I've never
had it long enough to duplicate the blue screen.

Here is a list of components:
ASUS P4P800SE 865PE/ICH5 motherboard.
Nvidia video card
1024MB of name brand memory listed as compatible with the board
Antec 500W Basiq PSU

Also it has in it PCI cards from her previous Dell computer such as...
A Lucent chip set soft modem
Sound Blaster 5.1
three port firewire card

I can lose these PCI cards from the old Dell, since she is on DSL, the
Asus board has onboard sound, and who needs firewire.

Here is a link to the minidump file created by the latest blue screen...
http://members.localnet.com/~eddie1...ni031508-01.dmp

I may try on my own to read the minidump by following the directions
given here... http://support.microsoft.com/kb/315263

Thanks in advance
Eddie

E wrote:
> http://members.localnet.com/~eddie1...ni031508-01.dmp
>
> I built a computer for a relative that has an occasional blue screen and
> memory dump. I changed out the video card and RAM about a year ago. She
> still had an occasional blue screen. I then changed out the power
> supply. The PC worked fine for a few months, until yesterday morning it
> blue screened again. It seems that it can blue screen at any time, no
> matter what task is being performed. She tolerated it until the last two
> recent episodes, when after it blue screened, the system would not boot.
> Just a black screen and no POST. When I brought it home, and hooked it
> up to my monitor, keyboard etc... it came on with no problem. I've never
> had it long enough to duplicate the blue screen.
>
> Here is a list of components:
> ASUS P4P800SE 865PE/ICH5 motherboard.
> Nvidia video card
> 1024MB of name brand memory listed as compatible with the board
> Antec 500W Basiq PSU
>
> Also it has in it PCI cards from her previous Dell computer such as...
> A Lucent chip set soft modem
> Sound Blaster 5.1
> three port firewire card
>
> I can lose these PCI cards from the old Dell, since she is on DSL, the
> Asus board has onboard sound, and who needs firewire.
>
> Here is a link to the minidump file created by the latest blue screen...
> http://members.localnet.com/~eddie1...ni031508-01.dmp
>
> I may try on my own to read the minidump by following the directions
> given here... http://support.microsoft.com/kb/315263
>
> Thanks in advance
> Eddie

I have a copy of Debugdiag from Microsoft here. One problem I have
with this tool, is it is too heavyweight for the job. It consists of
a client and a server task. My typical usage pattern, is install it,
read a dump with it, then uninstall it, which is not very practical.
I don't like to leave it installed. If the part that does dump analysis
was separate, at least I'd like that a little better.

http://www.microsoft.com/downloads/...&displaylang=en

I followed your KB article, and I did find a copy of "dumpchk" on my
Win2K CD. It was in support, and was inside a CAB file. I needed
to copy the dumpchk.exe and msdis110.dll into a folder, along with
your dump file. I used a DOS window, to run it, and redirected the
output to a text file.

Now, I don't know if it is really telling the truth or not. I suppose
if I install debugdiag again, I could find out.

*******
Filename . . . . . . .Mini031508-01.dmp
Signature. . . . . . .PAGE
ValidDump. . . . . . .DUMP
MajorVersion . . . . .free system
MinorVersion . . . . .2600
DirectoryTableBase . .0x00039000
PfnDataBase. . . . . .0x80566e48
PsLoadedModuleList . .0x805624a0
PsActiveProcessHead. .0x80568558
MachineImageType . . .i386
NumberProcessors . . .2
BugCheckCode . . . . .0x1000007f
BugCheckParameter1 . .0x00000008
BugCheckParameter2 . .0xf7abfd70
BugCheckParameter3 . .0x00000000
BugCheckParameter4 . .0x00000000

ExceptionCode. . . . .0x80000003
ExceptionFlags . . . .0x00000000
ExceptionAddress . . .0x00000000
*******

When I look here -

http://aumha.org/a/stop.htm

I get this -

0x1000007F: UNEXPECTED_KERNEL_MODE_TRAP_M

and that is why I don't trust the result.

OK, I tried Debugdiag, and this is what was returned.

"DebugDiag failed to locate the PEB (Process Environment Block)
in Mini031508-01.dmp, and as a result, debug analysis for this
dump may be incomplete or inaccurate."

So maybe it is an actual kernel problem.

Years and years ago, I used to do a lot of problem debugging
on proprietary computers we used to build from scratch. My
experience is, if it doesn't "crash once a day", it isn't
possible to make good progress on fixing it. So if the
problem is so infrequent as to be non-reproducible in
a reasonable interval, then changing the hardware config
may be the best thing for it. You may not get enough
crashes, to figure it out.

You can run a copy of Prime95, and this may help you determine
if the motherboard/CPU/RAM has a load dependent problem. When you
start this, and it offers to "Join GIMPS?", say No and choose
the Torture Test instead. When the custom dialog comes up, it
will offer to test some amount of memory (for me, it wants to
test 760MB or so). You can turn that number down a bit, if
you want to do a few other things on the machine at the same
time as the test is running.

http://www.mersenne.org/gimps/p95v255a.zip

Once the custom dialog is set up, start it running. On a P4
with Hyperthreading, the program should start two test threads.

For bad memory, or a processor with problems, the program can
detect an error in 10 seconds. (That is for a system overclocked
into unstable territory.) It will run for hours on a conservatively
set up system. The program won't tell you what is broken, but it
will be something in the CPU-Northbridge-Memory area of the
motherboard.

The longer it runs error free, the "better" your system is. I've
run it for 16 hours on my old P3 system. But never waited that
long on more modern systems. When you're done, there are "stop" and
"exit" options in the left-most menu.

You can also run something like memtest86+ from memtest.org, but
considering the infrequent errors, memtest86+ is too meek to
really kick the wheels off the computer. Prime95 does a better
job of that.

Sometimes, when memory has a low measurable error rate, a
little extra Vdimm in the BIOS can improve the error performance
of the memory. (I use 2.7V on my 2.5V DDR memory, and any memory
should be able to take that much. Winbond BH-5, if memory
serves, could take 3.3V applied to it, to give an extreme
example of voltage boost. But they don't make that memory
any more.)

Alternately, you can adjust the timings in the BIOS, and
loosen them a bit. Say you had 2.5-3-3-6 memory, you could
try 3-4-4-8 and see what happens. If you made such an adjustment
in the BIOS, your first test would be to use memtest86+, as
a quick check that you didn't mis-adjust anything. You don't
want to boot Windows, if memory is messed up badly.

Otherwise, your instinct, of removing the add-in cards and
simplifying the setup, may be a next step. But as long as
the crash rate of the box is low, it'll be a bugger to find.

You can also do a quick visual check for bad caps (bulging
tops or leaking electrolyte from the aluminum cylinders),
but that isn't likely to be the problem. But since a
visual check is fast and cheap, it is worth a look.

http://www.badcaps.net/images/caps/kt7/image004.png

Paul

On Sun, 16 Mar 2008 02:20:24 -0400, E wrote:

> When I brought it home, and hooked it
> up to my monitor, keyboard etc... it came on with no problem. I've never
> had it long enough to duplicate the blue screen.

It's funny you say that. I don't know too much about hardware, or
windows, but my brothers computer experienced similar problems a few
years ago. Turned out he had a keyboard (or was it mouse) driver
installed that was specific for his input device. There was a bug in the
custom driver that was causing doze to crash.

Check the drivers, make sure doze has all updates installed etc.


Hmmm, not good practice X-posting. Cut to single group.


Lionel.

"E" <eddie180@xlxoxcxaxlxnxextx.com> wrote in message
news:13tperfhou5v0b1@corp.supernews.com...
| http://members.localnet.com/~eddie1...ni031508-01.dmp
|
| I built a computer for a relative that has an occasional blue screen
and
| memory dump. I changed out the video card and RAM about a year ago.
She
| still had an occasional blue screen. I then changed out the power
| supply. The PC worked fine for a few months, until yesterday morning
it
| blue screened again. It seems that it can blue screen at any time,
no
| matter what task is being performed. She tolerated it until the last
two
| recent episodes, when after it blue screened, the system would not
boot.
| Just a black screen and no POST. When I brought it home, and hooked
it
| up to my monitor, keyboard etc... it came on with no problem. I've
never
| had it long enough to duplicate the blue screen.
|
| Here is a list of components:
| ASUS P4P800SE 865PE/ICH5 motherboard.
| Nvidia video card
| 1024MB of name brand memory listed as compatible with the board
| Antec 500W Basiq PSU
|
| Also it has in it PCI cards from her previous Dell computer such
as...
| A Lucent chip set soft modem
| Sound Blaster 5.1
| three port firewire card
|
| I can lose these PCI cards from the old Dell, since she is on DSL,
the
| Asus board has onboard sound, and who needs firewire.
|
| Here is a link to the minidump file created by the latest blue
screen...
| http://members.localnet.com/~eddie1...ni031508-01.dmp
|
| I may try on my own to read the minidump by following the directions
| given here... http://support.microsoft.com/kb/315263
|


Diagnosing a fairly rare blue screen crash problem is like looking for
the proverbial needle in the hay stack. Just a couple more
suggestions come to mind in addition to the informed comments posted
by Paul.

There could be a power/voltage rail problem, which might be caused by
the system or an external source. Setup a voltage monitoring program
and log results to a file, look for dips in the voltages beyond 5%
deviation from spec. There could be power line brownouts that occur
where the computer is in use that can affect stable operation of the
system, and testing the system at your home may not result in the same
operation of the computer. You probably don't know whether the blue
screen error message is the same stop error each time. If the stop
error is rarely the same error, I would suspect power regulation as
one possible source of the problem if no problems are detected after
prolonged testing with programs such as memtest86 and prime95. It
could be a capacitor in the Vcore or Vmem circuit, a bad capacitor in
the PS, dirt in the PS, AC line spikes/brownouts, a bad connection
from the PS to the motherboard (unplug/replug power connectors a few
times, this might help). Run a diagnostic on the HD, does it check
out OK for bad sectors. A dying HD can be the source of corrupted
system files. Keep in mind that it only takes one erroneous bit in a
critical system program to bring down the house. If you locate the
problem, post back with your findings.
--
Best regards,
Kyle

Paul wrote:
> E wrote:
>> http://members.localnet.com/~eddie1...ni031508-01.dmp
>>
>
> Now, I don't know if it is really telling the truth or not. I suppose
> if I install debugdiag again, I could find out.
>
> *******
> Filename . . . . . . .Mini031508-01.dmp
> Signature. . . . . . .PAGE
> ValidDump. . . . . . .DUMP
> MajorVersion . . . . .free system
> MinorVersion . . . . .2600
> DirectoryTableBase . .0x00039000
> PfnDataBase. . . . . .0x80566e48
> PsLoadedModuleList . .0x805624a0
> PsActiveProcessHead. .0x80568558
> MachineImageType . . .i386
> NumberProcessors . . .2
> BugCheckCode . . . . .0x1000007f
> BugCheckParameter1 . .0x00000008
> BugCheckParameter2 . .0xf7abfd70
> BugCheckParameter3 . .0x00000000
> BugCheckParameter4 . .0x00000000
>
> ExceptionCode. . . . .0x80000003
> ExceptionFlags . . . .0x00000000
> ExceptionAddress . . .0x00000000
> *******
>
> When I look here -
>
> http://aumha.org/a/stop.htm
>
> I get this -
>
> 0x1000007F: UNEXPECTED_KERNEL_MODE_TRAP_M
>
> and that is why I don't trust the result.
>
> OK, I tried Debugdiag, and this is what was returned.
>
> "DebugDiag failed to locate the PEB (Process Environment Block)
> in Mini031508-01.dmp, and as a result, debug analysis for this
> dump may be incomplete or inaccurate."
>
> So maybe it is an actual kernel problem.
>
> Years and years ago, I used to do a lot of problem debugging
> on proprietary computers we used to build from scratch. My
> experience is, if it doesn't "crash once a day", it isn't
> possible to make good progress on fixing it. So if the
> problem is so infrequent as to be non-reproducible in
> a reasonable interval, then changing the hardware config
> may be the best thing for it. You may not get enough
> crashes, to figure it out.
>
> You can run a copy of Prime95, and this may help you determine
> if the motherboard/CPU/RAM has a load dependent problem. When you
> start this, and it offers to "Join GIMPS?", say No and choose
> the Torture Test instead. When the custom dialog comes up, it
> will offer to test some amount of memory (for me, it wants to
> test 760MB or so). You can turn that number down a bit, if
> you want to do a few other things on the machine at the same
> time as the test is running.
>
> http://www.mersenne.org/gimps/p95v255a.zip
>
> Once the custom dialog is set up, start it running. On a P4
> with Hyperthreading, the program should start two test threads.
>
> For bad memory, or a processor with problems, the program can
> detect an error in 10 seconds. (That is for a system overclocked
> into unstable territory.) It will run for hours on a conservatively
> set up system. The program won't tell you what is broken, but it
> will be something in the CPU-Northbridge-Memory area of the
> motherboard.
>
> The longer it runs error free, the "better" your system is. I've
> run it for 16 hours on my old P3 system. But never waited that
> long on more modern systems. When you're done, there are "stop" and
> "exit" options in the left-most menu.
>
> You can also run something like memtest86+ from memtest.org, but
> considering the infrequent errors, memtest86+ is too meek to
> really kick the wheels off the computer. Prime95 does a better
> job of that.
>
> Sometimes, when memory has a low measurable error rate, a
> little extra Vdimm in the BIOS can improve the error performance
> of the memory. (I use 2.7V on my 2.5V DDR memory, and any memory
> should be able to take that much. Winbond BH-5, if memory
> serves, could take 3.3V applied to it, to give an extreme
> example of voltage boost. But they don't make that memory
> any more.)
>
> Alternately, you can adjust the timings in the BIOS, and
> loosen them a bit. Say you had 2.5-3-3-6 memory, you could
> try 3-4-4-8 and see what happens. If you made such an adjustment
> in the BIOS, your first test would be to use memtest86+, as
> a quick check that you didn't mis-adjust anything. You don't
> want to boot Windows, if memory is messed up badly.
>
> Otherwise, your instinct, of removing the add-in cards and
> simplifying the setup, may be a next step. But as long as
> the crash rate of the box is low, it'll be a bugger to find.
>
> You can also do a quick visual check for bad caps (bulging
> tops or leaking electrolyte from the aluminum cylinders),
> but that isn't likely to be the problem. But since a
> visual check is fast and cheap, it is worth a look.
>
> http://www.badcaps.net/images/caps/kt7/image004.png
>

Thanks for spending some time on this. I am now reading
http://aumha.org/a/stop.htm as well as copying and pasting some of the
hex numbers into google. Of all the systems I've built from scratch
(about 4) and worked on, I've never had one that had these sparse yet
persistent blue screen stop errors. So I've never had to try any of this
type of debugging.

I'm hoping to find that one of the addresses listed in the debug info
you posted for me will be just one in a range of addresses for a piece
of hardware. BugCheckParameter2 . .0xf7abfd70 might have some
significants. Also 0x1000007F: UNEXPECTED_KERNEL_MODE_TRAP_M is worth
looking into.

I have also downloaded this free GUI application from MS...
http://www.microsoft.com/whdc/devto...tallx86.mspx#E3

In addition to the three Dell supplied PCI cards, she is still using the
old Dell CRT monitor, and maybe even mouse and keyboard that came with
the Dell system. Maybe one of these is the culprit.

I also may check if there is a BIOS update for the board, remove the
three unneeded PCI cards, and update device drivers for remaining
hardware. Set BIOS to disable memory caching.

The current Windows XP Home install is the original install. I've never
reinstalled the OS. Its only been updated from Windows Update. The
system has never been over clocked, although the board was designed with
this in mind. The BIOS is set up conservatively. CPU came as boxed set
with Intel heat sink/fan, and runs ~33C idol. The hard drive is a
Seagate Barracuda SATA which should be pretty reliable. Visual
inspection was one of the first things I did when I opened it up this
time. The caps all look like they are intact to my eyes and I can't see
where anything is shorting to ground or to other hardware in the case. I
ran memtest before I changed out the system memory the first time, and
it checked out ok. Still I replaced it.

This may just be concept and correlation, but I have found a couple
others with similar problems in web based message boards that have this
same Asus motherboard. But Asus boards are highly regarded and it would
be the last thing that I would suspect.

Thanks again
Eddie

Lionel van den Berg wrote:
> On Sun, 16 Mar 2008 02:20:24 -0400, E wrote:
>
>> When I brought it home, and hooked it
>> up to my monitor, keyboard etc... it came on with no problem. I've never
>> had it long enough to duplicate the blue screen.
>
> It's funny you say that. I don't know too much about hardware, or
> windows, but my brothers computer experienced similar problems a few
> years ago. Turned out he had a keyboard (or was it mouse) driver
> installed that was specific for his input device. There was a bug in the
> custom driver that was causing doze to crash.

And as I wrote the above I started to wonder the same thing. Maybe just
try a different keyboard and mouse. She is still using the same Dell CRT
Monitor, and if I recall, the same Dell keyboard and mouse. Maybe
coffee on the keyboard?

>
> Check the drivers, make sure doze has all updates installed etc.

I may remove three PCI cards that aren't currently being used. The
system had this same problem before changing out the video card, but I
will update it anyway. I've thought of doing a clean install of XP as well.

>
>
> Hmmm, not good practice X-posting. Cut to single group.
>
>

Yes, I knew better. Haven't posted anything in Usenet for awhile and
thought maybe it didn't matter anymore. But if it helps me getting a
reply, I will comply.

Eddie

Kyle wrote:
> "E" <eddie180@xlxoxcxaxlxnxextx.com> wrote in message

> | Here is a link to the minidump file created by the latest blue
> screen...
> | http://members.localnet.com/~eddie1...ni031508-01.dmp
> |
> | I may try on my own to read the minidump by following the directions
> | given here... http://support.microsoft.com/kb/315263
> |
>
>
> Diagnosing a fairly rare blue screen crash problem is like looking for
> the proverbial needle in the hay stack. Just a couple more
> suggestions come to mind in addition to the informed comments posted
> by Paul.
>
> There could be a power/voltage rail problem, which might be caused by
> the system or an external source. Setup a voltage monitoring program
> and log results to a file, look for dips in the voltages beyond 5%
> deviation from spec. There could be power line brownouts that occur
> where the computer is in use that can affect stable operation of the
> system, and testing the system at your home may not result in the same
> operation of the computer. You probably don't know whether the blue
> screen error message is the same stop error each time. If the stop
> error is rarely the same error, I would suspect power regulation as
> one possible source of the problem if no problems are detected after
> prolonged testing with programs such as memtest86 and prime95. It
> could be a capacitor in the Vcore or Vmem circuit, a bad capacitor in
> the PS, dirt in the PS, AC line spikes/brownouts, a bad connection
> from the PS to the motherboard (unplug/replug power connectors a few
> times, this might help). Run a diagnostic on the HD, does it check
> out OK for bad sectors. A dying HD can be the source of corrupted
> system files. Keep in mind that it only takes one erroneous bit in a
> critical system program to bring down the house. If you locate the
> problem, post back with your findings.


This is a new Antec 500W PSU, that was notably heavier than the first
off name '580 Watt' PSU that I had used when I first built the system.
But I guess that doesn't rule out problems with the power circuits on
the motherboard that you mention. The PC has been in four different
residences, so I don't think its a a problem with whatever 120VAC
circuit its plugged into.

There are 13 minidump files in the /Windows/Minidump folder. I have
downloaded this debugging application from MS...
http://www.microsoft.com/whdc/devto...tallx86.mspx#E3
Maybe it will clue me in.

If I remove the three unneeded PCI boards from the system, that will
take some off hay the stack.

The HD is a Seagate Barracuda SATA, but running diags on this disk isn't
a bad idea.

Eddie

"E" <eddie180@xlxoxcxaxlxnxextx.com> wrote in message
news:13tperfhou5v0b1@corp.supernews.com...
> http://members.localnet.com/~eddie1...ni031508-01.dmp
>


I downloaded a debuging utility from MS called WinDbg found here...
http://www.microsoft.com/whdc/devto...ng/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

E wrote:
> "E" <eddie180@xlxoxcxaxlxnxextx.com> wrote in message
> news:13tperfhou5v0b1@corp.supernews.com...
> > http://members.localnet.com/~eddie1...ni031508-01.dmp
> >
>
>
> I downloaded a debuging utility from MS called WinDbg found here...
> http://www.microsoft.com/whdc/devto...ng/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

"E" <eddie180@xlxoxcxaxlxnxextx.com> wrote in message
news:13tperfhou5v0b1@corp.supernews.com...

> Here is a list of components:
> ASUS P4P800SE 865PE/ICH5 motherboard.
> Nvidia video card
> 1024MB of name brand memory listed as compatible with the board
> Antec 500W Basiq PSU
>
> Also it has in it PCI cards from her previous Dell computer such as...
> A Lucent chip set soft modem
> Sound Blaster 5.1
> three port firewire card
>
> I can lose these PCI cards from the old Dell, since she is on DSL, the
> Asus board has onboard sound, and who needs firewire.

the SoundBlaster card is your problem.. Dump it, and dump all of the drivers
and your pc will run flawless...

SB cards are good if your willing to invest the time and effort into making
them work AND making the software on the pc use them correctly.

Even a properly configured SB card can err when other programs make invalid
calls.