我的xp蓝屏dbg信息和微软xp论坛版主回复

显示全部楼层 · 发表于 2011-1-14 16:23:04

Windows 客户端技术中心 > Windows Client 论坛 > Windows XP > 求助！！！xp蓝屏dbg信息
[size=1.25em]提出问题搜索论坛：

求助！！！xp蓝屏dbg信息

- 删除警报
- 编辑
- 更改类型
[size=1.1em]2010年12月24日 9:34[size=1.25em]21597357

[size=1.5em]0

[size=1em]Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\WINDOWS\Minidump\Mini122410-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\temp*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.100427-1636
Machine Name:
Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055e720
Debug session time: Fri Dec 24 15:45:58.281 2010 (GMT+8)
System Uptime: 0 days 3:30:04.617
Loading Kernel Symbols
...............................................................
...................................................
Loading User Symbols
Loading unloaded module list
....................
*******************************************************************************
*                                                                            *
*                      Bugcheck Analysis                                  *
*                                                                            *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000000A, {e8, 2, 1, 806e7a16}

Unable to load image kl1.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for kl1.sys
*** ERROR: Module load completed but symbols could not be loaded for kl1.sys
Unable to load image klim5.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for klim5.sys
*** ERROR: Module load completed but symbols could not be loaded for klim5.sys
Probably caused by : kl1.sys ( kl1+3b8e5 )

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

0: kd> !analyze -v
*******************************************************************************
*                                                                            *
*                      Bugcheck Analysis                                  *
*                                                                            *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 000000e8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :

bit 0 : value 0 = read operation, 1 = write operation

bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 806e7a16, address which referenced memory

Debugging Details:
------------------

WRITE_ADDRESS:  000000e8

CURRENT_IRQL:  2

FAULTING_IP:
hal!KeAcquireInStackQueuedSpinLock+26
806e7a16 8711          xchg edx,dword ptr [ecx]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  Idle

LAST_CONTROL_TRANSFER:  from 804fd4aa to 806e7a16

STACK_TEXT:
80551c8c 804fd4aa 87cbb2b0 87838a70 87cbb2d8 hal!KeAcquireInStackQueuedSpinLock+0x26
80551cac 9eee2f95 87cbb2d8 87838a70 00000000 nt!KeInsertQueueApc+0x20
80551cdc 804f26c0 888a5030 87654f20 875c4248 afd!AfdRestartConnect+0x172
80551d0c a250e8e5 8780ab17 8780aa80 804f26c0 nt!IopfCompleteRequest+0xa2
WARNING: Stack unwind information not available. Following frames may be wrong.
80551d48 9ef47942 895df360 8760c268 00000002 kl1+0x3b8e5
80551d60 9ef4d471 8780aa80 00000000 00000000 tcpip!TCPDataRequestComplete+0xa6
80551d74 9ef4df10 8780aa80 00000000 00000000 tcpip!TCPRequestComplete+0x12
80551d94 9ef51d77 8760c268 80551f54 00000000 tcpip!CompleteConnReq+0x87
80551e18 9ef44ef5 883235b8 ce845071 26a77dde tcpip!TCPRcv+0xe35
80551e78 9ef44b19 00000020 883235b8 9ef470b6 tcpip!DeliverToUser+0x18e
80551ef4 9ef44836 9ef848f0 883235b8 89594072 tcpip!DeliverToUserEx+0x95e
80551fac 9fd12232 883235b8 89594086 0000001c tcpip!IPRcvPacket+0x6cb
80551ff0 9fd122cc 0cabb1e5 893daf30 89594064 wanarp!WanReceiveCommon+0x164
80552028 b9de0b9f 0cabb1e5 00000000 b49fdb40 wanarp!WanNdisReceivePacket+0x60
8055207c b49f801d 0038d420 88cec580 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x1c2
80552090 b49f81b4 894d3930 88cec580 00000001 psched!PsFlushReceiveQueue+0x15
805520b4 b49f85f9 893d78d8 00000000 894d3930 psched!PsEnqueueReceivePacket+0xda
805520cc b9de0c40 893d78d0 894f5130 883728c8 psched!ClReceiveComplete+0x13
8055211c ba15a494 0038d420 8892b9ac 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4
80552144 ba15ce9d 8892b970 883728c8 893daf50 klim5+0x2494
80552168 b9de0b9f 893dc5c8 883728c8 8821b2f0 klim5+0x4e9d
805521bc b4a0eb80 0038d420 805521fc 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x1c2
805521f0 b4a0ee3c 02840888 883728c8 88840888 ndiswan!IndicateRecvPacket+0x2bb
80552224 b4a0f2e9 88840888 89594008 00000032 ndiswan!ProcessPPPFrame+0x193
80552240 b4a0cd6b 8961e008 89594008 893d6928 ndiswan!ReceivePPP+0x76
80552264 b9ddb888 00000001 88ef9614 00000032 ndiswan!ProtoWanReceiveIndication+0x106
80552288 ba179979 805522b0 024eb250 00000001 NDIS!NdisMWanIndicateReceive+0x54
805522c0 ba17ee9d 8821c2a0 8821c018 00000000 raspppoe!MpIndicateReceivedPackets+0x93
805522e0 8050320f ba181028 ba180fe0 9a55e954 raspppoe!TimerEvent+0x7f
805523fc 8050332b 8055d0c0 ffdff9c0 ffdff000 nt!KiTimerListExpire+0x14b
80552428 80546ebf 8055d4c0 00000000 000c4f27 nt!KiTimerExpiration+0xb1
80552440 8055ce60 ffdffc50 00000000 8055ce60 nt!KiRetireDpcList+0x61
80552450 80546da4 00000000 0000000e 00000000 nt!KiIdleThread0
80552454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28

