COM组件停止响应简单分析，还没有答案？

    今天这边的系统又停止响应了，图形不能浏览。远程怎么折腾也没有找出原因来，后来没办法了，两位同事去了趟机房，发现有一台服务器上perl.exe起了数十个，完全堵死了。后来手工杀进程虽然把这些perl清理掉了，但是还是无法访问。我想起原来曾经遇到过的一个问题，不过那是图形定位查询一直没有返回，最后查出原因是一个COM组件没有响应了，也不知道是组件不能创建对象还是调用对象的方法失败。最后把组件的dllhost.exe杀掉重新启动就好了。
    这边IMS的请求发给IIS后，IIS创建一个perl进程来处理这个请求，perl进程查找可用的管道(pipe)，然后通过管道连接到IMS的一个实例，接下来发送命令执行操作，最后结果也通过管道返回，然后把结果交给IIS，进程退出。这就是CGI模式的请求处理过程。perl在处理某些请求的时候还需要用到一个COM组件来确定区县列表，这个组件除了访问一个定义区县界线的数据文件外不需要访问其他资源了。我突然想起昨天组件的作者说，这个组件还会写日志，会不会出现死锁，两个对象同时想往文件中写内容。
    这个组件是用VB 6写的，也就是说是一个STA模式的COM组件，但是调用该组件的perl是一个个独立的进程，虽然一个进程中只有一个线程能访问这个组件，但是不同的进程没有这样的限制。其实也不是这么回事，同时只允许一个进程进入STA套间，如果一个进程创建多个套间是可以有多个线程，不过即便这样也是进入不同的套间。所以组件内部的资源竞争可以排除，应该是在竞争外部资源。
    此外还有一件事情，因为这是一个STA组件，所以无法使用组件池来限制实例个数。后来另一个同事不知道用什么技术来限制了进程个数。现在组件放在组件管理器中，通过另外一个组件限制对象个数。症状就是服务器上启动了很多的perl，但是IMS那边不是很忙，肯定是在等待什么东西或者出现死锁。
    如果是写日志冲突的话，VB会打开日志文件就出错，难道他没有做错误处理，于是VB弹出一个错误对话框，可是在那里面又不显示，于是也看不到，这样就把它堵死了。可是这样会让整个组件失去响应吗，顶多堵死一个组件而已？如果在IIS中因为只创建一个套间，堵死一个进程，整个IIS都无法访问这个组件了。但是perl是一个个独立的进程，难道一个个全部堵死在那里，最后所有的组件全部被堵死，因为这种症状的确需要很久才会出来。
    我有什么办法知道，这个进程在干什么，在等待什么？Windbg可以告诉我答案，可惜我对这个玩意不是很熟悉，看来得好好学习一下这个玩意。
    假如是这样的原因，那么还有别的办法可以验证吗呢？第一个办法是找它，是不是在写日志的地方有错误处理。