Chinaunix

标题: XP无法正常关机和重启 [打印本页]

作者: 东方蜘蛛 时间: 2010-04-08 23:22
标题: XP无法正常关机和重启
关机和重启时就停在最后的屏幕不动了，只能强制压电源按钮关机了，系统日志如下，请大侠们帮忙看看是什么原因啊？谢谢！

Time<2010,04.08.,22:38:36> : ReadLastUpdate32:<g_UpdatingList.Save> after remove_all items. return code = 0
Time<2010,04.08.,22:38:37> : ------------service_ctrl:SERVICE CONTROL SHUTDOWN------------
Time<2010,04.08.,22:38:37> : CheckTimeOut_shutdown:Update <0> Reg files
Time<2010,04.08.,22:38:43> : ------------service_ctrl:SERVICE CONTROL SHUTDOWN<CheckTimeOut_shutdown>------------
Time<2010,04.08.,22:38:43> : ------------service_ctrl:SERVICE CONTROL SHUTDOWN<CheckTimeOut_shutdown>------------
Time<2010,04.08.,22:41:12> :  start main( __argc, __argv );

Time<2010,04.08.,22:41:12> : enter main function.

Time<2010,04.08.,22:41:12> : Now start services dispatch

Time<2010,04.08.,22:41:12> : Now start services dispatch

Time<2010,04.08.,22:41:12> : Start Pending, before servicestart.

Time<2010,04.08.,22:41:12> :  Report Service running in ServiceStart.

Time<2010,04.08.,22:41:12> :  Report Service running in ServiceStart.

Time<2010,04.08.,22:41:12> : OOBE flag has already been set at ..\TvTuMon\Parameters.
Time<2010,04.08.,22:41:54> : ------------ServiceStart:SERVICE START------------
Time<2010,04.08.,22:41:54> : ReadLastAutoUpdate32 g_cKerFileDigests.Save() return -100

Time<2010,04.08.,22:41:54> : ReadLastUpdate32:<g_cKerFileDigests.Save>  return code = -100
Time<2010,04.08.,22:41:55> : ReadLastUpdate32:<g_UpdatingList.Save> after remove_all items. return code = 0
Time<2010,04.08.,22:52:56> : ReadLastUpdate32:<g_UpdatingList.Save> after remove_all items. return code = 0
Time<2010,04.08.,22:52:56> : ------------service_ctrl:SERVICE CONTROL SHUTDOWN------------
Time<2010,04.08.,22:52:56> : CheckTimeOut_shutdown:Update <0> Reg files
Time<2010,04.08.,22:52:56> : ------------service_ctrl:SERVICE CONTROL SHUTDOWN<CheckTimeOut_shutdown>------------
Time<2010,04.08.,22:52:56> : ------------service_ctrl:SERVICE CONTROL SHUTDOWN<CheckTimeOut_shutdown>------------
Time<2010,04.08.,22:56:15> :  start main( __argc, __argv );

Time<2010,04.08.,22:56:15> : enter main function.

Time<2010,04.08.,22:56:15> : Now start services dispatch

Time<2010,04.08.,22:56:15> : Now start services dispatch

Time<2010,04.08.,22:56:15> : Start Pending, before servicestart.

Time<2010,04.08.,22:56:15> :  Report Service running in ServiceStart.

Time<2010,04.08.,22:56:15> :  Report Service running in ServiceStart.

Time<2010,04.08.,22:56:15> : OOBE flag has already been set at ..\TvTuMon\Parameters.
Time<2010,04.08.,22:56:59> : ------------ServiceStart:SERVICE START------------
Time<2010,04.08.,22:56:59> : ReadLastAutoUpdate32 g_cKerFileDigests.Save() return -100

Time<2010,04.08.,22:56:59> : ReadLastUpdate32:<g_cKerFileDigests.Save>  return code = -100
Time<2010,04.08.,22:57:00> : ReadLastUpdate32:<g_UpdatingList.Save> after remove_all items. return code = 0

作者: emperor 时间: 2010-04-09 10:47
thinkpad 吧
两个工具:
1.windbg工具 ---找出相关文件
2.微软官网的的Procmon.exe ---找出相关进程...........

