New
#1
BSOD Error 0x0000000a
Hello i have recently just been getting BSOD and i am getting the error in the title.
Hello i have recently just been getting BSOD and i am getting the error in the title.
Looking over the drivers it looks like a kernel driver issue. Not an exper though
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?
Please create a restore point, then follow this: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
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:
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> .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 address here does appear to be in the nt kernel: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
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).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.
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.