STACK_COMMAND:  kb

FOLLOWUP_IP:
kl1+3b8e5
a250e8e5 ??             ???

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  kl1+3b8e5

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: kl1

IMAGE_NAME:  kl1.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a9d0583

FAILURE_BUCKET_ID:  0xA_kl1+3b8e5

BUCKET_ID:  0xA_kl1+3b8e5

Followup: MachineOwner
---------
- 回复
- 引用

全部回复

[size=1.1em]2010年12月24日 13:47[size=1.25em]Alexis Zhang[size=1.2em]MVP, 版主

[size=1.5em]0

[size=0.9em]投票认定帖子内容有帮助
[size=1em]kl1.sys，这个文件应该是卡巴斯基添加的虚拟设备驱动，搜索一下这个文件在硬盘的什么地方，其文件签名是不是卡巴斯基的。如果是的话请暂时关闭卡巴斯基看看问题能否解决。

--
Alexis Zhang

https://mvp.support.microsoft.com/profile/jie
http://blogs.itecn.net/blogs/alexis

推荐以 NNTP Bridge 桥接新闻组方式访问论坛以获取最佳用户体验。

本帖是回复帖，原帖��者是楼上的 "21597357"

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

[size=0.85em]举报为违规帖子
- 回复
- 引用
- 标记为答复

显示全部楼层 · 发表于 2011-1-14 16:29:37

请大家帮我看一下，这个到底是不是什么原因？系统是msdn版的xpsp3,我用工行序列号激活安装的，不是ghost系统。卡巴斯基用的是kis2010，我现在怀疑是：
1.我的显卡驱动不行，因为我没有用光盘自带的显卡驱动，用的是催化剂10.7。自带的10.2
2.是迅雷或者utorrent破解了连接数导致蓝屏。因为总是在下载或者bt的时候出现自动关机然后重启就蓝了。
3.卡巴是不是和迅雷有冲突？网上很多这样的例子，另我用的迅雷是5.8.14706.
搞得我现在都不敢用xp了，只用win7了，奇怪的是我在win7里还是用这个版本的卡巴斯基，也同样是这个版本的迅雷和utorrent。倒是从来没有蓝屏过了。

显示全部楼层 · 发表于 2011-1-14 16:31:40

这个是版主回复我的帖子，复制如下：

Alexis Zhang
MVP, 版主

0
投票认定帖子内容有帮助
我认为与显卡驱动关系不大。迅雷倒是有可能，因为卡巴斯基会在网络连接中以协议方式添加过滤器，在下载时容易出现蓝屏与卡巴斯基的关系比较大。

--
Alexis Zhang

https://mvp.support.microsoft.com/profile/jie
http://blogs.itecn.net/blogs/alexis

推荐以 NNTP Bridge 桥接新闻组方式访问论坛以获取最佳用户体验。

本帖是回复帖，原帖作者是楼上的 "21597357"

用的是kis2010，应该能够支持sp3的吧？我现在怀疑是：1.我的显卡驱动不行，因为我没有用光盘自带的显卡驱动，用?氖谴呋??0.7。2.是迅雷或者utorrent破解了连接数导致蓝屏。

举报为违规帖子
回复引用标记为答复

显示全部楼层 · 发表于 2011-1-14 17:11:58

迅雷5.8有重大漏洞为什么不试试迅雷7？

显示全部楼层 · 发表于 2011-1-14 17:14:40

回复 4楼小小梦的帖子

5.8有什么漏洞？可否明示下？我觉得5.8的速度比较快，所以就一直在用这个，如果真的有漏洞，还是用7吧

显示全部楼层 · 发表于 2011-1-14 18:17:08

用迷你迅雷不错。

显示全部楼层 · 发表于 2011-1-14 18:23:18

文章太长了。。友情支持一下。

显示全部楼层 · 发表于 2011-1-15 00:48:46

7232092 发表于 2011-1-14 17:14
回复 4楼小小梦的帖子

5.8有什么漏洞？可否明示下？我觉得5.8的速度比较快，所以就一直在用这个，如果真 ...

你搜索下论坛资讯区的旧闻吧
我之前验证过了
的确迅雷一直没修复
因为迅雷还有5.9 迅雷7
迅雷5.8早就被遗弃了