对PEWaitKill和XPEinit -9的请教。

lxl1638

XPEinit -9的目的是Kill两个进程，但过早Kill掉在高速机中出现蓝屏，以往是凭经验作延时处理。
能不能这样：去掉注册表中的XPEinit -9，让WinPE顺利启动到桌面再Kill那两个进程，这样不更可靠更安全？
这样可行的话，就用不着作延时判断，因为要延时多长很难确定，让WinPE顺利启动到桌面再Kill那两个进程。

[ 本帖最后由 lxl1638 于 2006-10-19 11:39 PM 编辑 ]

lxl1638

晕死，一直在线=也没人说，我DDD！！！上去！！

l1982012800

好的........

asbai

呵呵，来了，“顺利启动到桌面” 只能说明 Windows Shell （通常是 Explorer.exe）已经启动并初始化完毕。并不能以此判断 Smss 和 WinLogon 的初始化任务已经结束。

Smss 和 WinLogon 本身是系统关键进程，在设计的时候恐怕没有考虑过要把它们强行 Kill 的情况。所以好像没有任何公开的方法判断它们当前的运行状态。用 Windows Shell 是否已启动来度测恐怕行不通，呵呵。

lxl1638

原帖由 asbai 于 2006-10-20 12:06 AM 发表
呵呵，来了，“顺利启动到桌面” 只能说明 Windows Shell （通常是 Explorer.exe）已经启动并初始化完毕。并不能以此判断 Smss 和 WinLogon 的初始化任务已经结束。

Smss 和 WinLogon 本身是系统关键进程，在设 ...

啊，经大侠指点，还得要延时了，但延时多少很难确定，这样Kill那两个进程必要性就可有可无了。
就算要Kill可靠的方法还是启动到桌面作足够的延时后再Kill。

[ 本帖最后由 lxl1638 于 2006-10-20 12:20 AM 编辑 ]

asbai

原帖由 lxl1638 于 2006-10-20 12:16 AM 发表
啊，经大侠指点，还得要延时了，但延时多少很难确定，这样Kill那两个进程必要性就可有可无了。

呵呵，延迟的绝对安全时间其实不难确定。其值取决于 smss 和 winlogon 完成所有初始化动作所需的最大时间。只要延迟的时间超过了这个值，就算在超高速机器上，xpelogon 的初始化速度为 0 也是安全的了。

lxl1638

问题还有点不明，在超高速机器上smss 和 winlogon 完成所有初始化动作所需的最大时间应比低速机的少，但Kill它们却要延迟去Kill。

asbai

原帖由 lxl1638 于 2006-10-20 12:29 AM 发表
问题还有点不明，在超高速机器上smss 和 winlogon 完成所有初始化动作所需的最大时间应比低速机的少，但Kill它们却要延迟去Kill。

说明 smss 和 winlogon 不是运算密集型应用，系统运算能力提高对他们的性能影响不大，这种情况很常见，比如他们需要阻塞操作、同步、等待网络超时等等。而 xpelogon 所做的都是运算密集型操作，系统运算能力的增强使它的性能大大提高，过早执行到了 -9……

lxl1638

明白了，谢谢大侠！
这样PEWaitKill就不必放在原位置上执行也可以的， Shell 启动并初始化完毕后再执行它也可行，关键是适当的延时后再去Kill那两个该死的进程。

asbai

原帖由 lxl1638 于 2006-10-20 12:42 AM 发表
明白了，谢谢大侠！
这样PEWaitKill就不必放在原位置上执行也可以的， Shell 启动并初始化完毕后再执行它也可行，关键是适当的延时后再去Kill那两个该死的进程。

you got it :)

lxl1638

原帖由 asbai 于 2006-10-20 12:45 AM 发表

you got it :)

之所以这样想，因为不同的机子延时不同，本人想把大侠的PEWaitKill调到外挂中执行，这样就更方便用户调试了修该延迟时间。

asbai

