询问者
求助:用windbg分析dump文件

问题
-
周末看了一下,windbg,自己只能查到这里,知道是驱动的错造成,但不知道,具体是那个驱动造成的,接下来,怎么操作,不知那位高手,帮忙指点一下!
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null. This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this. The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: 85ed5648, The address of the queue entry whose flink/blink field is NULL
Arg2: 8055befc, The address of the queue being references. Usually this is one
of the ExWorkerQueues.
Arg3: 8055bec0, The base address of the ExWorkerQueue array. This will help determine
if the queue in question is an ExWorkerQueue and if so, the offset from
this parameter will isolate the queue.
Arg4: 8056c9f0, If this is an ExWorkerQueue (which it usually is), this is the address
of the worker routine that would have been called if the work item was
valid. This can be used to isolate the driver that is misusing the work
queue.Debugging Details:
------------------
WORKER_ROUTINE:
nt!NtQueryValueKey+60
8056c9f0 8bff mov edi,ediFAULTING_IP:
nt!NtQueryValueKey+60
8056c9f0 8bff mov edi,ediWORK_ITEM: 85ed5648
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x96
PROCESS_NAME: System
LAST_CONTROL_TRANSFER: from 804fc33f to 804f9c77
STACK_TEXT:
f12b5d2c 804fc33f 00000096 85ed5648 8055befc nt!CcSetDirtyInMask+0xf8
f12b5d6c 805359c4 00000001 00000001 f12b5d8c nt!MiInitializeReadInProgressPfn+0x10
f12b5dac 805c6c84 85ed5648 00000000 00000000 nt!Ki386BiosCallReturnAddress+0x5e
f12b5ddc 80542bc2 805358ee 80000001 00000000 nt!IopTranslateAndAdjustReqDesc+0xc7
f12b5eac 007f007f 007f007f 007f007f 007f007f nt!RtlLogStackBackTrace+0x4a
WARNING: Frame IP not in any known module. Following frames may be wrong.
00000000 00000000 00000000 00000000 00000000 0x7f007f
STACK_COMMAND: .bugcheck ; kbFOLLOWUP_IP:
nt!NtQueryValueKey+60
8056c9f0 8bff mov edi,ediSYMBOL_NAME: nt!NtQueryValueKey+60
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 498c079b
FAILURE_BUCKET_ID: 0x96_nt!NtQueryValueKey+60
BUCKET_ID: 0x96_nt!NtQueryValueKey+60
Followup: MachineOwner
---------
zqkwll- 已编辑 周琪凯 2009年6月7日 15:29
全部回复
-
开机后无法启动,XP提示:
Windows could not start because the following file is missing or corrupt:
\system32\ntoskrnl.exe.
Please reinstall a copy of the above file.
ntoskrnl.exe文件找不到了,那么这个文件是干什么的?哪里去了呢?
ntoskrnl.exe是winows的一个进程文件,在系统经过预启动和启动阶段后进入内核调用阶段时由Ntldr调用Ntoskrnl.exe, 在WINXP系统中存储了WIN XP的启动LOGO画面。
调用Ntoskrnl.exe文件时将由Ntdetect.com收集的硬件信息传递给它,同时被调用的还有hal.dll文件.
也就是说,如果这个文件丢失或损坏,Windows Xp启动时那个Logo都出不来,也就没有下一步可以看了。
昨天尝试了很多方法,光盘上的copy、解压覆盖,系统上的备份覆盖还是不管用。
最后放弃了,修复安装,结果今天打补丁到某次重起后,问题再次出现。
现在我不能忍受再次重装了,于是反复研究,终于还是找到了一个合适的版本。
在 "c:\windows\driver cache\i386"目录下有sp2.cab和sp1.cab文件,存放了不同补丁包的一些驱动文件,我将sp2.cab中的ntoskrnl.exe解压缩出来,终于恢复了系统:
expand sp2.cab -F:ntoskrnl.exe c:\windows\system32
当然首先要用光盘启动到修复模式,进入命令行进行操作。
看来是微软的某个Patch有问题,覆盖之后会导致系统无法启动。