Test Build 546 (mainly for x64 compatibility)

jv16

Here is a test build which addresses most 64 bit Windows compatibility issues, and a whole lotta other things as well.

The reason it's only released here and why it's called a "test build" is because this version is not ready for public use, it still contains some bugs, of which the most serious being that under 64 bit Windows the restoring of backups does not work properly with the 64 bit view of the registry. So use with caution! Also the Detach feature of the Message Windows is not fully implemented yet.

You can download it from here:

http://www.macecraft.com/downloads/betas/jv16pt_setup_hb_546.exe

You can install it over the old version, but only install this version if you want to do some testing! This is not a version that should be used in production use.

Please send all your reports and feedback to this thread, thanks!

siliconman01

FIRST, let me say that there has been SIGNIFICANT advancement in the x64 compatibility of the Registry Cleaner. It is really encouraging. An Aggressive Scan revealed some 3200 registry keys that could be safely fixed or removed. My subsequent posts show where there may be some issues remaining....however, there are only a few in respect to the registry cleaner.

The Message window now stays open after closing a registry tool window. It is then used again as a "continuation" when opening another tool item. This is a new "technique" in build 546 ??

Also the Detach feature of the Message Windows is not fully implemented yet.

I assume this is part of the above item.

siliconman01

As reported in numerous posts on previous builds, the Startup Manager still does not properly display the startup items.

The actual startup registry entries are shown below:

Windows Registry Editor Version 5.00

"AutoSizer"="\"C:\\Program Files (x86)\\AutoSizer\\AutoSizer.exe\""

"Sidebar"="C:\\Program Files\\Windows Sidebar\\sidebar.exe /autoRun"

"HostsServer"="\"C:\\Program Files (x86)\\HostsMan\\hostssrv.exe\" --start"

"WeatherWatcherLive"="\"C:\\Program Files (x86)\\Weather Watcher Live\\ww.exe\""

"StickyPassword"="C:\\Program Files (x86)\\Sticky Password\\stpass.exe"

Windows Registry Editor Version 5.00

"PowerChute"="\"C:\\Program Files (x86)\\APC\\APC PowerChute Personal Edition\\Display.exe\""

"IAAnotif"="\"C:\\Program Files (x86)\\Intel\\Intel Matrix Storage Manager\\iaanotif.exe\""

"NvCplDaemon"="RUNDLL32.EXE C:\\Windows\\system32\\NvCpl.dll,NvStartup"

Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

Class Name: <NO CLASS>

Last Write Time: 3/25/2009 - 4 AM

Value 0

Name: UltraMon

Type: REG_SZ

Data: "C:\Program Files\UltraMon\UltraMon.exe"

Value 1

Name: avgnt

Type: REG_SZ

Data: "C:\Program Files (x86)\Avira\AntiVir Desktop\avgnt.exe" /min /nosplash

Value 2

Name: THGuard

Type: REG_SZ

Data: "C:\Program Files (x86)\TrojanHunter 5.0\THGuard.exe"

siliconman01

4 Shared DLLs keep showing up during registry scans as Unneeded. It says that it fixes them...but they show up on the very next scan again.

It says these are in HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls\ when actually they are in HKLM\Software\Wow6432\Microsoft\Windows\CurrentVersion\SharedDlls\. Pic and attached SharedDlls exported registry keys are attached.

siliconman01

These 4 keys are stated to be invalid. They are reported to be at HKLM\software\Wow6432Node\microsoft\windows\currentversion\setup\pnplockdownfiles\. They are actually at HKLM\software\microsoft\windows\currentversion\setup\pnplockdownfiles\. PT 2009 cannot fix or delete them. In addition, PT 2009 opens the 32-bit registry when clicking on Regedit for these keys.

This is in an Aggressive scan of the Registry.

Note: The keys are truly invalid because there is no C:\Windows\nvtmpinst folder on my system. Apparently these are a leftover from an nVidia driver update.

siliconman01

