用2003的setupldr.bin加载ram盘做XP的一些启动时发现，老是卡死在
“setup is starting windows” 这里，永远也不会恢复。
N天都无果，今天无意中发现，原来是必须是用windows 2003 sp1的setupldr.bin才行。sp2的就不行。
ramdisk.sy_ 倒是好像可以随意。
so, you must use win2k3sp1 ‘s sutupldr.bin to avoid hangs on “setup is starting windows”.
在安装的源盘根目录提供一个winnt.sif，写上：
[SetupData]
OsLoadOptions = “/noguiboot /fastdetect /debug /debugport=com1 /baudrate=115200 /break”
即可。
不过XP的setupldr.bin不支持这个，要win2k3的才行。（推荐sp1。sp2加载ramdisk有卡住bug）
结论非常简单，要先调用 NtInitializeRegistry. 参数见 wrk 中的 ntregapi.h
过程比较复杂，在smss.exe中用bootexecute启动的native程序里，调用 ntsavekey达不到想要的结果。
NtSaveKey会返回0，也就是没有错误。结果文件也会生成，生成的大小看起来也是对的。但是文件里面没有任何内容。所有字节都是0。
调试过程：
1. smss.exe启动的native程序是非常早的，可能是系统还有什么没准备好。试着替换其它程序而不是被smss.exe启动，来看看。
2. 替换winlogon.exe，发现能保存。
3. 替换 csrss.exe，发现也能保存。
4. 由于启动时候，smss创建csrss.exe ，后者再创建winlogon.exe。因此可以知道，在smss.exe调用native exe之后，启动csrss.exe之间，一定发生了什么事，使得ntsavekey在其前不能运行，其后可以运行。
5. 写一个简单的DLL，提供一个函数调用ntsavekey做测试，用lordpe把此DLL添加到smss.exe的依赖里。
6. WINDBG调试smss.exe启动native app后的路径，它每调几个函数就试下DLL中提供的函数看看ntsavekey是否正常。
7. 调试发现，在 NtInitializeRegistry之前，ntsavekey出现异常结果，之后，正常。
8. 结论： NtSaveKey需要用NtInitializeRegistry初始化注册表。
1：使用!process 0 0 获取用户空间的所有的进程的信息
!process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS 80a02a60 Cid: 0002 Peb: 00000000 ParentCid: 0000
DirBase: 00006e05 ObjectTable: 80a03788 TableSize: 150.
Image: System
。。。。。
2：使用.process /p + 你需要断的应用程序的EProcess地址切换到应用程序的地址空间
例如：
.process /p 0x80a02a60
3：重新加载user PDB文件
.reload /f /user
4：使用非侵入式的切换进程空间
.process /i /p 0x80a02a60
5：下应用层断点 bp bu 都可以
原文：http://blog.csdn.net/purplethunder/archive/2009/04/04/4048379.aspx
另外顺便证下在windbg调试时强制调用一个函数：（设函数名是 test_reg）
r esp=esp-4 ; ed esp eip ; r eip = test_reg
vs自带了一个mc.exe的程序，这个东西鲜有人知，它就是windows的message compiler程序。
mc编译mc代码，把它转变了一个bin格式的文件，放到资源中加载。在使用 windows event log , formatmessage的时候，就用得上这个消息了。formatmessage 有一个类似于 printf的形式的格式化能力。不过是用%1,%2这样的字眼，而不是%s,%d。这种%1,%2的形式理适合国际化。
codeproject上有一篇关于message compiler的文章： http://www.codeproject.com/KB/system/mctutorial.aspx
windows kernel有不少地方使用mc格式的文本。比如windows 在安装的时候，提示欢迎，格式化等的文字都来源于安装盘smss.exe的message resource里。
生成的 .bin 文件格式;
binfile = dword x + idgroups[x] + message[]
idgroup = dword startid + dword endid + dword offset_to_message
message = dword sizeof(message) + char text[]
我的WINXP移动版，也就是装在移动硬盘上的XP。在应用到我的新电脑（联想LENOVO G455A M320）时，发生了新的情况。
本来，移动的XP应该是，不论在哪里，插到新电脑上，一用USB启动，就自动进入到系统中，这样我不论在什么地方，都可以使用我原来的系统，最熟悉的系统，不用担心要同步文档配置啥的。而且这个绝对不是WINPE能比的，WINPE能在任何电脑上启动XP，但它只是用于维护和简单的使用。而移动版XP的功能是完整的，跟装在机箱内部硬盘的XP一样的功能。
移动的理想是美好的，现实是，在遇到全新的硬件时，它不一定能启动启来，可能发生BSOD 0x000007b错误。在G455A上就遇到了。
由于这个笔记本没有PCI Express Card接口，无法用我高价买的express 1394卡进行kernel debugging。它也没有串口，无法用串口kernel debuging. XP不支持USB kernel debugging, 就算换到vista或win7, 估计ehci的usb debug port也没有导出（有没有导出纯粹看运气，厂商一般不会故意导出）。总而言之，kernel debugging来诊断为什么从USB移动硬盘上启动不了，是没戏了。只能瞎子乱摸了。
说说最后的成果：
1. HKLM\SYSTEM\MountedDevices下的值 \DosDevice\C: 必须删掉，换了硬件后，后面的二进制可能变了，不删掉此项，可能导致C盘不能挂载，从而发生蓝屏。把此功能加到移动XP的recovery module中。
2. 需要copy安装盘安装时生成的 HKLM\SYSTEM\ControlSet001\Enum\PCI 全目录。由于我在recovery module中copy的是winpe的。跟安装盘的setupldr.bin生成的PCI信息有些差别，导致不能启动。要彻底解决，必须基于安装盘而不是PE重写recovery mode。不过我没有时间搞这玩意儿了。而且接下来可能要研究移动版win7而不是XP了，所以…算了吧。
再说说过程：
由于只能瞎子乱撞的试验，最开始试了很多次都成功不了。后来还是想到，重头再来，在机器上的主硬盘上新装一个全新的XP，先不装驱动，为了省时间，反正能登录进去的XP就行了。然后改注册表重启，使得用winobj看arcnames的时候，可以看到插上电脑的USB移动硬盘的记录。看到后说明，这份COPY的XP已经可以从USB移动硬盘启动。
然后，有了一个成功的版本，也有了一个失败的版本，就让它们不断的逼近吧。这里又出了一个问题：方案上，可以用二分法快速逼近找出问题的关键，也可以用经验为主的方式进行重点排查，我选择了后者，尝试重启若干次，无果。 只好往第一种方法偏，最终发现了1和2这两个结论。少一个也不行。
我以前碰到的电脑，尝试了好多种硬件，都发现只需要COPY WINPE的PCI信息就可以修复成功启动了，但现在这电脑非得要安装时产生的。不知道是不是新硬件搞出的新脾气。
移动版XP以后也没有太大的研究价值了，希望移动版的WIN7会更容易配置。不过VISTA/WIN7的boot配置就够麻烦的了，还是boot.ini来得简洁直观。
我在一些论坛上说移动的操作系统时，总要被人用WIN PE来拍砖。 其实移动OS是用来替换平时工作学习娱乐所用的OS的，跟WINPE主要用于维护是十分的不同。
你需要背着笔记本从家里到公司，或从宿舍到实验室吗，或者带着它从A地出差到B地吗？如果你在两处都有电脑，用移动的OS肯定好过背一台电脑。现代社会在目标地找或借一台电脑已经不难了，背个硬盘相比于背台笔记本，那肯定是爽了很多。
你需要同步在家里电脑和公司电脑上产生的不同的内容吗？如果用了移动的OS，那所有的文档设置和生产出来的文件都已经在移动硬盘上同步了，根本没有合并和版本选择的烦恼。
LINUX是很容易做成移动的OS的，微软则则不知是有意还是无意制造了一些烦恼，让你的WIN不能在移动硬盘上启动任何一台电脑，只是提供了一个用于维护的WINPE。还好XP和WIN7都是可以做成移动系统的。前者我已经成功了，后者，在网上能找到有些人的成功记录，估计应该不会太难实现。待到有空时，再搞个500G的移动硬盘，试试移动WIN7了。
# apt-get install connect-proxy
#!/bin/sh SOCKS5_PASSWD=xxxxxx connect-proxy -S username@host:port $@
chmod +x /usr/bin/my-git-proxy
$ git config --global core.gitproxy "my-git-proxy"