You may find the following event in your Application event log:
Event Type: Warning
Event Source: .NET Runtime
Event Category: None
Event ID: 1000
Time: 9:35:49 AM
The description for Event ID ( 1000 ) in Source ( .NET Runtime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: .NET Runtime version 1.1.4322.2032 – Error “Attribute names must be unique.” occurred while parsing the User policy level. The default policy level was used instead…
This is another one of those items that doesn’t really have any information returned to you when you try to search for it. So of I went to see if I could reproduce.
My first assumption was that this error was related to on or another security policy. So, what I planned to do was to run the .NET Framework configuration wizard while monitoring the app with FileMon (http://www.sysinternals.com). I set a filter on *.config because I wanted to see what config files the app was touching. I figured this would turn up something and boy did it ever…
Hehe…as you can imagine this isn’t what I was expecting! I rebooted and tried again and for the second time I got the bsod. I need to see if I can repro on another machine to determine if indeed the problem is caused by the FileMon driver or if it’s a problem with my disks at home.
I decided against using Filemon and tried to use the text of the error to my advantage. What I did to hack this was to modify the security.config file by hand. I created a new codegroup using the framework configuration tool. I then opened the security.config file and modified the code group by hand. The change I made duplicated one of the codegroup element attributes so there were two of them instead of one.
I then opened the .Net framework configuration tool and then checked the event log: VOILA! I had several (10 to be exact) of the same events as listed above in the event log. So, to me it looks like someone/something mucked with the security.config file and didn’t play nice with the XML rules. Then, the security tool loaded the xml file it complained about the falsely formed XML and reverted to the default security.config file that ships with the framework.
Here’s the original codegroup XML: