另外发现一个问题，就是在64位多核的机器上，程序多次崩溃在 ofstream和owstringstream的构造函数中，尤其是owstringsteam的构造函数崩溃更是不可思议，就是owstringstream oss这样普通的语句，crash点在msvcp80， 不知道是根据windbg dump分析定位有问题还是msvcp80.dll本身真的有问题,不知道有没人碰到过类似的问题。

相信分析过AMD x64位dump的人都知道，比起32位来困难多了，首先函数调用的前4个参数，是通过RCX,RDX,R8,R9寄存器传递的，这样很难从栈里把参数恢复过来，不知道各位有什么高招没有。还有一个问题就是优化后的Release版，用KD或DDS命令看原始栈，可以看到很多已经执行完的函数还在栈里，停留在函数最后一个}这一行，实在是搞不懂为什么会这样。另外一个问题就是ebp寄存器完全不靠谱，和问win2完全不一样。例如在我的一个dump里就出现了这样的情况。00000000`1cf06c28  6a96b368 utilDebug!LogAdaptor::AdjustLogIfChanged+0x288 [utildebug\dbg_ns_debug.cpp @ ...

晕，下午发帖一直显示不成功，没想到都发上来了

在我的安装程序代码里找到了一个TerminateThread， 现在把这个Thread完全禁止后，用自动化测试case测试，到现在为止这个问题没有再出现，所以正如张老师所说的那样，手语的推测是很有道理的。

我在我们的安装程序里找到了有一个地方用到了TerminateThread， 把这个地方禁掉后，用自动测试case测试，到目前为止，这个问题没有出现过，所以正如张老师所说的，手语的推测很有可能是对的。

按照手语的建议，在我们的安装程序里，找到了有一个地方用到了TerminateThread，把这个地方禁掉后，用自动测试的case对安装程序做了几十次测试，到目前为止，这个问题没有出现过了，所以就像张老师说的那样，手语的推测很有可能是对的，非常感谢大家。

比较奇怪的是执行!locks命令发现了另一个loaderlock 0:006> !locks CritSec WLDAP32!LoadLibLock+0 at 76f33250 WaiterWoken No LockCount 0 RecursionCount 1 OwningThread 788 EntryCount 0 ContentionCount 0 *** Locked Scanned 464 critical sections 0:006> dt _RTL_CRITICAL_SECTION ...

张老师您好， 今天又把这个问题重现了一下，用户态的栈是： 2 Id: b5c.788 Suspend: 1 Teb: 7ffd8000 Unfrozen ChildEBP RetAddr Args to Child 00cec3cc 7c827d29 7c83d266 0000023c 00000000 ntdll!KiFastSystemCallRet 00cec3d0 7c83d266 0000023c 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc 00cec40c 7c83d2b1 0000023c 00000004 00000001 ...

张老师，您好，很久没有和您联系过了，因为出了一趟长差昨天刚刚回来上班，今天又发现了这个问题，这次抓到了kernel model的dump，分析了一下，也没发现什么线程异常，由于Critical Section没有kernel mode的对象，请问我该如何着手分析呢？

Hi Raymond， 我已经把memory dump上传我的qq文件中转站去了，我的qq号码是：68615598，不知道你是否使用qq，至于调试符号文件，如果你需要的话，我再上传上去（需要咨询一下领导上传pdb文件是否违反policy）。