The \$Extend\$RmMetaData\file structure

[August59]

Can someone quickly explain what is happening when I have an USB hard drive that cannot be removed by "Safely Remove Hardware" command? The process that is running for hours, that seems to be holding on to mt hard drive is:
"g:\$Extend\$RmMetadata\$Txflog\$Txflog.blf"
"g:\$Extend\$RmMetadata\$Txflog\$TxflogContainer00000000000000000001"g:\$Extend\$RmMetadata\$Txflog\ $TxflogContainer00000000000000000002

All of this was associated with my "G" drive - WDC WD25 OBEVS (Verbatim) USB hard drive.

The USB hard drive is obviously in very constant use as it is singing and "blue light" is constant. The reason I ask is that I had to interupt the process and I ended up with a corrupted "Recycle.bin" on the usb hard drive. It somehow messed up my "boot loader" which had attached the letter "G" to the "Windows 7 x32" Partition that was not in use. I found this out by by chance while I was removing "Acrobat.com" and it prompted an "Autoplay" pop-up and it was for drive "G" - Windows 7 x32 (which is my first operatiing system and the one not in use as I was operating under Windows 7 x64).

I know rhere are a few post on this topic, but they are very specific to a different problem. If you know of a link that does the job, by all means please just send me the link. Thank everyone very much!!!!

[SalVatore]

Hello there, this particular problem that you are facing can also occur because of any sort of threats. So, install a well updated antivirus in your system and then, scan the entire system. Now, delete all the unhealed infections from it. Then, let me know if the issue is solved or not.

[August59]

I'll do that ASAP. Had one other reply from someone local and they told me it was "defrag" program or "indexing" program. Thanks

I will say that it started right after I installed iTunes and was referencing the "G" drive (Verbatim) to populate the iTunes library.

[snofriacus]

I'm running into this same problem. I haven't yet solved it for my case, but did find some info that might be of use. The "Safely Remove Hardware" button wasn't able to release my USB drive M: for removal, so at the command line I typed:
"handle m:"

This showed the following open handles on the drive, quite similar to what you reported:

System pid: 4 DB8: M:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000001
System pid: 4 ED4: M:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000002
System pid: 4 EF4: M:\$Extend\$RmMetadata\$Txf
System pid: 4 1574: M:\$Extend\$RmMetadata\$TxfLog\$TxfLog.blf

Then at the command line I typed:
"fsutil resource info m:"

It reported some Resource Manager info including this mysterious path "$Extend\$RmMetadata\$TxfLog\$TxfLog"

Then at the command line I typed:
"fsutil resource stop m:"

Now running "handle m:" shows no more matching handles on the drive.

I don't have any clear understanding of this hidden data that we're seeing or of the "fsutil" commands that have some control over it, but my impression is that it's all a part of the NTFS file system. I found the info on a website that was addressing issues with defragmentation of this hidden data.

I don't know whether this will solve your case. As I said, it hasn't actually solved mine. My case is a little more complicated than what I've described so far. This drive M: is actually just one of six partitions on my USB drive. Five of the partitions are formatted as NTFS, and all five of these are exhibiting this same problem. Once I run the "fsutil resource stop" command for each logical drive, they all seem to stay stopped, now reporting no handles, until I press the "Safely Remove Hardware" button. Then at this point, something triggers them all on again.

Hoping that somebody else can build on these observations to bring us to a working solution.

[August59]

Thanks for the response. I actually just yesterday really beat my brain up trying to remember exactly what I had done when this problem happened to me. I only came up with a couple of options and I knew it was not an infection of any sorts all though there is a lot of stuff on the "net" about it. I came up with the following things:

1) I had it attached for a long time period of time.
2) I had searched for some things
3) I deleted a lot of files, some of which were on the "USB" drive and some of the files were very large.
4) I installed only a couple programs at that time. One I had already removed and the other was "iTunes"
5) I rebooted while it was attached and noticed a very quick blip on the screen while the boot process was going on. I don't know if there is a running log of the boot process or how to view it if there is.

I had a gut feeling that "Windows 7" in some way had a hold of the drive and would not let it go. So, I decided to try a couple of things.

1) From the desktop screen I right clicked on the "Recycle Bin" icon and went to properties and highlighted my "USB" drive and changed the setting to "Don't move files to the "Recycle Bin". (I did this because I had a "Recycle.bin" file and a "System Information" folder on my "USB" drive if a turned on "Show hidden files and folders" and unchecked "Hide system files and folders".
2) I uninstalled "iTunes" (the 64-bit version) and Quicktime

Since I did these 2 things it has not denied me "Safely Remove Device" since. I have left it attached for 4 -5 hours and it still works fine. I wish I had done one and then tried it, but I didn't think it was going to work.
I hope this information can help you or someone else because it is just aggrevating.

[snofriacus]

Thanks for this info. Disabling the recycle bin looks like a good thing to try. I've just done that on all 6 volumes of my external USB hard drive. It hasn't made any difference yet. Maybe it will make a difference after a reboot. Thing is, I can't reboot right now. I do need to disconnect from the external drive though so I can take my laptop to the office.

So for now what I'll take as my solution is to run the "fsutil resource stop X:" command on all 6 volumes. This does close the open handles from the Kernel Transaction Manager, as verified by the command "handle RmMetadata". Running "handle X:" for each of the 6 volumes verifies that there are no open handles at all now on these 6 volumes.

At this point if I were to run "Safely Remove Hardware", it would fail, somehow cause all these handles to be opened again, and I'd be back where I started. So... I'm going to skip the "Safely Remove" step this time, and just disconnect the drive.

Ok, the deed is done. We'll see what comes of it.

If the recycle bin tweak doesn't help things and I have to fight with this again, one other thought to follow up - My troublesome drive is listed under disk management as a "Basic" type disk just like the drive that my OS boots from - not as a "Removable" type disk like my USB flash drive. If I could find a way to mount the USB hard disk as "Removable" - I wonder if that would keep the system from opening these Resource Manager log files on the drive during the removal process.

[jesse]

It has been seen that there some of the problems being encountered in the Windows 7 operating system, not because of incompatibility, but because the operating system blocks the programs from loading. One of the solutions to force such programs to execute is to run them as administrator. I hope that this can be prove of some help to the Windows 7 users.

[snofriacus]

Ok, just reporting back...

My USB drive still works fine despite having to unplug it without the ok of the "safely remove hardware" function. Rebooted the computer this morning. Then after plugging in the USB drive again, the "safely remove" function again doesn't want to let me unplug it. The recycle bin still has the new settings I put on it, disabling it for the 6 volumes on my external USB drive. But this tweaking of the recycle bin didn't take care of the problem.

I recall that I used to have this problem fairly regularly with this external drive, then the problem went away and for a while I was actually able to safely remove the drive. Then the problem returned a few days ago. No idea what changed to bring the problem back.

Oh - One significant change I did make recently was the addition of one more partition - the largest NTFS partition on the drive.

An interesting observation is:
1) I use "fsutil resource stop X:" on all 6 volumes, and the open RmMetadata handles are closed.
2) I try the "safely remove" function, it fails, but when rechecking the handles afterwards, they're actually all still closed.
3) It's only when I run "fsutil resource info X:" for each drive that the handles are opened once again.

My conclusion is that I've probably been misled by the open RmMetadata handles reported by handle.exe. The problem, whatever it is, probably actually has nothing to do with the RmMetadata log file handles. Since they remained closed throughout the failure of "safely remove", something else must actually be causing the failure.

A new troubleshooting tool I tried on this today is Sysinternals ProcessMonitor, filtering to display just the entries whose path contains G:, H:, I:, K:, L:, or M: (the 6 volumes on my External hard disk), and disabling all the default exclusions so that I'll see -everything- that applies to these 6 volumes. It shows some interesting activity involving mostly svchost.exe and System on the NTFS volumes, and involving Explorer.EXE on the one FAT32 volume. Could be the key to figuring this out, if I had a better understanding of what it's telling me. The Explorer.EXE activity on the FAT32 volume was a surprise. Nothing ever showed up on that volume when just looking for open handles. So... maybe this could actually be a FAT32 problem rather than an NTFS problem?

[JAMES_911]

Have you tried resetting the RM (resource manager). This will blow away all the $Rm data and re-create everything from scratch, after which $Tops will be negligable.

1 Before resetting the RM make sure there are no transactions in progress, and if there are its best to just wait for them to complete. To check type "fsutil resource info c:\". The output of the field 'Running Transactions' will show non-zero if there are transactions in progress.
2 To reset the RM type "fsutil resource setautoreset true" and then reboot.

[snofriacus]

Ok, thanks. I tried this "fsutil resource setautoreset true" command on each NTFS volume of the removable drive and rebooted. It did change the shape of things a bit, but still no safe removal.

There were initially a couple of negative changes. Searchindexer.exe and svchost.exe now showed up with handles on the removable volumes. I was able to get rid of the searchindexer.exe handle by stopping the wsearch service. What svchost.exe was doing had to do with System Volume Information, which hadn't previously been involved in this at all. This eventually went away too after some more tinkering and reboots. Maybe svchost actually had some legitimate work to do on "System Volume Information" after the reset, and the problem went away when it was finished? Or another possibility is that the extra issues came from rebooting with the drive connected, which I did on that first reboot. On subsequent reboots I reconnected the drive -after- rebooting was done. Anyway, the extra problems are gone now.

The original problem - the open handles on RmMetadata log files - is back and looks just like it did before, except for one change in the positive direction. Now when I run "Safely Remove Hardware", that process successfully causes all these RmMetadata handles to be closed. No longer any need for me to close these handles myself by first running the "fsutil resource stop" command. The safe removal still fails. Something else is still blocking it. Apparently it's not about open handles, because there aren't any.

Thanks for your ideas. I'd like to get to the bottom of this, but have no spare time left to spend on it. Could be just one little detail out of place on one of the 6 volumes. Wish I could attach individual volumes one at a time to narrow it down.

[Team Leader]

You can try using some commandline tools called RemoveDrive that can prepare a drive for save removal, download it from here. Started with parameter -i it stops the indexing service for a moment. Horrible workaround, but it works.

Example:

removedrive u: -i

For stopping a service admin previleges are required.