I've been experiencing nasty lockups while debugging under VS2008, SP1 on my machine. I was running ProcMon.exe to try and determine what is going on. One thing I see is 100s or 1000s of repeated reads + writes to a file called security.config.cch and security.config.cch.new.
What are these files? Why would my application need to read + write repeatedly to this file?
Thanks, Dave
Example :
2:18:14.1421944 PM App.vshost.exe 1152 ReadFile C:\Documents and Settings\myuser\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch SUCCESS Offset: 170,397, Length: 208 2:18:14.1422854 PM App.vshost.exe 1152 ReadFile C:\Documents and Settings\myuser\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch SUCCESS Offset: 170,605, Length: 224 2:18:14.1423824 PM App.vshost.exe 1152 WriteFile C:\Documents and Settings\myuser\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch.new SUCCESS Offset: 206,817, Length: 208 2:18:14.1424843 PM App.vshost.exe 1152 WriteFile C:\Documents and Settings\myuser\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch.new SUCCESS Offset: 207,025, Length: 224 2:18:14.1425788 PM App.vshost.exe 1152 WriteFile C:\Documents and Settings\myuser\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch.new SUCCESS Offset: 207,249, Length: 12 2:18:14.1426746 PM App.vshost.exe 1152 ReadFile C:\Documents and Settings\myuser\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch SUCCESS Offset: 170,841, Length: 220 2:18:14.1427679 PM App.vshost.exe 1152 ReadFile C:\Documents and Settings\myuser\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch SUCCESS Offset: 171,061, Length: 224
security.config.cch
files, and variations of them (security.config.cch.new
, security.config.cch.[random numbers]
etc.) are security resolution cache files.
These files are essentially a cache of the CAS (Code Access Security) demands of your application's code. They allow the in-built security system of the CLR to resolve the security demands of your code slightly quicker.
You can safely delete these files, and this will result in your application's initial performance next time around to be slightly slower, however, the CLR security sub-system will eventually re-generate these files.
There was a known issue that could arise from this process, "FIX: Error message when you try to run a Web application that was built by using the .NET Framework 2.0: "Overwhelming changes have occurred" however, this applies to .NET Framework 2.0 and may or may not still apply with .NET Framework 3.5 SP1 (which you're using with VS2008 SP1).
It's perfectly normal for there to be many reads/writes to these files, however, if the reads/writes seem excessive and to the point where you're experiencing lock-ups I would look into either reviewing your code (assuming you have many calls to demand specific security actions or equivalent), or examining the configuration of your Runtime Security Policy as set within the .NET Framework Configuration Tool (Mscorcfg.msc).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With