Barnardos_2LS
asked on
WinDbg Driver Identification
Good afternoon,
After running a kernel dump through WinDbg it has identified a driver fault but has not explicitly stated which caused the crash. How can I determine this information from the WinDbg data:
Debugging Details:
------------------
WORKER_ROUTINE:
nt!IopProcessWorkItem+0
8056ae40 8bff mov edi,edi
FAULTING_IP:
nt!IopProcessWorkItem+0
8056ae40 8bff mov edi,edi
WORK_ITEM: 85fdcb60
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x96
PROCESS_NAME: System
LAST_CONTROL_TRANSFER: from 804fb1df to 804f8aef
STACK_TEXT:
f7aacd2c 804fb1df 00000096 85fdcb60 8055a3fc nt!KeBugCheckEx+0x1b
f7aacd6c 80533fbc 00000001 51600001 00000000 nt!KeRemoveQueue+0x2e7
f7aacdac 805c4cce 85fdcb60 00000000 00000000 nt!ExpWorkerThread+0xd6
f7aacddc 805411c2 80533ee6 00000001 00000000 nt!PspSystemThreadStartup+ 0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: .bugcheck ; kb
FOLLOWUP_IP:
nt!IopProcessWorkItem+0
8056ae40 8bff mov edi,edi
SYMBOL_NAME: nt!IopProcessWorkItem+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 45e53f9c
FAILURE_BUCKET_ID: 0x96_nt!IopProcessWorkItem +0
BUCKET_ID: 0x96_nt!IopProcessWorkItem +0
Followup: MachineOwner
---------
After running a kernel dump through WinDbg it has identified a driver fault but has not explicitly stated which caused the crash. How can I determine this information from the WinDbg data:
Debugging Details:
------------------
WORKER_ROUTINE:
nt!IopProcessWorkItem+0
8056ae40 8bff mov edi,edi
FAULTING_IP:
nt!IopProcessWorkItem+0
8056ae40 8bff mov edi,edi
WORK_ITEM: 85fdcb60
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x96
PROCESS_NAME: System
LAST_CONTROL_TRANSFER: from 804fb1df to 804f8aef
STACK_TEXT:
f7aacd2c 804fb1df 00000096 85fdcb60 8055a3fc nt!KeBugCheckEx+0x1b
f7aacd6c 80533fbc 00000001 51600001 00000000 nt!KeRemoveQueue+0x2e7
f7aacdac 805c4cce 85fdcb60 00000000 00000000 nt!ExpWorkerThread+0xd6
f7aacddc 805411c2 80533ee6 00000001 00000000 nt!PspSystemThreadStartup+
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: .bugcheck ; kb
FOLLOWUP_IP:
nt!IopProcessWorkItem+0
8056ae40 8bff mov edi,edi
SYMBOL_NAME: nt!IopProcessWorkItem+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
DEBUG_FLR_IMAGE_TIMESTAMP:
FAILURE_BUCKET_ID: 0x96_nt!IopProcessWorkItem
BUCKET_ID: 0x96_nt!IopProcessWorkItem
Followup: MachineOwner
---------
check your NIc by uninstalling and reinstalling, dont think this points to anything other than those two pieces of kit
ASKER
How did you identify this? For future information...
best place to look at these bug checks is the image name: this identifies usually teh root cause, however depending on which image it points to can have an impact on dignosis.
the error in question points to teh kernel of the Os being either part of the ethernet link or its a fault with the RAM modules.
Please bear in mind though these minidumps anlaysis and bug checks are not exact scince and it can sometimes take awhiel to pinpoint the issue
the error in question points to teh kernel of the Os being either part of the ethernet link or its a fault with the RAM modules.
Please bear in mind though these minidumps anlaysis and bug checks are not exact scince and it can sometimes take awhiel to pinpoint the issue
ASKER
So ntkrnlpa.exe relates to Ethernet or RAM?
i would say 80% of the time thhis would be related to ram as its part of the core of teh OS and so that owuld be my first port of call and investigation.
The flip side to that is that a driver fault has been identified and so i always look towards NIC first when it is linked to the ntkrnlpa.exe image fault.
Like i said this isnt exact science and can be a process of elimination but with time you get a feel for what the linkages are between teh different segments of a bug check
The flip side to that is that a driver fault has been identified and so i always look towards NIC first when it is linked to the ntkrnlpa.exe image fault.
Like i said this isnt exact science and can be a process of elimination but with time you get a feel for what the linkages are between teh different segments of a bug check
Ok ive done a bit more digging ot get you a better dexcription of what this specific file does and it is to do with allowing the 32 bit version of windows use the PAE up to 4gb within teh windows system and how it is allocated. The PAE is the addressable space of memory that windows can use and in 32bit version this is limitied to 4gb including teh video ram.
Therefore as the file is linked to the PAE that is why i lean towards the RAM issue as the RAM is basically the addressable memory of the machine.
Also following on from this if the RAM isnt faulty could be the video card in addition to the NIC as all require PAE space
Therefore as the file is linked to the PAE that is why i lean towards the RAM issue as the RAM is basically the addressable memory of the machine.
Also following on from this if the RAM isnt faulty could be the video card in addition to the NIC as all require PAE space
ASKER
Thanks for your help. Where are you digging?? Are their any decent resources on the Internet to identify these issues?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you.
no problem, please remember to close the question if it has helped you by selecting one of the answers
tyest your rem by running www.memtest86.org, run 3 opasses to ensure its ok