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

Question

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

Answer 1

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.

Answer 2

These files are created when a profile is recreated or initiated. They are also sources of trouble, because they are 'signed' in the sense that they are resident and thus become the focus of intruders or hackers if you like.

Following the instructions, RT-CLK My Computer, Properties, select 'Advanced System Settings' and then 'Settings' under User Profiles. You should expect a list of all PROFILEs, that is, one for each USER.

Slow downs always invite inspectors and at times, they overlook something that could be important. On one machine here, there was a PROFILE named "DefaultProfile", which of course is bogus and was deleted. On another, there was a PROFILE named "Default Profile", which is also bogus. However, the latter is not easily removed.

This indicates that someone has hacked in and is building up to a crescendo, which on a third machine, became a USER PROFILE of some 231GB (!!!), making boot an inexorable waiting experience. Eventually, the tolerant user became annoyed when something he had been doing all along, wasn't happening.

All user Accounts on that machine, including the Administrator, were changed to HOME USER and/or GUEST. Just try to get an elevated command prompt from that!

So, if you delete a USER PROFILE, and then log in anew, a new profile is built using the DefaultProfile and in Win10, this is evident by the 'Hi' baloney that makes it look better than Windows Whatever over the years. If you were to logon and then look into C:\Users\ (whatever)\Appdata\Local (for hidden files) you will see the offending REGTRANS-MS files, numbered and ZERO LENGTH.

They are filled with changes, which often result on actions taken to settings on files in use, which is still a no-no. After the session is complete, the changes are invoked and the data in the file becomes the stuff logs are made of for advertising/tracking and a whole slew of things that only the 'Geniuses' at Microsoft now about.

Cheers.