BSOD cause with dump files

PSEAST · Aug 10, 2015

I have had a reoccurring BSOD and a, hoping someone can help me out.

Who crashed says:

crash dump file: C:\Windows\Minidump\071515-7937-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x150CA0)
Bugcheck code: 0xC000021A (0xFFFFC000596BFAA0, 0x0, 0x0, 0x0)
Error: STATUS_SYSTEM_PROCESS_TERMINATED
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This means that an error has occurred in a crucial user-mode subsystem.
There is a possibility this problem was caused by a virus or other malware.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

I turned on driver verifiers and got some other driver issues, couldn't start up etc. "Driver IRQL not less or equal". Did some driver updates and seemed to be ok. With driver verifiers off I don't get those issues.

I haven't paid for pro so it wont let me see its dump files.

Couldn't find dump files in my computer any other way.

Downloaded Windows SDK and installed WinDBG. This is what is shows:

Microsoft (R) Windows Debugger Version 6.3.9600.17298 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17736.amd64fre.winblue_r9.150322-1500
Machine Name:
Kernel base = 0xfffff803`ece7e000 PsLoadedModuleList = 0xfffff803`ed157850
Debug session time: Mon Aug 10 20:47:10.272 2015 (UTC + 7:00)
System Uptime: 0 days 0:00:06.060
Loading Kernel Symbols
...............................................................
..............................................................
Loading User Symbols

Loading unloaded module list
...
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {fffff80010076638, 2, 8, fffff80010076638}

*** ERROR: Module load completed but symbols could not be loaded for MijXfilt.sys
Probably caused by : MijXfilt.sys ( MijXfilt+1b638 )

Followup: MachineOwner
---------

How can I get some good dump file reports to post?

Also, had some network issues. turned out my network drivers weren't installed correctly. Sometimes I could connect, sometimes it wouldn't, and the network wouldn't show in device manager. Repaired my driver and it all Checked out again. Could that be the cause of the 0xC000021A ntoskrnl.exe error?

Thanks for the help in advance!

Patrick

MarkW · Aug 10, 2015

Joystick controller driver on the Xbox.

Plug the joystick back in?

PSEAST · Aug 10, 2015

MarkW :

Hi there,

After updating a few drivers and running driver verifies with a number of settings checked I haven't had problems. Hopefully that will do.

Does anyone know how I can get more descriptive dump files with Windbg? I don't think mine is set up properly. Do I have to download symbols?

johnbl · Aug 10, 2015

you don't have to download symbols, you just need to enter the path to the windows symbol server
http://msdl.microsoft.com/download/symbols

just hit contro+s to bring up the menu, put in the path and hit ok and exit. the next time you start the debugger it should be saved.

to get more debugging info saved in the memory dump you have to change the memory dump type from minidump to kernel memory dump. also if you run verifier.exe more info will be saved. Very useful to have the kernel memory dump as more automated debugging commands work.
and info on plug and play, USB, networks, and all drivers is saved.
minidump just saves the list of drivers, some bios info and the current stack backtrace.

for example:
lmiftsm will show the list of drivers sorted in alphnumeric order on a minidump
!for_each_module !chkimg @#ModuleName
will check each windows file for corruption in memory dump. (only checks microsoft owned files)

just too many commands to list, more of the automated commands are available when you have a kernel or full memory dump.

for example:
!pnptriage looks for plug and play problems but must be run on a kernel memory dump, often useful for figuring out a watchdog timeout problem related to failure to install a driver on one CPU core.

driver verifier helps to find problems with drivers that would be very hard to find otherwise. For example, I looked at a razer driver that would corrupt memory depending on how much paging was going on in the system.
the driver would work fine until the memory manager paged the driver out while a game was running and the driver was not used. Then when you exit the game or used certain functions the windows memory manager would load the driver into memory again but at a different location. Problem is the driver had a user interface that would use the old memory locations and would write data over that location. This could result in a crash depending on who (what driver) currently owned that memory location.

with driver verifier it check to make sure the driver owns the memory location it is writing to and calls a bugcheck if it is out of bounds. Very useful and pretty quick to help figure out what driver is causing problems.