On testing the registry compactor on x64 Vista SP1 Business, the compactor is unable to open HKLM\Security for compaction. The other hives appear to have compacted properly.

The debug logs are attached.

siliconman01

The Registry Finder is now finding keys in the HKLM\Software\Wow6432 section. As near as I can tell, it appears that the Registry Finder is working properly now. :)

siliconman01

The keys in the pic below are key errors concerning the TrustedInstaller. I cannot figure out what is finding incorrect on the these key. PT 2009 cannot FIX or REMOVE these keys because of Denied Access or Invalid File. (Yes, I know this is a permission issue).

In addition, the results window is improperly stating what it finally did. It says that it removed 65 keys when in fact it fixed nothing and removed nothing.

HKEY_CLASSES_ROOT\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\@ : Sxs Store Class

HKEY_CLASSES_ROOT\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\AppID : {752073A2-23F2-4396-85F0-8FDB879ED0ED}

HKEY_CLASSES_ROOT\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\{KEY} : {KEY}

HKEY_CLASSES_ROOT\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\LocalServer32\ :

HKEY_CLASSES_ROOT\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\LocalServer32\@ : %systemroot%\servicing\TrustedInstaller.exe

HKEY_CLASSES_ROOT\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\LocalServer32\ThreadingModel : Both

HKEY_LOCAL_MACHINE\Software\classes\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\@ : Sxs Store Class

HKEY_LOCAL_MACHINE\Software\classes\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\AppID : {752073A2-23F2-4396-85F0-8FDB879ED0ED}

HKEY_LOCAL_MACHINE\Software\classes\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\{KEY} : {KEY}

HKEY_LOCAL_MACHINE\Software\classes\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\LocalServer32\ :

HKEY_LOCAL_MACHINE\Software\classes\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\LocalServer32\@ : %systemroot%\servicing\TrustedInstaller.exe

HKEY_LOCAL_MACHINE\Software\classes\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\LocalServer32\ThreadingModel : Both

HKEY_LOCAL_MACHINE\Software\classes\CLSID\{3c6859ce-230b-48a4-be6c-932c0c202048}\LocalServer32\{KEY} : {KEY}

siliconman01

The Shared DLLs shown in the pic below are found in the wrong location as well.

PT 2009 says they are in HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls. They are actually in HKLM\Software\Wow6432\Microsoft\Windows\CurrentVersion\SharedDlls. PT 2009 cannot fix or remove them because of this error in location.

I'm inclined to think that these SharedDlls and the ones posted earlier are not valid detections at all and should not be fixed or removed...even if addressed at their proper location in the registry.

siliconman01

When performing a registry compact, PT stores various .bak_jv16PT files on the system in two or three locations. Would it be possible for PT to create its own "jv16CompactBak" folder and store these all in that folder. That would make it much easier to find them and clear them out on system cleanups.

Unfortunately CCleaner is not fully x64 compatible and cannot be used to custom clear these files in the locations they are currently created because of permission problems.

redseujac

File Finder can find them searching for ".bak_jv16PT" and you can save that search option with "Saved Preferences". The next time searching for those files and removing them (with the file tool) is a piece of cake.

drob

There are still problem with the registry cleaner, at one time it would get stuck during the "deep analysts" stage, at the other it wouldn't, it seems changing the "don't show the scan report" prolongs the scan.

In settings-advanced, trying any of the browsing buttons doest work.

similar to the same issue with file tool-file-select files, doesn't do anything.

added:

Also strange, with "don't show the scan report" checked i get 6 errors, unchecked about 260 errors...

redseujac

siliconman01 wrote
On testing the registry compactor on x64 Vista SP1 Business, the compactor is unable to open HKLM\Security for compaction. The other hives appear to have compacted properly.

The debug logs are attached.

Same in Vista Ultimate SP1 32-bit: message "Failed to open the key HKLM\Security".

So it's NOT a typical x64 Vista SP1 issue.

