Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question
1  
Because you don't believe there have been so many changes the first step would be to run antivirus and anti-malware scans an check the logs for suspicious activity, such as logons that shouldn't have occurred. –  John Gardeniers Aug 24 '12 at 0:28
add comment

1 Answer

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.

share|improve this answer
    
I kind of figured it would be a needle in the haystack jobby. You have certainly given me a great deal to go on. When I can sit down and track it I will do so but for now I've opted to archive and delete them; from what you are saying though - I don't need to archive, just delete them? I have a feeling it could be in response to logon attempts made over RDP. The problem is I can't lock access down to a static IP. I have enabled secure RDP clients only though which has slowed down the attempts. I will revert when I have more info as it may help someone else if I do find the cause. –  Anthony Aug 23 '12 at 23:17
    
The other kink I have is that the web server was a pre-made, pre-installed template of what the providers created - they could of mucked it up before I even started it to custom configure. Who knows. It wouldn't be the first time I've experienced a problem which reared itself because of incompetent techs. –  Anthony Aug 23 '12 at 23:20
1  
@Anthony Well, archiving them would be useful for analyzing them, but really, no, you can safely delete them. Might be wise to only delete those prior to the last reboot, or cleanly reboot the OS, and then delete all of them, in case some are still pending to be written. As to logon attempts over RDP... I wouldn't think so, as you shouldn't be prompting any registry writes until you successfully log in... then again, this is a pretty serious edge case, so maybe it's worth considering that this behavior might be from something totally out there as well. –  HopelessN00b Aug 23 '12 at 23:21
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.