我的任务是将旧的ASP应用程序从Windows 2003服务器（x86）移植到运行IIS 7.5的Windows 2008R2服务器
许多事情需要改变（主要与registry访问有关），但是我偶然发现了一个我无法以令人满意的方式解决的问题。
该应用程序使用外部COM对象（进程内DLL）。 它将在login阶段创build该对象的实例，并将其存储为会话variables。
这个工作相当不错，在我的testing中运行良好，但是当我将它部署到第一台生产服务器上时，当用户尝试login时，我开始出现随机的“500”错误。错误实际上并不一致，所以我使用procmon跟踪问题的来源，得到这个：当用户试图访问该网站时，IIS工作进程尝试打开承载COM对象的Dll，但失败并出现拒绝访问错误。
现在，我不明白这一点：Web应用程序使用服务帐户访问本地资源。 该服务帐户对该COM库所在的目录具有明确的权限。 然而，该文件的访问仍然被拒绝。
我通过给予“每个人”明确的读取和执行访问的DLL，并（似乎）已经解决了问题“解决”的问题。
但我不知道为什么。
最奇怪的是，我使用本地pipe理员帐户连接到网页一次（和一次），然后问题是固定的，只要应用程序没有回收。
如果有人能够在这个问题上提出一些看法，我将不胜感激。 我可以忍受这个问题，但我真的很想明白。
编辑为了澄清：该网站不设置为模拟连接用户。 实际上，唯一启用的authenticationscheme是“匿名authentication”。 但是，基本设置被设置为使用服务帐户。
编辑拒绝访问期间由procmon报告的身份是“IIS APPPOOL \（应用程序名称）”
我想你已经回答了你自己的问题。
您的networking应用程序已configuration为模拟经过身份validation的用户。
当请求被接受时，处理请求的线程被赋予被authentication的用户的标记，然后该标识被该线程的所有操作使用，直到请求终止。
COM对象只需要加载一次，Admins基本上可以读取任何文件，所以作为Admin的第一个请求能够：a）读取文件并且b）将其加载到进程地址空间中。 这通常不需要重复发生：一旦DLL在内存中，它就在那里。
如果普通用户（或匿名用户）进行身份validation和模拟，他们没有权限打开该文件，ProcMon应该告诉你，以及正在使用的身份。 （默认情况下：匿名请求的IUSR）。
您所描述的“服务帐户”位听起来像是工作进程标识。 他们只是用来启动应用程序池，读取configuration，然后坐在做与请求*没有直接关系的东西。
*除非您使用App Pool帐户作为匿名用户帐户，并且除非冒充用户的线程无法获得离线（即需要委派），在这种情况下，将使用App Pool帐户。