NTUSER.DAT and UsrClass.dat files building up by the thousands, why and can I delete?

I've noticed that my web server, 2008 Xen VM, gradually loosing free space - more than I would of though from normal use and decided to investigate.

There are two problem areas:

*C:\Users\Administrator\ (6,755.0 MB)*

with files: 

NTUSER.DAT{randomness}.TMContainer'0000 randomness'.regtrans-ms
NTUSER.DAT{randomness}.TM.blf

AND

C:\Users\Administrator\AppData\Local\Microsoft\Windows\ (6,743.8 MB)

with files

UsrClass.dat{randomness}.TMContainer'0000 randomness'.regtrans-ms
UsrClass.dat{randomness}.TM.blf

From what I understand these are in-time backups of registry changes. If that is the case I cannot possibly understand why there would be 10000+ changes. (That's how many files there are per folder location, over 20,000 per folder in total.)

The files are using almost 15GB of space and I want rid of them, I'm just wondering can I remove them. However, I need to understand why they are being created so I can avoid this in the future.

Any ideas why there would be so many? Is there a way I can check to see what is making the modifications?

• Are they created with login attempts?
• Are they created in relation to every day Web Server use?
• etc. and so on

They're not backups of registry changes, actually, they're what changes to the registry are before they become changes to the registry. A type of .tmp file for registry changes, in essence.

As a protection against registry corruption, which used to be a fairly common, and very nasty problem in Windows, what newer versions of Windows do when a change to the registry is requested, is write the requested change to a file before doing anything. (For changes in the user hive, those files are in the form of NTUSER.DAT{GUID}.TMContainer####################.regtrans-ms, and are numbered sequentially - go back far enough and you should see a 00000000000000000001 file.) Once Windows has determined that it's "safe" to write the change to registry, it does so, and following that, it will then verify that the change has been made, at which time it will delete the file and move onto other OS tasks. When something in this process fails, you end up amassing these files.

And clearly, in your case, something, somewhere in that process is not working properly. I'd bet a pretty penny that if you looked through the server Event Logs you'll see a whole ton of errors about this, in the form of events about the registry being locked, or being unable to write changes to the registry. (Probably along the lines of Unable to open registry for writing or Failed to update system registry). These can be indications of serious problems, or they can be indications that some PITA programs wants to write a change to the registry every time it's launched and doesn't have permission.

There's also the less likely possibility that the changes are being written, but the files can't be deleted, as would happen if the locking handle on the files isn't being terminated properly, or if SYSTEM has write permission, but lacks delete permissions to those folder locations.

It may help in tracking down the source to do a quick md5 sum (or similar) of these files to see if they're all, or mostly identical (which would indicate the same change failing to write to the registry over and over), or if there's a lot of variation, which is more likely to indicate a serious problem - that the registry isn't able to be written to by a lot of processes, or that the user profiles in question are corrupt.

Once you're done analyzing them, any of these .blf or .regtrans-ms files that were created prior to the last system boot can be safely deleted. There's no way they will (or should) be written to the registry, so they're junk.

As to what, precisely is creating them, that's something you'll have to track down yourself, because it could be almost anything. It's possible that something in the web code is trying to write a registry change every time the site is accessed, but fails for lack of permissions (I've certainly seen dumber things), it's possible that they're generated by user logons and subsequent activity trying to write to the registry and lacking permissions, and as stated earlier, it's even possible that they're being created and executed normally, but are unable to be deleted as intended for some reason.

Check all your logs, particularly your Event Logs and IIS logs for registry-related errors to narrow it down and figure out what's causing this.