petm has uploaded a patch.
Description:
This bug occurs in the following scenario:
* you are using IIS impersonation
* you are connecting to the database using "integrated security"
* you call UserPermissionCache with the multiThreadedBuild property equal to TRUE.
(Other members on this work item have already identified the same issue, but I will try to summarize for the sake of this patch description)
What happens is that the multiThreadedBuild=TRUE approach loses the impersonation you had in the original thread as soon as the ThreadPool.QueueUserWorkItem starts running. This means the call to clonedStorage.OpenConnection() will fail unless the IIS AppPool account is added to SQL Server. I believe this is inconsistent with the intended behavior, since calling UserPermissionCache with multiThreadedBuild=FALSE will use the impersonated account to connect to SQL.