原帖由 lxl1638 于 2006-10-20 12:49 AM 发表

之所以这样想，因为不同的机子延时不同，本人想把大侠的PEWaitKill调到外挂中执行，这样就更方便用户调试了修该延迟时间。

感觉默认的 30s 应该足够了，呵呵

lxl1638

原帖由 asbai 于 2006-10-20 12:52 AM 发表

感觉默认的 30s 应该足够了，呵呵

的确应足够了，但调到外挂也是一种更个性化人性化的方法，因为不少机子无需延时，直接Kill也可以的，象本人这些02、03年的老爷机就是这样。

l1982012800

原帖由 lsjtywkj 于 2006-10-20 08:59 AM 发表
隐约感觉大师们没有真正理解了xpeinit.exe 的用法！！
老九、老毛桃都用过轶微超级系统维护盘吧，这个盘里并没有延时程序，但在P4 2.9G Hz 的机器上不会蓝屏.我不知道P4 2.9G Hz 算不算高速机。

有没有一个程序可以判断WINLOGON已经初始化结束的

lxl1638

原帖由 lsjtywkj 于 2006-10-20 08:59 AM 发表
隐约感觉大师们没有真正理解了xpeinit.exe 的用法！！
老九、老毛桃都用过轶微超级系统维护盘吧，这个盘里并没有延时程序，但在P4 2.9G Hz 的机器上不会蓝屏.我不知道P4 2.9G Hz 算不算高速机。

老九、老毛桃对轶微超级系统维护盘中的WinPE最了解的，如果认第二，没人敢说第一。

Rinrin

不好意思
来晚了
平时要上班

我个人认为
应该着重搞清为什么会蓝屏
答案不应该仅仅是未初始化完成
要搞清楚到底在哪一步导致蓝屏

这两天我会研究这个问题
当然，如果问题无法在我这里复现那也没有办法了

PS：
想问一下BaiY兄是怎么调试确认的

lxl1638

嘿嘿，期待呢。
无忧牛人多啊，对WinPE的研究并不比911的差。

老毛桃

原帖由 lxl1638 于 2006-10-20 19:54 发表
嘿嘿，期待呢。
无忧牛人多啊，对WinPE的研究并不比911的差。

嘿嘿，那是！

而且都是纯正的中文版的啊！

偶就在一旁偷着乐，凿壁偷光了。。。。

lxl1638

对于PEWaitKill，本想简化一下它，就是把它放到启动组执行(内置外置都可以)，延迟一定时间后再创建一个
XPEinit -9 的进程，将Kill任务交 XPEinit 来做，这样 PEWaitKill 可以更简，Kill任务更可靠，免得以后 XPEinit
更新涉及到 XPEinit -9 的功能有变化时又要去改PEWaitKill。

asbai

原帖由 Rinrin 于 2006-10-20 07:45 PM 发表
PS：
想问一下BaiY兄是怎么调试确认的 ...

这个感觉在这两天发的帖子里应该都说了，呵呵。

首先最重要的证据是实测，我有台机器每次启动必蓝屏，后来看到其它兄台的延迟法判断是进程间同步的时序问题。NT Kernel 的同步和互斥机制已经很稳定了，所以怀疑是 PE 里后加入的组件跟某个系统进程间有问题。

然后 down 了一份 xpe 的源码看了一下，竟然有个参数是用来 kill 系统关键进程的（因为怀疑是同步问题，kill 进程的函数又叫 unlockResources，所以立刻就被揪出来了，呵呵）。

我们知道，smss 和 winlogon 在初始化过程中的主要任务之一是初始化系统服务管理器，并装入类型为 SERVICE_SYSTEM_START 和 SERVICE_AUTO_START 的服务和驱动（其中 SERVICE_SYSTEM_START 由 smss 直接加载）。延迟方案解决的 0x71 错误和这一步有直接关系。

至此基本可以确定在高速机器上 xpelogon 执行初始化速度过快，以至在 smss 未能初始化完毕所有服务前被强行 Kill，导致系统初始化失败。

