Jump to content

MountPointManagerRemoteDatabase


Recommended Posts

  • 2 months later...

The reason we want to get rid of the System Volume Information folder is because it gets in the way of defrags and disk checks, especially on removable drives formatted with NTFS.

But more than that it is the principle of the matter: My hard drive belongs to me, not Microsoft. Sure XP can have C: but the rest of my drives are mine and mine alone. It is an affront that Microsoft think they can hide files on our hard drives and deny us access to them. I will not rest until it is permanently destroyed.

Link to comment
Share on other sites

I have System Restore disabled, and deleted all files in System Volume Information. It still recreates MountPointManagerRemoteDatabase and tracking.log, but I really can't be bothered that much, since the first file is 0 bytes, and the second is 20 bytes. I'd rather see it gone too, though. I don't understand how it can get in the way with defrags and disk checks if you give everyone full rights to the folder and files.

Link to comment
Share on other sites

  • 1 month later...

i tried something.

i deleted a siv folder and i made an empty file called siv.

i restarted and it was really strange, the process that recreates the siv folder deleted the file i made and created the folder on the drive.

so i tried to do it again but with a cacls siv /d system on the file.

certainly after this the folder weren't recreated on the drive.

would it be possible to catch a system error message that it couldn't recreate the siv folder? maybe it would show what process were unsuccessful.

Link to comment
Share on other sites

  • 2 months later...
The reason we want to get rid of the System Volume Information folder is because it gets in the way of defrags and disk checks, especially on removable drives formatted with NTFS.

But more than that it is the principle of the matter: My hard drive belongs to me, not Microsoft. Sure XP can have C: but the rest of my drives are mine and mine alone. It is an affront that Microsoft think they can hide files on our hard drives and deny us access to them. I will not rest until it is permanently destroyed.

Fully agree here, and it definitely bothers defraggers (if you can't read or delete it, most probably no program can). Or if you delete it, when it is recreated, even if it's 0 bytes long, it takes up a cluster and FRAGMENTS the free space. Same for the folder. I've been trying to fight with it for some time and found the string "MountPointManagerRemoteDatabase" inside two files in system32/drivers:

fltMgr.sys

and

mountmgr.sys

but I'm still reluctant to disable these services/delete files - and I don't recomend anyone to do it. I've had many BSODs because of disabling services I KNOW that are unnecessary for me, but 'someone' apparently knows better. I never use dynamic disks or do volume shadow copies or connect direct parralel... but hey... Has anyone got World Standard Teletext Codec to work or seen any use of it? Why should I keep 2+ Mb of junk (in system32 only, not to mention registry and other places) if I don't and never will use direct play?

...Someone please stop me! :realmad::whistle:

GL

Link to comment
Share on other sites

That's some great info GrofLuigi! :w00t:

You figured it out.

The first file you mentioned, fltmgr.sys (FS Filter Manager), is a new service which came with SP2. From what I can read about it, you don't really need this at all. You can easily disable it like this;

REGEDIT4

; Stop the service from running
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FltMgr]
"Start"=dword:00000004

; ..or remove FS Filter Manager alltogether :)
[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FltMgr]

The main problem however, is the Mount Manager (mountmgr.sys)

There's two places you need to hack/alter in the file if you want to get rid of the automaticly creating of the SIV\MountPointManagerRemoteDatabase file,

0A10: 5C 00 53 00 79 00 73 00 (...)

9610: 6C 43 72 65 61 74 65 53 (...)

But since I'm not a hacker, I wasn't able to successfully to make it work as I wanted. I was able to disbale the creation of the mountpoint(..) file by changing the first of the mentioned addresses of (0A10) 5C 00 53(...) to 5C 00 3F(..)

But I was unable to change the automatic creation of the SIV folder, which I think is programmed into the second address (9610). When I tried to change that, I couldn't launch into Windows, bummer :(

I'll leave the hacking to someone who knows what they're doing.

However, you can make it work by replacing the mountmgr.sys file, with the pre-SP2 Build, which dosen't contain any aforementioned "always-create-crappy-files-on-my-drive" code as far as I can see.

