1.6.1.41 No unloading PE_C_ALL USERS Registry hive

Hi Everyone,

PepiMK I am hoping that you find your way to this thread. I am the guy that reported the users registry hive lock problem for 1.6.0. Thanks for taking care of that problem. I have just installed 1.6.1.41 release canidate on a clients machine. The SID based user hives are now unloading perfectly. However I have noticed that PE_C_ALL USERS is not unloading from HKEY_USERS. This hive will not cause a problem with locking user profiles but it should also be unloaded when Spybot terminates. By the way what is PE_C_ALL USERS hive? Thanks for your support...

Are you working from drive D: and have another installation on drive A:?

PE_C_ALL USERS would be the hive found at C:\Documents and Settings\All Users\ntuser.dat ... but the all users hive is loaded by the system, and once it is loaded, Spybot shouldn't even be able to load it itself (that's why I'm thinking it might belong to a different installation).

Hi PepiMK,

Thanks for your reply. The machine in question has never had Spybot installed before and I am working from drive C with no other drives on the machine. After the install I figured I would check the Users hive after terminating Spybot. This is when I found the PE_C_ALL USERS hive. I manually unloaded the hive and ran Spybot again. The hive returned back in HKEY_USERS. I manually unloaded the hive again and tried a third time. The result was the same. Spybot is definately loading this hive and not unloading it after termination. PE_C_ALL USERS only has two folder in it (Control Panel and Keyboard Layout). I can not imagine that Spyware would plant itself here. In my opinion the hive should never be loaded at all. Hopes this helps you find the problem. Thanks for your support...

Hi PepiMK,

I was curious about what you said here...

Quote:

---

Spybot shouldn't even be able to load it itself (that's why I'm thinking it might belong to a different installation).

---

I am able to manually load/unload the hive C:\Documents and Settings\All Users\ntuser.dat into HKEY_USERS using Regedit. This means that Spybot can also load/unload the All Users hive. When I Google about this hive I get several hits from folks posting the antivirus scan logs. It seems that their logs indicate the All Users hive is locked on their machines when they ran the scan. I am curious why the hive is locked on their machines and not mine. I also have tried this on another machine with the same results in that the hive is not loaded/locked by Windows. Can you explain this? Thanks for your support...

I searched a bit myself, but - did not find that hive on any machines I looked at! It does not make a lot of sense anyway... what exactly would an "All Users" hive do? I seem to have mistaken it with the .DEFAULT hive the first time I read it.

Still need to check machines that are part of a domain. Maybe it could make some sense for domain policies?

Hi PepiMK,

I have figured out what is happening. Spybot is parsing the Documents and Settings subfolders and looking for NTUSER.DAT hive files. If it finds a user hive then it tries to get the SID for the hive. If it finds a SID for the hive then it loads the hive using the SID under HKEY_USERS. If a SID is not found then Spybot is loading the hive the old way using PE_C_Username. In the case that a SID is not found for the hive, the PE_C_Username is not unloaded after normal termination.

This theory can be tested by creating a folder "Test" under Documents and Settings. Then place any NTUSER.DAT file in the "Test" folder. In fact you can create an empty .TXT file and rename it to NTUSER.DAT if you like. Now run Spybot and you will see a key PE_C_TEST under HKEY_USERS.

The question is what to do about this. Here is what I think. If Spybot cannot find the SID for an NTUSER.DAT, then that hive should be ignored. Hives without a SID must be the All Users hive or User Account hives that are no longer active on the system. When you remove an account from the system, you are given the option to delete or keep the files. So this would explain NTUSER.DAT's without an associated SID. If there a alot of dead accounts with NTUSER.DAT's remaining, then this will increase the scan time. What do you think?

I also have made some progress on why some systems have an NTUSER.DAT hive in the All Users folder. I had a look at the NTUSER.DAT.LOG using Notepad. From what I can see it is associated with Windows Media player. I am not sure how the the hive is getting created or why but WMP is definately using it or did so at some time. I have attached a zip file with the NTUSER.DAT and NTUSER.DAT.LOG from the All Users folder. Load the hive under HKEY_USERS and check out the data. It does not give me any clues but if you open up NTUSER.DAT.LOG in Notepad you will see the reference to WMP.

