Status: Unresolved, workaround provided.
Update 121122: Closing the loop... this was never actually resolved, and our customer agreed to use the workaround of disabling scardhook.dll.
Update 110818: Citrix found that it's likely that a cryptographic service provider (CSP) installed on the machine is not functioning as it should. We have asked the customer to engage the developer of the CSP.
Update 110705: After disabling scardhook.dll (Citrix) we did not see the problem anymore. The customer has a case open with Citrix now, and we're further working on this together.
Update 110522: End of last week I've opened a Request For Collaboration (RFC) with our Sustained Engineering (SE) team, in order to get further assistance on this issue. Stay tuned for updates to this post!
Update 110518: Researching a new memory dump shows the identical issue, also after removing ForeFront. We did this because a similar problem was resolved in the ForeFront Client update of October 2010. If you are running ForeFront, please ensure this update (and later updates) are applied on all your machines. Further research on the dump(s) is needed to find the root cause. Also, turns out this is not only related to index.dat, although redirecting this file and similar files may increase the frequency of the hang. Stay tuned! :)
Today my colleague Sonny and I had a look at a memory dump of a freezing machine. The root cause of this looks to be in rdbss.sys, but it's triggered because the Internet Explorer cache index.dat is redirected. This is causing "stress" on the Redirector, thus eventually hanging the machine.
Looking at the various stacks, the most significant one to indicate this issue is:
0: kd> knL e
# Child-SP RetAddr Call Site
00 fffff880`24c341f0 fffff800`01693992 nt!KiSwapContext+0x7a
01 fffff880`24c34330 fffff800`016961af nt!KiCommitThreadWait+0x1d2
02 fffff880`24c343c0 fffff880`02626bcb nt!KeWaitForSingleObject+0x19f
03 fffff880`24c34460 fffff880`0263599b rdbss!RxLowIoSubmit+0x2c3
04 fffff880`24c344c0 fffff880`0260d46d rdbss!RxLowIoWriteShell+0x7f
05 fffff880`24c344f0 fffff880`026358ce rdbss!RxCommonFileWrite+0x1be9
06 fffff880`24c34660 fffff880`02604684 rdbss!RxCommonWrite+0xe6
07 fffff880`24c34690 fffff880`02621b44 rdbss!RxFsdCommonDispatch+0x870
08 fffff880`24c34780 fffff880`031ce2cc rdbss!RxFsdDispatch+0x224
09 fffff880`24c347f0 fffff880`0190b271 mrxsmb!MRxSmbFsdDispatch+0xc0
0a fffff880`24c34830 fffff880`01909138 mup!MupiCallUncProvider+0x161
0b fffff880`24c348a0 fffff880`01909b0d mup!MupStateMachine+0x128
0c fffff880`24c348f0 fffff880`01287bcf mup!MupFsdIrpPassThrough+0x12d
0d fffff880`24c34940 fffff880`012866df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
To get to this stack, use !locks command and look for output similar to:
Resource @ 0xfffffa800a99b360 Exclusively owned
Contention Count = 4
NumberOfSharedWaiters = 2
NumberOfExclusiveWaiters = 2
Threads: fffffa800ae33060-02<*> fffffa800a98f060-01 fffffa800a9c65c0-01
Threads Waiting On Exclusive Access:
fffffa800a7ea900 fffffa800a9f3b60
The thread marked with the asterisk (*) is the owner of the resource, and the thread of which the stack is above.
If you look at the IRPs related to the above thread using the !irp and the !fileobj extensions, you will see a FileObject similar to:
\Roaming\Microsoft\Windows\Cookies\index.dat
We are currently further investigating this. Expect an update shortly. Please mail me when you think you have this issue.