PSEAST :

PSEAST · Aug 10, 2015

johnbl :

you don't have to download symbols, you just need to enter the path to the windows symbol server
http://msdl.microsoft.com/download/symbols

just hit contro+s to bring up the menu, put in the path and hit ok and exit. the next time you start the debugger it should be saved.

to get more debugging info saved in the memory dump you have to change the memory dump type from minidump to kernel memory dump. also if you run verifier.exe more info will be saved. Very useful to have the kernel memory dump as more automated debugging commands work.
and info on plug and play, USB, networks, and all drivers is saved.
minidump just saves the list of drivers, some bios info and the current stack backtrace.

for example:
lmiftsm will show the list of drivers sorted in alphnumeric order on a minidump
!for_each_module !chkimg @#ModuleName
will check each windows file for corruption in memory dump. (only checks microsoft owned files)

just too many commands to list, more of the automated commands are available when you have a kernel or full memory dump.

for example:
!pnptriage looks for plug and play problems but must be run on a kernel memory dump, often useful for figuring out a watchdog timeout problem related to failure to install a driver on one CPU core.

driver verifier helps to find problems with drivers that would be very hard to find otherwise. For example, I looked at a razer driver that would corrupt memory depending on how much paging was going on in the system.
the driver would work fine until the memory manager paged the driver out while a game was running and the driver was not used. Then when you exit the game or used certain functions the windows memory manager would load the driver into memory again but at a different location. Problem is the driver had a user interface that would use the old memory locations and would write data over that location. This could result in a crash depending on who (what driver) currently owned that memory location.

with driver verifier it check to make sure the driver owns the memory location it is writing to and calls a bugcheck if it is out of bounds. Very useful and pretty quick to help figure out what driver is causing problems.

PSEAST :

Excellent,

I chose the kernel memory dump option because the full memory dump is only available for 2gb ram or less machines, is that right?

johnbl · Aug 14, 2015

full memory dump should work for all machines. I have looked a tmemory dumps that were 12GB

they will contain all of the user program that are currently in memory.

PSEAST :

johnbl :

you don't have to download symbols, you just need to enter the path to the windows symbol server
http://msdl.microsoft.com/download/symbols

just hit contro+s to bring up the menu, put in the path and hit ok and exit. the next time you start the debugger it should be saved.

to get more debugging info saved in the memory dump you have to change the memory dump type from minidump to kernel memory dump. also if you run verifier.exe more info will be saved. Very useful to have the kernel memory dump as more automated debugging commands work.
and info on plug and play, USB, networks, and all drivers is saved.
minidump just saves the list of drivers, some bios info and the current stack backtrace.

for example:
lmiftsm will show the list of drivers sorted in alphnumeric order on a minidump
!for_each_module !chkimg @#ModuleName
will check each windows file for corruption in memory dump. (only checks microsoft owned files)

just too many commands to list, more of the automated commands are available when you have a kernel or full memory dump.

for example:
!pnptriage looks for plug and play problems but must be run on a kernel memory dump, often useful for figuring out a watchdog timeout problem related to failure to install a driver on one CPU core.

driver verifier helps to find problems with drivers that would be very hard to find otherwise. For example, I looked at a razer driver that would corrupt memory depending on how much paging was going on in the system.
the driver would work fine until the memory manager paged the driver out while a game was running and the driver was not used. Then when you exit the game or used certain functions the windows memory manager would load the driver into memory again but at a different location. Problem is the driver had a user interface that would use the old memory locations and would write data over that location. This could result in a crash depending on who (what driver) currently owned that memory location.

with driver verifier it check to make sure the driver owns the memory location it is writing to and calls a bugcheck if it is out of bounds. Very useful and pretty quick to help figure out what driver is causing problems.

PSEAST :

Excellent,

I chose the kernel memory dump option because the full memory dump is only available for 2gb ram or less machines, is that right?

Search

BSOD cause with dump files

PSEAST

Reputable

johnbl

MarkW

Judicious

PSEAST

Reputable

johnbl

Polypheme

PSEAST

Reputable

johnbl

Polypheme

TRENDING THREADS

Latest posts

Moderators online

Share this page