我们有一个使用Forms Auth的ASP.NET应用程序。用户登录时，会生成一个会话ID cookie和Forms Auth票证（存储为cookie）。这些是会话cookie而不是永久cookie。当浏览器关闭时，用户被有效地注销是故意且可取的。
一旦用户登录，将使用
最近，我们有许多客户（都使用IE8的最新版本）抱怨说，当他们登录时，初始弹出窗口会将他们带回到登录屏幕，而不是主页。或者，用户有时可以登录，进入主页（再次，在新的弹出窗口中），一切看起来都很好，直到创建任何其他弹出窗口，它就开始将其重定向到登录屏幕。
在试图解决问题时，我使用了老式的Fiddler。当问题开始显现时，我注意到浏览器没有发送ASP.NET会话ID会话cookie或Forms Auth票证会话cookie，即使登录POST的响应明显推送这些cookie。
更奇怪的是，如果我使用CTRL+N从缺少会话cookie的弹出窗口打开一个新窗口，然后手动键入主页的URL，这些cookie就会神奇地再次出现。但是，后续的
需要注意的是，有时，似乎没有什么好的理由，那些相同的用户突然可以正常登录并工作一段时间，然后回到损坏状态。
现在，我确保没有浏览器附加组件、插件、工具栏等在运行。我已将我们的站点添加为可信站点，并将安全设置降低到最低。我已修改了Cookie隐私策略以“接受所有”并禁用了自动策略设置，手动强制它接受所有内容并包括会话cookie。似乎没有任何影响。
一旦用户登录，将使用
window.open('location here');弹出一个新窗口。打开的页面实际上是用户在其余会话期间工作的工作区域。从此页面，还使用其他弹出窗口。最近，我们有许多客户（都使用IE8的最新版本）抱怨说，当他们登录时，初始弹出窗口会将他们带回到登录屏幕，而不是主页。或者，用户有时可以登录，进入主页（再次，在新的弹出窗口中），一切看起来都很好，直到创建任何其他弹出窗口，它就开始将其重定向到登录屏幕。
在试图解决问题时，我使用了老式的Fiddler。当问题开始显现时，我注意到浏览器没有发送ASP.NET会话ID会话cookie或Forms Auth票证会话cookie，即使登录POST的响应明显推送这些cookie。
更奇怪的是，如果我使用CTRL+N从缺少会话cookie的弹出窗口打开一个新窗口，然后手动键入主页的URL，这些cookie就会神奇地再次出现。但是，后续的
window.open();调用将继续破坏，不发送会话cookie并将用户带到登录屏幕。需要注意的是，有时，似乎没有什么好的理由，那些相同的用户突然可以正常登录并工作一段时间，然后回到损坏状态。
现在，我确保没有浏览器附加组件、插件、工具栏等在运行。我已将我们的站点添加为可信站点，并将安全设置降低到最低。我已修改了Cookie隐私策略以“接受所有”并禁用了自动策略设置，手动强制它接受所有内容并包括会话cookie。似乎没有任何影响。
请注意，Web应用程序驻留在单个服务器上。没有负载均衡、Web园艺、服务器农场、集群等。服务器确实驻留在ISA服务器后面，但除此之外，它非常直接。
我已经搜索了几天，没有找到任何可行的东西。有时候甚至无法可靠地重现它。我发现有几个人遇到了同样的问题，但他们似乎在引用一个据称已在Beta或RC版本中修复的问题（例如：IE8在重定向后打开新窗口时丢失Cookie）。这些都是具有最新补丁的IE版本。
我知道我可以尝试设置永久Cookie而不是会话Cookie。但是，这对我们的应用程序具有极端的安全影响。
更新
当将用户添加为本地管理员时，问题似乎会自动消失。只有时间才能告诉我们这种变化是否会永久（且积极地）影响这个问题。
到时间使用ProcMon并查看是否存在资源访问问题。
更新＃2
似乎有多个角度可以解决看起来是单一问题的问题。我很久以前报告说将用户设置为本地管理员似乎有所帮助。对于许多用户来说确实如此。当然，这并不是真正的解决方案，但它确实让我们艰难地前进。
然后更多的用户开始报告这个问题，而管理员修复似乎没有起作用。用户似乎主要是Win7，但Vista也受到影响。他们似乎大多是64位安装。
将TabProcGrowth设置为0或1（任何一个都可以）如以下一些成员建议的那样，似乎在很大程度上解决了问题。因此，我将我的采纳答案移交给第一个提出这个建议的人，因为它产生了显着的影响。
这是一个非常令人沮丧的问题，因为很难复现，并且通常发生在我无法直接沟通的用户身上，或者当我到达他们时，它似乎已经没有问题了。我只能说会话合并功能存在问题，但我没有足够的数据向微软提供以找到永久解决方案。