siliconman01

In the pic below, there are registry items detected that need fixed or removed. If I select FIX, the results window shows that 2 were fixed and 2 were removed. In reality, nothing was fixed or removed. The same items show up in an immediate subsequent scan. Again, it looks like PT is trying to fix with x286 routines instead of x64 routines.

siliconman01

In aggressive mode, the Intel Matrix Storage Manager appears to be falsely detected as needing correction. File C:\Program Files (x86)\Intel\Intel Matrix Storage Manager\PI_IMSM.dll does exist. I've attached the CLSID registry export and a txt file of what PT 2009 is "detecting".

siliconman01

In aggressive mode, the hnetcfg.dll appears to be falsely detected as needing correction. File %SystemRoot%\System32\hnetcfg.dll does exist. I've attached the CLSID registry export and a txt file of what PT 2009 is "detecting".

siliconman01

In aggressive mode, the osbplov.dll appears to be falsely detected as needing correction. File %SystemRoot%\system32\osblprov.dll does exist. I've attached the CLSID registry export and a txt file of what PT 2009 is "detecting".

siliconman01

In aggressive scan, there are 3100+ detections under ActiveX/DDE/COM/DCOM/OLE that when "Fixed" result in various programs failing thereafter. One such program is PerfectDisk 10. It will not even open. These detections are also present for this category in 32-bit systems...both Vista and XP. And are not "new" to PT 2009. In my opinion, this entire category of detections in Aggressive Mode needs major work for reliability purposes. I've attached the keys from my x64 Vista SP1 system.

redseujac

siliconman01 wrote
The Shared DLLs shown in the pic below are found in the wrong location as well.

PT 2009 says they are in HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls. They are actually in HKLM\Software\Wow6432\Microsoft\Windows\CurrentVersion\SharedDlls. PT 2009 cannot fix or remove them because of this error in location.

I'm inclined to think that these SharedDlls and the ones posted earlier are not valid detections at all and should not be fixed or removed...even if addressed at their proper location in the registry.

When running the first time build 546 it found more than 2000 erroneous shared dll's. I couldn't fix them because the progres bar disappeared after 2 seconds or so and nothing happened, so I had to remove them and that was succesful.

Till now I didn't run into problems after that removal. I'll wait and see...

The previous builds didn't find such errors.

Notice my OS is Vista Ultimate SP1 32-bit, so the phenomenon is NOT specific for 64-bit.

siliconman01

Notice my OS is Vista Ultimate SP1 32-bit, so the phenomenon is NOT specific for 64-bit.

What is specific to x64, however, is that they are not being "located properly".

PT 2009 says they are in HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls. They are actually in HKLM\Software\Wow6432\Microsoft\Windows\CurrentVersion\SharedDlls.

This explanation by another registry cleaner makes me very cautious that PT 2009 is not working correctly on shareddlls because all the dlls actually exist in my Common Files\ folder in various shared subfolders such as Microsoft Shared.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\SharedDLLs

This registry key contains references to shared DLLs (Dynamic Link Libraries). DLLs are used to store functions that can be called by programs to perform certain tasks. They can be shared by multiple applications to reduce memory and disk space requirements.

If a shared DLL is deleted or moved to another folder, the functions that are stored in this DLL become inaccessible to applications because the corresponding registry entry in the SharedDLLs section no longer points to the actual location of the DLL. This can cause problems for the applications that use functions stored in the missing DLL file.

If (Pgm name edited out) cannot find a DLL file that is referenced from the SharedDLLs section, the registry entry pointing to this DLL is removed.

If a registry reference to a DLL file is specified as a short filename without the full path, (Pgm name edited out) tries to find the file in all the folders on your hard drives. If the file in question is not found, the registry entry referring to this file is considered invalid and is removed from the registry. If one or more files with that name are found, (Pgm name edited out) does not remove the reference from the registry. If a reference points to a file located on a network drive, (Pgm name edited out) does not remove this reference.