这个结论很容易验证，删除 xpeinit -9 启动项后问题解决（为此俺反复验证了 2 次，呵呵）。

Rinrin

原帖由 asbai 于 2006-10-20 09:34 PM 发表

这个感觉在这两天发的帖子里应该都说了，呵呵。

首先最重要的证据是实测，我有台机器每次启动必蓝屏，后来看到其它兄台的延迟法判断是进程间同步的时序问题。NT Kernel 的同步和互斥机制已经很稳定了，所以怀 ...

很遗憾
我的机器怎么搞都不蓝屏
只好找些资料充数了
Mark的Windows Internals里写道：
The last step is to create the Session Manager subsystem (Smss) process (introduced in Chapter 2). Smss is responsible for creating the user-mode environment that provides the visible interface to Windows—its initialization steps are covered in the next section.

The progress bar is (finally) set to 100%.

As a final step before considering the executive and kernel initialization complete, the phase 1 initialization thread waits for the handle to the Session Manager process with a timeout value of 5 seconds. If the Session Manager process exits before the 5 seconds elapse, the system crashes itself with a SESSION5_ INITIALIZATION_FAILED bug check code.

If the 5-second wait times out (that is, if 5 seconds elapse), the Session Manager is assumed to have started successfully, and the phase 1 initialization function calls the memory manager's zero page thread function (explained in Chapter 7). Thus, this system thread becomes the zero page thread for the remainder of the life of the system.

SESSION5_ INITIALIZATION_FAILED即是0x71错误

asbai

原帖由 Rinrin 于 2006-10-20 11:31 PM 发表

As a final step before considering the executive and kernel initialization complete, the phase 1 initialization thread waits for the handle to the Session Manager process with a timeout value of 5 seconds. If the Session Manager process exits before the 5 seconds elapse, the system crashes itself with a SESSION5_ INITIALIZATION_FAILED bug check code.

Mark 大牛说的没错，不过引起 0x71 错误的原因是很多的，mark 说的这个只是其中之一（他老自己也没说这是71错误的唯一原因嘛）。有关 smss 都做了哪些事情，以及71错误的详细指南，在微软的 technet 上很容易找到。:P

Rinrin

原帖由 asbai 于 2006-10-21 05:06 PM 发表


Mark 大牛说的没错，不过引起 0x71 错误的原因是很多的，mark 说的这个只是其中之一（他老自己也没说这是71错误的唯一原因嘛）。有关 smss 都做了哪些事情，以及71错误的详细指南，在微软的 technet 上很容易 ...

确实有可能
asbai兄用Windbg调试过吗？
内存dump文件能不能发出来？

asbai

原帖由 Rinrin 于 2006-10-21 07:56 PM 发表

确实有可能
asbai兄用Windbg调试过吗？
内存dump文件能不能发出来？

这个。。。。在 pe 环境下 setup 一个 kernel mode debugger 好像太麻烦了，呵呵。再说不配调试环境也把问题解决了。不知道 rinrin 兄要 context dump 是想看什么：
1. 蓝屏问题是不是 kill smss 引起的（这个我觉得前面的黑箱测试就基本可以肯定了）。
2. 想知道出了哪类问题（有充分的理由认为是同步时序问题）。
3. 想看看究竟是在 smss 执行到了哪一步出现问题：这个我觉得就算抓出上下文 dump 也比较困难。首先没有源码，仅凭一些符号信息和 callback stack 很难说明什么。其次，定位故障点没太大意义，kill smss 导致 0x71 蓝屏问题的故障点肯定不止一处，比较可能的情况是在 smss 开始初始化到它的初始化工作结束之间的任意一点 kill 它都会导致 0x71 蓝屏问题。在同一台机器上每次出现蓝屏可能都是不同的点，这种分析方式没什么明显的作用。
:lol

[ 本帖最后由 asbai 于 2006-10-21 08:33 PM 编辑 ]