做过WinCE PB工作的人都知道PB是一个比较长的过程，当前主流台式机一般需要20-40分钟。由于突然一直能够编译成功的笔记本出了问题，
所以我又寄希望于自己的台式机，毕竟台式机cpu和内存都要强大一点点。在使用了几天win7，并经过多次build失败后，又换成了WIN2008。
今天装好了一套WINCE PB的软件后，进行PB立刻就失败了，看了一下log，发现是commdlg.dll can’t find.因为以前曾经失败后又pb成功，所以
有尝试着pb一次，此次pb的错误同样是can't find xxx.dll。可能是由于1.1的影响，我仔细检查了一下log，发现上次出错的地方这次成功编译成功
也即commdlg.dll这个东西并没有出错，也没有can’t find。于是立刻再pb一次，果然这次错误又不同，并且上次出错的地方也成功。于是again，
这一次的编译完全通过。直到最后生成nk.bin的时候发生了错误，错误提示是内核大于了32m，但是没有在环境中设置。虽然没有编译成功，但是
说明我的猜想是正确的，于是将编译类型改为release,并在环境中勾选内核可以大于32m，经过几次不出意料的失败好，PB成功了………………。
2010/01/01 22:30 18,961,379 NK.bin
1 个文件 18,961,379 字节
0 个目录 57,639,759,872 可用字节
BLDDEMO: Test build complete.
Test - 0 error(s), 20 warning(s)
========== 生成: 1 成功或最新，0 失败，0 被跳过 ==========
看到这个消息，这是第一次有发现当pb出现奇怪错误的时候的一个解决方案。网上能搜索到的方案一般为重新装环境…
实际上重新装环境能成功地概率和没有重新装以前是一样的。当然也有很多大牛使用虚拟机，不过不是所有人都能使用虚拟机
而且实际上虚拟机也同样会出现类似的问题。因为我在一次PB成功后，对vm虚拟机作了一个snapshot，可是当后面再编译
失败时返回该snapshot的时候还是编译失败。
总结一下为：如果PB的失败的时候，如果log里面的错误是can’t find xxx的时候，可以尝试再“生成解决方案”，然后
检查错误是否一样，如果不一样，再检查以前的错误点是否已正确通过。如果通过的话，就再build几次吧。可能可以最后成功
并且我这里的经验是如果build成功，那么以后只要不清理方案以后同一solution pb就不会再出问题。
估计的原因：每次build将部分dll编译成功。具体的原因还需要进一步研究。并希望有对付PB无原则失败经验的大牛们指出这种方法能成功
的具体原因，如果纯属巧合，也请不吝赐教。
