
Originally Posted by
Helcat
While I was waiting I found BlueScreen viewer and there seemed to be a common theme of failing on ntoskrnl.exe. Do I need to worry about that as well or just assume that you were able to look deeper into the dump files to see the 3 driver issues that you directed me to?
No not typically. It's getting the blame because of the nature of the errors (involving the Kernel).
Of your five dump files, three are Kernel Mode Traps (7f) DOUBLE FAULT EXCEPTIONS;
Code:
UNEXPECTED_KERNEL_MODE_TRAP (7f)
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: 0000000000000008, EXCEPTION_DOUBLE_FAULT The other two are;
Code:
APC_INDEX_MISMATCH (1)
This is a kernel internal error. The most common reason to see this
bugcheck is when a filesystem or a driver has a mismatched number of
calls to disable and re-enable APCs. The key data item is the
Thread->KernelApcDisable field. A negative value indicates that a driver
has disabled APC calls without re-enabling them. A positive value indicates
that the reverse is true. This check is made on exit from a system call.
Arguments:
Arg1: 00000000770c1dea, address of system function (system call)
Arg2: 0000000000000000, Thread->ApcStateIndex << 8 | Previous ApcStateIndex
Arg3: 000000000000ffff, Thread->KernelApcDisable
Arg4: fffff88007109ca0, Previous KernelApcDisable
And
Code:
MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000000403, The subtype of the bugcheck.
Arg2: fffff6800000ff18
Arg3: 8bb000006da01867
Arg4: dffff6800000ff18 
Originally Posted by
Helcat
I had just run CPU-Z and my motherboard is an eMachines WMCP61M and the chipset is NVIDIA MCP61 Rev A3. To install updates on those or the BIOS do I need to take care to be in safe mode or just feel comfortable downloading from manufacturers website and let it rip?
As far as updating hardware device drivers (Chipset) usually the motherboard manufacturer is the best bet for a resource, however; because Emachines are kind of a sub-species of computers and can be a product from Gateway or from Acer or perhaps other manufacturers there may be instances where the actual system manufacturer is the best resource as there may be proprietary considerations that I could not possibly be aware of.
And as far as BIOS updates (flashing), there is always a small risk involved albeit slight, that a problem can arise resulting in an unbootable and unrecoverable machine. You should always consult you computer documentation regarding this process as well as any and all accompanying information regarding the update and or flash utility (release notes, readme files, etc.,) and make sure you understand what the process entails and how to perform it correctly.
Regards
Randy