作者: 东方蜘蛛 时间: 2010-04-09 13:55
windbg使用的前提是要有C:\WINDOWS\Minidump下的dump文件生成才行的吧？我的xp没有生成dump文件，甚至没有Minidump目录

作者: 东方蜘蛛 时间: 2010-04-09 14:09
Procmon.exe 我已经下下来了，怎么找相关进程，请不吝指教，谢谢

作者: emperor 时间: 2010-04-09 14:10
那就procmon吧。。。。。。。

作者: emperor 时间: 2010-04-09 14:20

Procmon.exe 我已经下下来了，怎么找相关进程，请不吝指教，谢谢
东方蜘蛛发表于 2010-04-09 14:09

直接运行procmon.exe然后设置log文件地址，然后直接关机。生成log后，用procmon来看log文件，你这个情况可以看最后的时间都是哪些进程在跑，找失败了进程，应该比较容易找到的
另外minidump，如果你的系统有问题了，应该有这个dump的，你可以根据下面的提示换个路径看看。
http://support.microsoft.com/kb/315263

作者: emperor 时间: 2010-04-09 14:34
如果实在没有minidump生成的话，基本排除是系统的问题。也就是说很可能是什么软件导致的冲突等等原因，这样只能从分析过滤procmon的log来分析了
其实最傻瓜的方式是你知道你在出现这种情况之前你对你的xp做了什么

。。。。。。

作者: 东方蜘蛛 时间: 2010-04-09 14:57
新买的x200，新装的xp，新装了些日常工作软件，用的金山毒霸，系统这两天在不停的更新补丁。。。。

刚才在procmon里面选了enable booting log后重启主机，到关机界面又是不动了，再次压了电源按钮后，再刚登录系统就来了个蓝屏，再重启，再蓝屏，如此4次，总算进来了。。。。。。

作者: emperor 时间: 2010-04-09 15:11
都蓝屏了还没有minidump。。。。。要不把金山干掉吧，那个东西实在不敢恭维。。。。。。

作者: 东方蜘蛛 时间: 2010-04-09 15:15
金山毒霸我以前一直都在用的，还行吧，支持国货嘛，蓝屏重启后生成了4个dump文件，我把4次的!analyze -v信息给你贴出来，你帮忙看下，偶是看不懂了

第四次的－Mini040910-04.dmp

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8053ba1e, The address that the exception occurred at
Arg3: a789cbf0, Trap Frame
Arg4: 00000000

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

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

FAULTING_IP:
nt!memmove+16e
8053ba1e 8807          mov    byte ptr [edi],al

TRAP_FRAME:  a789cbf0 -- (.trap 0xffffffffa789cbf0)
ErrCode = 00000002
eax=a789cc5c ebx=00000000 ecx=00000000 edx=00000002 esi=a789ccb4 edi=00000000
eip=8053ba1e esp=a789cc64 ebp=a789cc6c iopl=0       nv up ei ng nz ac po cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000          efl=00010293
nt!memmove+0x16e:
8053ba1e 8807          mov    byte ptr [edi],al       ds:0023:00000000=??
Resetting default scope

CUSTOMER_CRASH_COUNT:  4

DEFAULT_BUCKET_ID:  COMMON_SYSTEM_FAULT

BUGCHECK_STR:  0x8E

PROCESS_NAME:  tvt_reg_monitor

LAST_CONTROL_TRANSFER:  from 8052cb27 to 8053ba1e

STACK_TEXT:
a789cc6c 8052cb27 00000000 a789ccb4 00000002 nt!memmove+0x16e
a789cc8c ba10bac0 892dbbb8 00000002 a733dcbd nt!RtlAppendUnicodeStringToString+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
a789cce0 ba10bbe4 00000040 8910ad50 a789cd1c PROCMON20+0x3ac0
a789ccfc ba10c73a 00000001 000000f8 00000000 PROCMON20+0x3be4
a789cd2c ba10c7c3 00000000 00020019 000000f8 PROCMON20+0x473a
a789cd50 8054263c 007362bc 00020019 0182fc98 PROCMON20+0x47c3
a789cd50 7c92e514 007362bc 00020019 0182fc98 nt!KiFastCallEntry+0xfc
0182fcd8 00000000 00000000 00000000 00000000 0x7c92e514

