De oplossing heb ik gevonden:
Terribly slow Visual Studio .NET compilation?
When I started at Globeranger some people were having problems with Visual Studio .NET compiling terribly slowly. And by terribly slowly I mean hanging/locking and taking over 20 seconds to compile a simple project that should only take 1 or 2 seconds to compile. At the time I didn't care so much, because it didn't happen to me.
Then it started happening to me as well. Visual Studio would lock right after it output "Performing main compilation" in the output window. Nothing would respond then eventually it would slowly compile. It started happening only infrequently; I would restart Visual Studio and it would work fine again. Then one day nothing would compile without taking an extra 20-40 seconds. Needless to say, this made debugging much harder since I refused to waste time building my project and just guessed at a lot of code and waited until I got to a major milestone (every 30 or 40 minutes would be the minimum) before I would even try to build.
Then one of us made an observation: take the computer off the network and Visual Studio would speedily compile your projects again. Put it back on the network and you end up in the same situation you were in before. So every time we build I was going to have to unplug my computer from the network? That wouldn't save any time, I'd have to reorganize my desk and it would take at least 5-10 seconds every build to unplug then replug the network cable. Definitely not a marked improvement.
So I started to do some research and found some other people with the same problem. In both of those situations, nobody had any real resolution other than "unplug your network cable" (actually some Microsoft support employee kept making idiotic recommendations, despite the original poster repeatedly saying things like "I did that, not the problem"). Because I didn't want to unplug my network every time I built and because from those newsgroup postings it appears as if it wasn't a permanent solution, I decided to find a way to automate the process. I found an executable from Microsoft called devcon.exe that can list, enable and disable PCI devices on your motherboard. So I found the ID of my NIC and started to write a batch file that would disable it on pre-build of a project and then re-enable it on post-build of a project. Well, I did it once and Visual Studio started working perfectly again, even after multiple app restarts and windows reboots.
So the moral of the story is, if you're having seriously slow-down issues with Visual Studio compiling, simply disable your NIC, build a couple times, re-enable your NIC and Visual Studio should work again. Oh, and this only seems to happen on Domains, I've never seen or heard of this problem by anyone on their domain-free home computer.
Terribly slow Visual Studio .NET compilation?
I experienced this same issue and received the following information:
*** Problem Description ***
We found that this issue is caused by a combination of two things:
A. Using an AssemblyKeyFile attribute
B. There is a lot of activity on Port 138 to domain controllers (as monitored during with TDIMON (sysinternals))
NOTE: Disabling DHCP service is a good test to see if it is causing the problem.
Please refer to SOX030324700042 Visual Studio .NET: Building a strong name signed C# assembly for more information.
CAUSE
=====
Private keys generated are encrypted using a DPAPI master key. When a domain account is used, DPAPI makes two copies of each master key encrypting one with the user password and one with a domain secret. Encrypting the second copy requires calling over to one of the user's domain controllers. If this is an NT4 domain, then the DC doesn't support this operation. DPAPI won't give up though thinking that there must be a Win2K or better DC out there (that's perhaps just offline for a little while). DPAPI will continue to attempt to call over to the DC periodically perhaps every time a DPAPI call is made.
RESOLUTION1:
============
The following article describes a way to workaround this limitation:
http://support.microsoft.com/?kbid=331333
For more information on DPAPI, please refer to:
http://msdn.microsoft.com...ndataprotection-dpapi.asp
RESOLUTION2
===========
1. Log into the machine as a local Administrator (off the network) and muck with the solution.
2. Log back into the machine on the domain
Following the workaround noted in the QArticle 331333 (Resolution1) fixed the problem for me.
en
User Cannot Gain Access to Certificate Functionality After Password Change or When Using a Roaming Profile
View products that this article applies to.
This article was previously published under Q331333
Important: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry
SYMPTOMS
========
When a user tries to use certificate functionality after they change their password or when they use a roaming profile, they may lose access to this certificate functionality. Certificate functionality that may not work as before includes the following:
* Accessing files that are encrypted with Encrypting File System (EFS)
* Accessing a secure Web page that requires certificate authentication
* Signing e-mail with Secure/Multipurpose Internet Mail Extensions (S/MIME)
When they try to access a secure Web site, the following error message is logged:
Schannel Event: 36870
A fatal error occurred when you try to access the SSL client credential private key. The error code returned from the cryptographic module is 0x80090016.
CAUSE
=====
This problem occurs only if the client user account is in a Microsoft Windows NT 4.0 domain and if they are logged on to a Microsoft Windows XP Professional workstation. The Windows XP version of the Data Protection API (DPAPI) function helps to protect EFS private keys and other data that you want to keep secure. The recovery functionality of DPAPI is not supported for users who are members of domains that are running Microsoft Windows NT 4.0 and earlier.
RESOLUTION
==========
To maintain client access to certificate functionality after users change their passwords or when they use roaming profiles, upgrade the domain to Active Directory directory service. Active Directory domains provide a mechanism that helps to protect the DPAPI master key with a public/private key pair. (The DPAPI master key is used to help protect EFS private keys and other certificate-based functions.)
In a Windows NT 4.0 domain, the ability to restore access to the certificate keys and data is located on the workstation. This is not the case in a Microsoft Windows 2000 domain. Because the recovery mechanism is not located on the workstation, Windows 2000 domains provide a significant additional level of protection for certificates if the workstation is physically compromised.
Although you only have to upgrade a single domain controller to take advantage of the DPAPI domain recovery mechanism, consider upgrading at least two domain controllers for fault-tolerance purposes.
It is highly recommended that you plan your Active Directory before you implement it. For more information about Active Directory design, visit the following Microsoft Web site:
http://www.microsoft.com/...ows2000/plan/bpaddsgn.asp
WORKAROUND
==========
To work around this problem, install Windows XP Service Pack 1 (SP1) or later on the client workstation, and then create the following registry entry to emulate Windows 2000 behavior.
Warning: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. Follow these steps, and then quit Registry Editor:
1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb
3. On the Edit menu, point to New, and then click DWORD value.
4. Type MasterKeyLegacyNt4Domain, and then press ENTER.
5. On the Edit menu, click Modify.
6. Type 1, and then click OK.
After you create this entry, the client will determine if the user is a member of a Windows NT 4.0 domain. If they are a member, the Windows XP client will emulate the Windows 2000 behavior, and DPAPI will give users with changed passwords access to their keys.
Note: If you work around this problem by editing the registry, you only change the behavior that is described in the Symptoms section from the time that you make the registry change. Any password changes that were made before the change to the registry are not be undone and you will still receive an "access denied" error message when you open the EFS file.
Important Security Implications
Using this registry entry substantially decreases the security of a physically compromised computer. An attacker with physical access to the computer could access some or all EFS-encrypted files and any Certificate private keys on it.
Recover the Files After a Password Change
To regain access to the certificate functionality on an individual workstation after a password change, change the password back to the password that was used when the files were last encrypted.
Note: These steps only change the password that you use to log on to your computer. They do not change your domain password.
1. Log on to the computer as the user with the current password.
2. Click Start, and then click Control Panel.
3. Double-click User Accounts.
4. Click to select your user name.
5. Click Reset password.
6. Type your original password in the New password text box, and then type the password in the Confirm new password text box. Click OK.
7. Restart your computer.
STATUS
======
This behavior is by design.
MORE INFORMATION
================
The behavior that is described in the "Symptoms" section of this article applies only to users who are members of a Windows NT 4.0 domain and who log on to computers that run Windows XP. The behavior of Windows XP Professional clients that are members of a workgroup or of a Windows 2000 Active Directory domain differs significantly from the description in this article.
For more information about DPAPI in Windows XP, visit the following Microsoft Web site:
http://msdn.microsoft.com...ndataprotection-dpapi.asp
For additional information about troubleshooting DPAPI issues, including loss of access to a private key or EFS files, click the following article number to view the article in the Microsoft Knowledge Base:
309408 Troubleshooting the Data Protection API (DPAPI)
The information in this article applies to:
* Microsoft Windows XP Professional
:strip_icc():strip_exif()/u/13459/crop6564fce317550_cropped.jpg?f=community)
:strip_exif()/u/109062/copy.gif?f=community)
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
:strip_exif()/u/7759/red_cat.gif?f=community)
