BSOD Error 0x0000000a

I'm downloading the zip file now. In future, please attached the files here directly using this:

OK. Im getting some conflicting results.

Questions:
1. Is Windows Updated?
2. Are you using a RAID array or Storage Spaces in Windows 8.1?

Code:

ffffd000`e3549ff0  ????????`????????
ffffd000`e3549ff8  ????????`????????
ffffd000`e354a000  00000000`000001e0
ffffd000`e354a008  fffff800`85524807Unable to load image \SystemRoot\System32\Drivers\dump_iaStorA.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for dump_iaStorA.sys
*** ERROR: Module load completed but symbols could not be loaded for dump_iaStorA.sys
 dump_iaStorA+0x78807
ffffd000`e354a010  ffffe000`7c202a68
ffffd000`e354a018  ffffd000`e354a070
ffffd000`e354a020  00000000`00000000

Please create a restore point, then follow this:

Remove Intel Rapid Storage Technology applications.

1. Uninstall it from Control Panel > Programs and Features.
2. Uninstall the driver from device manager:
- Right click on "my computer" icon and click "manage" on the context menu.
- In the "Computer Management" window that opens:
- Select "Device Manager" in the left pane, It will list all the existing devices.
- Expand "IDE ATA/ATAPI controllers" by clicking on the triangle in front of it.
- Select one Intel device item under it, right click, then uninstall.
- Repeat the process for all Intel items under "IDE ATA/ATAPI controllers"
3. Now restart the computer.
4. Once booted, Windows will auto configure the appropriate native system driver.

The address that references the invalid memory address appears to be a kernel-mode address, specifically in the initial loader mapping range:

Code:

3: kd> .bugcheck
Bugcheck code 0000000A
Arguments 00000000`00000048 00000000`00000002 00000000`00000001 fffff802`33f20230
 
3: kd> !address fffff80233f20230
Usage:                  
Base Address:           fffff800`00000000
End Address:            fffff802`341c80e7
Region Size:            00000002`341c80e7
VA Type:                BootLoaded
VAD Address:            0x27676e69727473
Commit Charge:          0x100000004
Protection:             0x7ffef0af5b08 []
Memory Usage:           Private
No Change:              yes
 
3: kd> !vad 0xfffff80000000000
GetPointerFromAddress: unable to read from fffff802341c8010
VAD           Level     Start       End Commit
Unable to get LeftChild of nt!_MMVAD_SHORT at fffff80000000000

The initial loader mapping range (about 512GB starting at fffff80000000000) contains the NT kernel binary, the HAL, and any loaded kernel debugger DLLs, as well as idle thread stacks, DPC stacks, and the KPCR and the idle thread's structures. Looking at the actual thread that was running at the time of the crash, it would seem to be a worker thread for some other thread:

Code:

3: kd> kn
 # Child-SP          RetAddr           Call Site
00 ffffd000`e354ae98 fffff802`33fd3ae9 nt!KeBugCheckEx
01 ffffd000`e354aea0 fffff802`33fd233a nt!KiBugCheckDispatch+0x69
02 ffffd000`e354afe0 fffff802`33f20230 nt!KiPageFault+0x23a
03 (Inline Function) --------`-------- nt!ExAcquireSpinLockExclusiveAtDpcLevel+0x12
04 (Inline Function) --------`-------- nt!MiLockControlAreaExclusiveAtDpc+0x12
05 ffffd000`e354b170 fffff802`33f2003c nt!MiIdentifyPfn+0x160
06 ffffd000`e354b220 fffff802`3428f6cb nt!MiIdentifyPfnWrapper+0x3c
07 (Inline Function) --------`-------- nt!MmQueryPfnList+0x41
08 ffffd000`e354b250 fffff802`34265083 nt!PfpPfnPrioRequest+0xbb
09 ffffd000`e354b2d0 fffff802`342631b3 nt!PfQuerySuperfetchInformation+0x313
0a ffffd000`e354b400 fffff802`34262f61 nt!ExpQuerySystemInformation+0x1ff
0b ffffd000`e354bac0 fffff802`33fd37b3 nt!NtQuerySystemInformation+0x49
0c ffffd000`e354bb00 00007ffb`a029aeea nt!KiSystemServiceCopyEnd+0x13
0d 0000001b`f5f9c558 00000000`00000000 0x00007ffb`a029aeea

The address here does appear to be in the nt kernel:

Code:

3: kd> lmDvm nt
Browse full module list
start             end                 module name
fffff802`33e74000 fffff802`345fd000   nt
    Loaded symbol image file: ntkrnlmp.exe
    Image path: ntkrnlmp.exe
    Image name: ntkrnlmp.exe
    Timestamp:        Sat Feb 22 00:08:18 2014 (53085AF2)
    CheckSum:         0071FAD2
    ImageSize:        00789000
    File version:     6.3.9600.17031
    Product version:  6.3.9600.17031
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® Windows® Operating System
    InternalName:     ntkrnlmp.exe
    OriginalFilename: ntkrnlmp.exe
    ProductVersion:   6.3.9600.17031
    FileVersion:      6.3.9600.17031 (winblue_gdr.140221-1952)
    FileDescription:  NT Kernel & System
    LegalCopyright:   © Microsoft Corporation. All rights reserved.

All of this would indicate virtual memory corruption, so to catch the culprit would probably require enabling special pool at this point. I would not agree that doing anything with the Intel driver would help, as the "dump_iastor<blah>" issue is always there with that driver, so seeing issues with loading symbols or hashing it out is pretty typical. It's always wise to update drivers, of course, but in this case the fact that it's in a list of modules isn't necessarily a reason for any other issues, it's just a symptom of how the Intel storage driver implements itself to be able to handle dump files if the system crashes (as a storage driver must be running to save a .dmp file).

Thanks Carl. Whats the suggested solution do you think?

No clue - this looks like a PFN is corrupt, which would indicate virtual memory errors. Only something running in kernel-mode can modify this, and either there's a bug in the memory manager (less likely) or a kernel-mode driver (more likely) causing the problem, either advertently or inadvertently.

It's not likely a hardware problem (although anything is technically possible), but catching something corrupting kernel memory really requires special pool to be enabled, and another dump captured (a FULL dump if possible) when the problem occurs next.