症状
公司一台数据库服务器上部署了IIS网站(IIS7)，利用Sql Server Analysis Services的msmdpump.dll组件，实现了通过HTTP层来访问Analysis Services(MSAS不支持HTTP远程访问，非HTTP的远程访问也一直没成功过)。运行状况一直良好，最近突然罢工。Debug发现在建立连接的时候总是抛出“The Connection either timed out or was lost”。
诊断
尝试用企业管理器直接连接Analysis Services，成功，数据访问也正常，说明Analysis Services服务运作正常。那看来问题是出在了IIS这一层。
直接在浏览器中通过http://machinename/olap/msmdpump.dll去访问的时候，会弹出一个保存文件的对话框。正常情况下，服务器会返回500，因为没有数据输入。现在弹出保存文件的对话框，说明IIS把这个dll资源当作一个普通文件来对待了，而不是调用ISAPI处理器来处理。
细看了网站的配置，似乎没有问题，重新部署了一个网站，重新配置了ISAPI处理器映射，问题依旧出现。
自己探索了很久，未果，Google了很久，一篇文章(IIS7 – Running 32-bit and 64-bit ASP.NET versions at the same time on different worker processes)提醒了我。这篇文章讲的是如何在不同的应用程序池进程上同时使用32位和64位的Asp.Net。
公司服务器出于性能考虑，用了64位系统。相应的msmdpump.dll文件也是64位的，但IIS的应用程序池进程是多少位的，我倒还真没考虑过。任务管理器一看，只有一个"w3wp.exe * 32”，果然是32位的。那问题的原因应该是，32位的应用程序池无法加载64位的Isapi处理器。
知道了问题所在，解决方法也很简单，启动一个64位的应用程序池就行了。打开应用程序池的高级设置，找到了“启用32位应用程序(enable32bitAppOnWin64)”的设置，将其从原来的True改成False(默认值为False)。这个选项的作用就是允许在64位操作系统上，以32位的应用程序池去加载32位的程序。
之所以会突然出现这个问题，是因为IIS的机器配置文件ApplicationHost.config文件中，全局应用程序池的enable32bitAppOnWin64默认值被意外修改为True。而我部署的IIS网站，由于没有显式设置此选项，因此会继承ApplicationHost.config文件中的默认值。