I found my original XP CD, and copied mountmgr.sys (Build 5.1.2600.0) to my Windows\System32\Drivers\ folder, and restarted the machine. I deleted the System Voulme Information folder and have been running my machine for 17 hours. I've also restarted the machine 2-3 times to check if the folder gets back, and it surely does not.

It's working like it used to under SP1 :thumbup

I won't reccomend doing any of this, unless you know what you're doing and are willing to take some risks.

For your convinience, here's the original pre-SP2 Build 5.1.2600.0 of mountmgr.sys

Click here

Link to comment
Share on other sites

Kishiro, thank YOU for the information. :hello:

However, this is one of the few parts of Windows I would not poke too deep - the filesystem.

For starters, I will just disable FltMgr service and see what happens - if it doesn't boot, that can be easily reverted with Recovery Console. :whistle:

But, I am really uncomfortable with pathching - just because this is not so big of a problem.

As for the empty file, I deal with it easily:

For the System Volume Information folder, I add myself as a user with full permissions (inheritable).

Now I can do whatever I like with the empty file. Most often, it gets automatically deleted by a "cleaning" program. Even it gets recreated, It doesn't get into anybody's way.

I considered taking away system's permissions on that folder and storing my files in there, but naah... I'm not THAT geeky. :wacko:

GL

Link to comment
Share on other sites

  • 1 month later...

There is a way to prevent the creation of "Recycler" and "System Volume Information". I was _very_ annoyed by these reapearing directories, so I looked into it and came up with the following solution.

It is quite hardcore so you should now what you are doing... BE WARNED...

1) Create a complete backup of your harddisk. You will be messing around with system files, so don't take this easy. Things might go wrong. And have a bootable CD ready to recover your system...

2) Use a program that is capable of searching for hex values, e.g. Total Commander.

Search for the following hex string in your drive containing windows: "530079007300740065006D00200056006F006C0075006D006500200049006E0066006F0072006D006100740069006F0

06E" with is nothing else than "S y s t e m V o l u m e I n f o r m a t i o n" - that's how it is stored in executable files. Note that there are not simple spaces but hex00 values, that is why we are using that search string.

3) You will be returned with some files. Now use a hex editor, like winhex, and search in all returned files for the hex string from above. Every finding replace with a different tag, eg ongoing numbers (Change "S y s t e m" in "S y s 0 0 1" and so on). And keep track which number you assigned to which file. After doing that with all files, you can now easily determine, which one is causing the creation of the directory from the number in the directories name.

For me, it was the "ntoskrnl.exe" in the system32 folder.

4) Copy this file to a different directory. Change the SVI with your hex editor to "C:\WINDOWS\TEMP". Boot into the recovery console, replace the original file with your altered one. (Think about the dllcache directory. Either delete all files in that directory or be aware of replaing the file here as well.)

NOW YOU ARE FREE OF SVI DIRECTORIES...

5) Remove all previous SVI directories from your system (eg. by using that script posted earlier). Now you should test your system for stability. After perhaps 3-4 days you can reinstall your backup and replace only the files that needed modification.

You can do the same for Recycler according to the method stated above. Search String is "520045004300590043004C00450052" to be replaced by hex 20 values which is equivalent to space. For my sytem, it was shell32.dll in system32 directory.

Again: You should now what you are doing... Just a nice example: If you replace the SVI with hex 20 values, you get a nice directory with a name of blanks. Very difficult to remove from you system... So, both files seem to be using different methodes of creating the directories.

Link to comment
Share on other sites

  • 4 weeks later...

I have been running these suggestions now for a long time... Just wanted to report it's stable, no problems did occur at all.

And what a beautiful silence: No more directories are created. Wonderful... Still an impertinence that you have to employ such drastic measures to stop your operating system from it but that is a different story.

Just out of curiosity: Did anybody follow my guide and try it? Would be nice to hear your suggestions especially since there was a lot of discussion going on before...

Link to comment
Share on other sites

  • 3 weeks later...
  • 4 years later...
Guest ajmal_2204

I have found a method to remove this mountpointmanagerremotedatabase. Just download this program and install it : URL removed. Then right click on the file and select Unlocker. From there it is easy. For me it worked.

Regards,

Ajmal Basheer.

Edited by cluberti
URL removed - virustotal.com reports problems with the .exe, as did NOD32
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...