STACK_COMMAND:  kb

FOLLOWUP_IP:
PROCMON20+3ac0
ba10bac0 ??             ???

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  PROCMON20+3ac0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: PROCMON20

IMAGE_NAME:  PROCMON20.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4aeb76fe

FAILURE_BUCKET_ID:  0x8E_PROCMON20+3ac0

BUCKET_ID:  0x8E_PROCMON20+3ac0

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

作者: 东方蜘蛛 时间: 2010-04-09 15:18
第三次的－－Mini040910-03.dmp

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8053ba1e, The address that the exception occurred at
Arg3: a7a90bf0, Trap Frame
Arg4: 00000000

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

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

FAULTING_IP:
nt!memmove+16e
8053ba1e 8807          mov    byte ptr [edi],al

TRAP_FRAME:  a7a90bf0 -- (.trap 0xffffffffa7a90bf0)
ErrCode = 00000002
eax=a7a90c5c ebx=00000000 ecx=00000000 edx=00000002 esi=a7a90cb4 edi=00000000
eip=8053ba1e esp=a7a90c64 ebp=a7a90c6c iopl=0       nv up ei ng nz ac po cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000          efl=00010293
nt!memmove+0x16e:
8053ba1e 8807          mov    byte ptr [edi],al       ds:0023:00000000=??
Resetting default scope

CUSTOMER_CRASH_COUNT:  3

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

PROCESS_NAME:  tvt_reg_monitor

LAST_CONTROL_TRANSFER:  from 8052cb27 to 8053ba1e

STACK_TEXT:
a7a90c6c 8052cb27 00000000 a7a90cb4 00000002 nt!memmove+0x16e
a7a90c8c ba10bac0 89ebac68 00000002 a7131cb0 nt!RtlAppendUnicodeStringToString+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
a7a90ce0 ba10bbe4 00000040 86328de0 a7a90d1c PROCMON20+0x3ac0
a7a90cfc ba10c73a 00000001 000000f8 00000000 PROCMON20+0x3be4
a7a90d2c ba10c7c3 00000000 00020019 000000f8 PROCMON20+0x473a
a7a90d50 8054263c 007362bc 00020019 0182fc98 PROCMON20+0x47c3
a7a90d50 7c92e514 007362bc 00020019 0182fc98 nt!KiFastCallEntry+0xfc
0182fcd8 00000000 00000000 00000000 00000000 0x7c92e514

STACK_COMMAND:  kb

FOLLOWUP_IP:
PROCMON20+3ac0
ba10bac0 ??             ???

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  PROCMON20+3ac0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: PROCMON20

IMAGE_NAME:  PROCMON20.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4aeb76fe

FAILURE_BUCKET_ID:  0x8E_PROCMON20+3ac0

BUCKET_ID:  0x8E_PROCMON20+3ac0

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

作者: 东方蜘蛛 时间: 2010-04-09 15:22
第二次的－－－Mini040910-02.dmp

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8053ba1e, The address that the exception occurred at
Arg3: a7bb4bf0, Trap Frame
Arg4: 00000000

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

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

FAULTING_IP:
nt!memmove+16e
8053ba1e 8807          mov    byte ptr [edi],al

TRAP_FRAME:  a7bb4bf0 -- (.trap 0xffffffffa7bb4bf0)
ErrCode = 00000002
eax=a7bb4c5c ebx=00000000 ecx=00000000 edx=00000002 esi=a7bb4cb4 edi=00000000
eip=8053ba1e esp=a7bb4c64 ebp=a7bb4c6c iopl=0       nv up ei ng nz ac po cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000          efl=00010293
nt!memmove+0x16e:
8053ba1e 8807          mov    byte ptr [edi],al       ds:0023:00000000=??
Resetting default scope

CUSTOMER_CRASH_COUNT:  2

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

PROCESS_NAME:  tvt_reg_monitor

LAST_CONTROL_TRANSFER:  from 8052cb27 to 8053ba1e

