none
求助:用windbg分析dump文件 RRS feed

  • 问题

  • 周末看了一下,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,edi

    FAULTING_IP:
    nt!NtQueryValueKey+60
    8056c9f0 8bff            mov     edi,edi

    WORK_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 ; kb

    FOLLOWUP_IP:
    nt!NtQueryValueKey+60
    8056c9f0 8bff            mov     edi,edi

    SYMBOL_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有问题,覆盖之后会导致系统无法启动。
    2009年6月8日 8:12