I hope that you can slip in a fix for this before the final release of 1.6.1. Thanks...

It's not as simple as the skipping you described ;)
Finding hives that have no SID in the running system is absolutely essential to scanning inactive systems, like when you are scanning from a boot CD - the system running on the CD does not know thing about the hives on the harddisk.

Skipping by folder name is also error-prone - the All Users folder can be retrieved from the registry of the running system, but it might get difficult for inactive systems again. The best solution there might be to somehow find the proper hive name instead of a generic one, but that would mean finding out how/where it is loaded when it gets active.

Since in 2.0 there might be multiple module that might need all hives (scanner and immunization to start with), and it cannot be taken granted that apps are started and closed in the "proper" technical order (FILO), there's a background hive "management" that will deal with closing hives.

Thanks for the attached file, I'll take a look it :)

Hi PepiMK,

I suspected that my solution would not cover all of the bases. I do not see a problem with loading and scanning the All Users hive or any other hives that are inactive. I also do not see a problem with the PE_C naming convention for hives with no SID. However they should be unloaded just like the SID hives when Spybot terminates. Thanks and I look forward to your reply...

Since we needed to make a new build anyway for a 9x/ME graphics glitch, I decided that we could put the new hive manager into 1.6.1 as well.

Even the old one should try to unload any registry hive it has loaded, so usually, something that does not get unloaded means that some other process might have a handle to a key in there open. In the the one, the state ("this hive was loaded by Spybot") is not discarded though when closing Spybot, so if a hive could not get unloaded when closing Spybot, it would be attempted again the next time you close Spybot.

More details, like a warning message and possibly even listing which process is responsible (owns the handle), will follow in 2.0 only :)

Hi PepiMK,

The new hive manager sounds good but I think the old one can be fixed very easily. The PE_C_username hives do not have any handles open by Spybot or any other program. I no this because the hive can be unloaded manually using regedit. This means that Spybot is not trying to unload the PE_C hives. Please try this to confirm my findings.

1. Create a folder called Test under Documents and Settings.
2. Copy the hive that I uploaded to you in NTUSER.zip to the Test folder.
3. Run Spybot. You do not need to run a scan.
4. Open regedit and look in HKEY_USERS. You will see the PE_C_TEST hive.
5. Exit Spybot.
6. Refresh regedit and look in HKEY_USERS. PE_C_TEST will still be there.
7. Manually unload the hive using Unload Hive in regedit.

To further show that the PE_C hive does not have an open handle try this. Repeat steps 1-4, then use regedit to manually unload the PE_C_TEST hive before exiting Spybot. In fact if you have any other user account SID hives that Spybot has loaded, you can also manually unload them as well using regedit.

I think this confirms that the both PE_C and SID hives loaded by Spybot are not locked due to an open handle. Since the SID hives now unload everytime and the PE_C hives never unload, I have to conclude that Spybot is not trying to unload them. I hope this helps and thanks for your support...

Hi PepiMK,

The new hive manager sounds good to me. However I still think that you are missing my point. The PE_C_username hives do not have any handles open by Spybot or any other program. I no this because the hive can be unloaded manually using regedit. This means that Spybot is not trying to unload the PE_C hives. Please try this to confirm my findings.

1. Create a folder called Test under Documents and Settings.
2. Copy the hive that I uploaded to you in NTUSER.zip to the Test folder.
3. Run Spybot. You do not need to run a scan.
4. Open regedit and look in HKEY_USERS. You will see the PE_C_TEST hive.
5. Exit Spybot.
6. Refresh regedit and look in HKEY_USERS. PE_C_TEST will still be there.
7. Manually unload the hive using Unload Hive in regedit.

To further show that the PE_C hive does not have an open handle try this.
Repeat steps 1-4 then use regedit to manually unload the PE_C_TEST hive before exiting Spybot. In fact if you have any other user account SID hives that Spybot has loaded, you can also manually unload them as well using regedit.

I think this confirms that the both PE_C and SID hives loaded by Spybot are not locked due to an open handle. Since the SID hives now unload everytime and the PE_C hives never unload, I have to conclude that Spybot is not trying to unload them. I hope this helps and thanks for your support...