STACK_TEXT:
a7bb4c6c 8052cb27 00000000 a7bb4cb4 00000002 nt!memmove+0x16e
a7bb4c8c ba10bac0 88eba228 00000002 a7015cf7 nt!RtlAppendUnicodeStringToString+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
a7bb4ce0 ba10bbe4 0000002a 88e13780 a7bb4d1c PROCMON20+0x3ac0
a7bb4cfc ba10c73a 00000001 000000f8 00000000 PROCMON20+0x3be4
a7bb4d2c ba10c7c3 00000000 00020019 000000f8 PROCMON20+0x473a
a7bb4d50 8054263c 00736cb4 00020019 0192fc98 PROCMON20+0x47c3
a7bb4d50 7c92e514 00736cb4 00020019 0192fc98 nt!KiFastCallEntry+0xfc
0192fcd8 00000000 00000000 00000000 00000000 0x7c92e514

STACK_COMMAND:  kb

FOLLOWUP_IP:
PROCMON20+3ac0
ba10bac0 ??             ???

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  PROCMON20+3ac0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: PROCMON20

IMAGE_NAME:  PROCMON20.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4aeb76fe

FAILURE_BUCKET_ID:  0x8E_PROCMON20+3ac0

BUCKET_ID:  0x8E_PROCMON20+3ac0

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

作者: 东方蜘蛛 时间: 2010-04-09 15:25
第一次的－－－Mini040910-01.dmp

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8053ba1e, The address that the exception occurred at
Arg3: a7858bf0, Trap Frame
Arg4: 00000000

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

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

FAULTING_IP:
nt!memmove+16e
8053ba1e 8807          mov    byte ptr [edi],al

TRAP_FRAME:  a7858bf0 -- (.trap 0xffffffffa7858bf0)
ErrCode = 00000002
eax=a7858c5c ebx=00000000 ecx=00000000 edx=00000002 esi=a7858cb4 edi=00000000
eip=8053ba1e esp=a7858c64 ebp=a7858c6c iopl=0       nv up ei ng nz ac po cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000          efl=00010293
nt!memmove+0x16e:
8053ba1e 8807          mov    byte ptr [edi],al       ds:0023:00000000=??
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

PROCESS_NAME:  tvt_reg_monitor

LAST_CONTROL_TRANSFER:  from 8052cb27 to 8053ba1e

STACK_TEXT:
a7858c6c 8052cb27 00000000 a7858cb4 00000002 nt!memmove+0x16e
a7858c8c ba10bac0 8a4e9cd8 00000002 a73f9cbf nt!RtlAppendUnicodeStringToString+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
a7858ce0 ba10bbe4 0000002a 892e30d8 a7858d1c PROCMON20+0x3ac0
a7858cfc ba10c73a 00000001 000000f8 00000000 PROCMON20+0x3be4
a7858d2c ba10c7c3 00000000 00020019 000000f8 PROCMON20+0x473a
a7858d50 8054263c 00736934 00020019 01d2fc98 PROCMON20+0x47c3
a7858d50 7c92e514 00736934 00020019 01d2fc98 nt!KiFastCallEntry+0xfc
01d2fcd8 00000000 00000000 00000000 00000000 0x7c92e514

STACK_COMMAND:  kb

FOLLOWUP_IP:
PROCMON20+3ac0
ba10bac0 ??             ???

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  PROCMON20+3ac0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: PROCMON20

IMAGE_NAME:  PROCMON20.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4aeb76fe

FAILURE_BUCKET_ID:  0x8E_PROCMON20+3ac0

BUCKET_ID:  0x8E_PROCMON20+3ac0

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

作者: 东方蜘蛛 时间: 2010-04-09 15:26
我好像能看出点端倪了，是不是这个导致的：PROCESS_NAME: tvt_reg_monitor

名称：tvt_reg_monitor_svc.exe
可信认证：安全
PID：820
路径：c:\Program Files\Common Files\Lenovo\tvt_reg_monitor_svc.exe
描述：IBM ThinkPad 笔记本电脑注册表监控服务(Registry Monitor Service)相关进程。

