I posted this in the newsgroups a long time ago and several people have emailed me about how it helped them which is really great because the problem is extremely hard to track down. Hopefully by “cross-posting” it here on my web site I will make it even easier to find.
Newsgroups: microsoft.public.dotnet.framework, microsoft.public.dotnet.framework.aspnet, microsoft.public.dotnet.framework.performance, microsoft.public.dotnet.framework.windowsforms, microsoft.public.dotnet.languages.csharp, microsoft.public.dotnet.languages.vb, mic From: "Josh" <josheinstein@hotmail.com> Date: Mon, 4 Aug 2003 16:34:53 -0400 Local: Tues,Aug 5 2003 6:34 am Subject: FIX: Slow compilations when using strong name To all... I have experienced this problem and recently so has my co-worker which led me to try to solve the problem. Before I give you the fix, let me give a brief overview of the problem. Hopefully this will be indexed efficiently by google so that others with this problem can quickly benefit from it. The problem manifests itself when on a Windows NT 4.0 domain and building assemblies using a strong name key generated with the SN.EXE utility. I cannot identify when the problem started, but it was definitely related to the client and not the server because the problem occurred at different times on two different machines. (We're talking months apart...) The problem is that compilation takes an unacceptably long time (~15 seconds PER PROJECT). If you disable the network interface, the problem goes away. If you do not strong name your assemblies, the problem goes away. I saw that one person solved the problem by changing the machine-based key containers option with the SN.EXE utility. While this fixed the problem on my machine (temporarily) it did not help at all on my co-worker's machine. I turned on auditing (for every failure) and found an event log entry in the security log that resembled the following: Type: Failure Audit Source: Security Category: Detailed Tracking Event ID: 596 Backup of data protection master key. Key Identifier: (guid omitted) Recovery Server: Recovery Key ID: Failure Reason: 0x3A According to MSKB article 309408, this is from the DPAPI and there is a workaround detailed in article 331333. I know, it looks like it has nothing to do with VS.NET and the compilers, but in fact it does. http://support.microsoft.com/default.aspx?scid=kb;en-us;309408 http://support.microsoft.com/default.aspx?scid=kb;en-us;331333 By adding the following registry value, the problem has been fixed on both mine and my coworker's workstations and I could not be happier. Below is the registry entry, but I suggest you read the KB articles before importing it because it changes the way the DPAPI functions on Windows XP on a NT 4 domain. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\ Providers\df9d8c d0-1501-11d1-8c7a-00c04fc297eb ] "MasterKeyLegacyNt4Domain"=dword:00000001 On a side note, the fix also corrected this very annoying little problem I was having with Windows Messenger when I would open a new conversation window it would lag for a few seconds before allowing me to type. Perhaps it is related. I hope I have made someone's day as I have certainly made my own. I was beginning to consider not strong naming anything anymore. :) 15 seconds per project in a solution with 8 or so projects was becoming quite annoying!! Please email me if this fix helps you. I'd be happy to hear from you.