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

thinkpad 吧
两个工具:
1.windbg工具  ---找出相关文件
2.微软官网的的Procmon.exe ---找出相关进程...........

东方蜘蛛

windbg使用的前提是要有C:\WINDOWS\Minidump下的dump文件生成才行的吧？我的xp没有生成dump文件，甚至没有Minidump目录

东方蜘蛛

Procmon.exe 我已经下下来了，怎么找相关进程，请不吝指教，谢谢

emperor

那就procmon吧。。。。。。。

emperor

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

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

emperor

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

东方蜘蛛

新买的x200，新装的xp，新装了些日常工作软件，用的金山毒霸，系统这两天在不停的更新补丁。。。。


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

emperor

都蓝屏了还没有minidump。。。。。要不把金山干掉吧，那个东西实在不敢恭维。。。。。。

东方蜘蛛

金山毒霸我以前一直都在用的，还行吧，支持国货嘛，蓝屏重启后生成了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
---------