难道这个有问题？

作者: 东方蜘蛛 时间: 2010-04-09 15:29
我看了启动项里面了，好像没有这个进程的启动项哦？

作者: emperor 时间: 2010-04-09 15:33

procmon导致蓝屏？要么你还是直接跑procmon收集点日志看吧，别整boot mode了，就滤32bit的架构。。。。。。。。。。

作者: 东方蜘蛛 时间: 2010-04-09 15:49
在服务里面把tvt_reg_monitor_svc.exe停掉了，但是重启还是老样子。。。。怎么用procmon收集日志啊。。。。

作者: emperor 时间: 2010-04-09 15:52
打开procmon，出现过滤界面，我建议你过滤下金山的进程，然后apply再然后点那个save就ok了。。。。。

作者: emperor 时间: 2010-04-09 16:11
这个文档比较短,但基本够用了........

procmon.chm

59.23 KB, 下载次数: 44

作者: 东方蜘蛛 时间: 2010-04-09 16:22
怎么看logfile啊？

作者: emperor 时间: 2010-04-09 16:38
- -| OK, 放弃procmon...
这么来:
开始-->运行-->msconfig-->启动-->全部禁用.-->确定,重启
如果关机顺利 -->回到msconfig -->慢慢勾选.....................

作者: 东方蜘蛛 时间: 2010-04-09 18:43

还是不行。。。。

作者: emperor 时间: 2010-04-09 20:19

还是不行。。。。
东方蜘蛛发表于 2010-04-09 18:43

1。我想确认一下：a.你禁用所有启动后，重启。然后再关机，还是关不了？ --如果的确如此，比较汗。。。
b.你的xp是SP3补丁吗
2。如果还关不了的话，按照下面的链接，碰碰运气吧。。。。。。。
http://aumha.org/win5/a/shtdwnxp.php

3。如果第二条的运气不佳，暂时卸掉金山看看
4。如果金山卸掉仍然如此，那么就把lenovo的自带的乱七八糟的软件卸掉吧，除了指纹鉴别。
5。如果以上还不行，还。。。。。。

作者: 东方蜘蛛 时间: 2010-04-12 22:16
禁用所有启动项，再关机，启动后，还是不选任何启动项，还是无法正常关机或重启，XP我更新到SP3。。。实在无奈了，等过两天重新恢复下，把自动更新关了，我怀疑是补丁跟新出问题了

作者: emperor 时间: 2010-04-13 10:01
本帖最后由 emperor 于 2010-04-13 10:09 编辑

禁用所有启动项，再关机，启动后，还是不选任何启动项，还是无法正常关机或重启，XP我更新到SP3。。。实在无 ...
东方蜘蛛发表于 2010-04-12 22:16

这样的话，应该是windows在关机的时候触发了什么服务或者是存在一个windows无法关闭的程序导致。你下面的这个工具优化一下系统看看会不会改善
http://www.iobit.com/advancedwindowscareper.html
未果的话，用下面的这个工具给注册表打扫一下
http://www.piriform.com/ccleaner

作者: h0571z05711 时间: 2010-04-13 12:42
搞这么复杂，我目前电脑也有这个问题。
我找了下估计是我装的这个xp出问题了，难得换。

作者: shaver 时间: 2010-04-13 13:41
1、hijackthis,看看有没有什么不该启动的东西。
2、事件查看器，有没有关机时报错的事件日志？

楼主真是unix用的多了，叙述问题让人感觉不像是用xp,呵呵

作者: x9x9 时间: 2010-04-13 14:38
看下系统版本，是sp2还是sp3版本？

作者: yingfengstart 时间: 2010-04-13 16:37
换个系统咯

作者: cobranail 时间: 2010-04-13 19:49
哎，分析个毛啊，直接重装，省时省心。

作者: jnbxzl0200157 时间: 2011-09-05 17:27
这个好复杂~帖子太长，没重点~~~~~~~~~~

作者: renxiao2003 时间: 2012-03-22 11:08
日志是从哪看到的，楼主。

作者: 流氓无产者 时间: 2012-06-20 09:16
首先，你要把启动改成debug版本，真晕啊

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)