I will make a bold statement here: corrupt user profiles are a myth. That may seem very bold indeed, with 331,000 hits on Google for “corrupt user profile” and countless admins complaining about having to deal with corrupt profiles on a daily basis.
In order to understand my position we need to take a step back and have a look at the layout of Windows user profiles. They basically consist of a number of files and folders. One of the files in each profile is special in that it is some kind of database: NTUSER.DAT in the root of every profile contains a user’s registry hive, which is mounted to HKCU during logon. But essentially a user’s registry hive is still a file, alas a file that is exclusively locked while a user is logged on.
For the time being, please bear with me and think of a user profile as a conglomerate of files on an NTFS volume. If you look at user profiles this way, the word “corruption” gets an entirely different meaning. Just ask yourself: what can possibly happen to files on a (partly) transactional file system like NTFS? Of course, if you flip the power switch during a write operation, the file being written to will be corrupt. But apart from that I cannot think of any common situation in which files on an NTFS volume become corrupt. And even the effects of flipping the power switch have been mitigated with Windows Vista and Server 2008: Transactional Registry (TxR) protects writes to NTUSER.DAT just like databases protect their data from power loss.
But what about roaming profiles? They need to be copied from the user’s machine to a file server on the network. Theoretically, a file could become corrupt during transmission.
Ask yourself one question: Is that likely to happen with today’s networks? I think the question should remain rhetorical. If you do not think so you should seriously consider changing or upgrading your network hardware/software/architecture.
Are all those people wrong that have to deal with so-called corrupt profiles? Of course not! The part that is wrong is the term “corrupt”! So-called corrupt profiles are in reality inconsistent profiles. It all becomes clear when you think of a typical situation a help desk employee has to deal with: A user calls and complains about this and that not working. The admin makes some checks and determines something must be wrong with the user profile. He deletes the profile, has the user log on again and all is well.
The user had some “inexplicable” application misbehavior. The root cause for this will probably have been some misbehaving application that either crashed while writing data to the profile or experienced some other issue in the process. The net result is that an application wrote only partial data to the profile, making it inconsistent.
A user profile is a complex structure consisting of many files, folders and registry values. Many dependencies exist between different components of a profile: registry entries point to files, INI files contain the names of other files, and so on. Applications write to the profile all the time. Is it so very special that from time to time write operations are not fully completed due to an error of some kind? I think not.
Of course, Transactional Registry and Transactional File System (TxR and TxF) could provide a remedy for these issues. But Microsoft introduced new APIs for transactions (contrary to earlier plans), meaning that applications need to be changed to take advantage of transaction support. With what we know about application lifecycles in enterprises and the “conservative” attitude of many programmers we will have to live with inconsistent user profiles for quite some time. Because that is what profile corruption really is – profile inconsistency.
The only significant cause of real profile corruption I know of are virus scanners misbehaving, which happens from time to time.
Many user profile management product vendors claim their solution mitigates profile corruption. Now you know you should take such statements with a grain of salt.