kburgoyne said:blowdart said:*snip*
I tracked down a reply on another forum that didn't precisely identify the problem, but it did ask a question that ended up identifying the problem on my system.
Specifically, if CardSpace is failing to automatically create a "CardSpace" folder created under their C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft folder, this is most likely the solution.
A definitely problem relates to security settings under the C:\Documents and Settings\<user> directory branch. This is a subtle nasty "problem". I wouldn't say it's a "bug", but Microsoft could probably add some code to CardSpace to help user's resolve it.
My entire C:\Documents and Settings\<user> branch did not have any security entry for <user>. Access was based entirely upon administrator. (<user> is an administrator.)
The solution is to make sure your actual sign-on user account is listed as having "full access" for the C:\Documents and Settings\<user> directory branch, including all subfolders. The fact that the user account might have administrator priviledges doesn't count. These folder security settings are supposed to be the "normal" situation anyway, but system reconfigurations applied over time may have resulted in these entries not existing. There's a check box under the "Advanced" button for security settings that'll make all subfolders under the <user> branch have the same security settings as the <user> folder.
I think what Microsoft is facing here is that CardSpace is probably the first application that a user will run that probably forces the security context to be specifically the signed-on user in order to fulfill the security restrictions CardSpace wants to impose (in order to fulfill its security objectives). Since CardSpace has security objectives that are not a concern of other applications accessing \Documents and Settings\, this isn't really a "bug" in CardSpace. It does however mean that CardSpace support is going to encounter the typical support problems associated with going "where no one has gone before".
I think this is definitely a candidate for a knowledge-base entry for starters. I think it is then a candidate for some user "help" code to be added to CardSpace that explicitly tests for the problem in the directory branch, and then tells the user more clearly what is happening and what might need fixing. Presumably this wouldn't result in a security breach because presumably the user wouldn't be able to "fix" the problem unless they had the appropriate permissions anyway.
I would guess that this problem is most likely to occur on systems that have evolved through various user accounts. This was a LONG time ago, but I believe the current user account I use was not the original account when the system was first configured. I think I cloned the original account into this new account because I wanted to shut down network access to the original default account. The cloning of the \Documents and Settings\ branch probably ended up creating this situation.
I changed my Users folder on Win7 x64 from C:\Users to D:\Users and ran into the Cardspace crashing issue.
After checking your comment, I replicated the exact security settings for my account folder and everything is now OK, Cardspace is running normally.
Just wanted to let people know that it works fine under Win7 too.