Believe it or not, I was already in bed when I made the mistake of checking the mail on my phone (HDPro2… for now ;-)) and got the nth mail of somebody hitting the same issue; since there’s a REAL QUICK fix, it’s just easier for me to get up and get it out of my mind by blogging about it (or I’d just end up dreaming about it).
The issue at hand arises when you debug in VS2010 an ASP.NET web site which uses a custom STS generated via WIF SDK 4.0 template, something that happens very often when you go through the identity training kit labs. You hit F5 and you get redirected to the STS; you enter credentials (or not) and hit submit. The Default.aspx.cs code-behind munches the request in a try-catch block; when it comes to the ProcessSignInResponse, something in modifies the normal request serving flow. That raises an exception – i think that has to do with the thread serving the request coming to a premature end – which the try-block catches; in response to that, it raises an exception as well. Now, if the try-catch block would not raise an exception, execution would simply go on smoothly; but since the STS template code throws another exception, the VS2010 debugger sees a unhandled exception and breaks there. At that point some people thinks that the execution is failing and just stop the debugging session there.
Now, nothing is wrong: you can just hit F5 again and the flow will continue as expected.
In fact, if you start the execution using Ctrl+F5 everything will go forward without interruptions; this is just a debug artifact.
I was getting this problem again and again and I thought it was a COM error...but was ignoring it ...
I thought I was only getting it but fixed it by emptying the catch block