A site devoted to discussing techniques that promote quality and ethical practices in software development.

Friday, September 24, 2010

A review of Advanced Registry Optimizer 2010

I have been asked for an opinion of this tool called "Advanced Registry Optimizer 2010" (ARO) from Sammsoft. Since I have never used anything like that despite using Windows since 3.0, I decided to give it a try.

The one so 'generously' made available from its web site was only a nobbled version allowing one to correct up to 100 errors. This wasn't made clear in the download. Anyway, the version I tested was 6.0.743.796 and all tests were performed in two Virtual Machines whose guest OS's were: Windows XP SP3 and Windows 7 Ultimate. Furthermore all tests, other than installations, were carried out in LUA (Limited User Account) and disconnected from the network, just in case the program performs call-home operations.

I also deliberately created a key in HKCR\CLSID with incomplete and incorrect information. While the GUID was correct, the ProgID contained incorrect or missing data. This was to test how good this program was.

Although the installation was relatively straight forward there were two areas that were not very satisfactory:
  • The acceptance of askToolbar installation should be a bit more obvious.
  • After successful installation, it should not execute an automatic scan without user's instruction. It ran and I had to use tools like Process Explorer to terminate it immediately. Not nice.
As mentioned all runs were carried in LUA and the program was found to be faulty running in this kind of account settings. Since all programs in Windows 7 and Vista run with standard user security token by default, ARO's end result was identical to that running in XP LUA mode.

This observation was substantiated by comparing the run time log captured using Process Monitor when ARO was executed in XP SP3 and Windows 7.

It did not crash when running in LUA. It simply lied to the users telling them their system had fewer issues than it really was.

Take for example, the specially planned registry settings was not identified when ARO was running in LUA. The reason was that it tried to open the registry key HKCR\CLSID\<My-Test-GUID> with Read/Write access and failed due to lack of sufficient rights when executed in LUA.

The program simply swallowed the error and moved on. This was a very bad programming mistake. The return code was very specific of the problem and when the program was told access was denied, it should have immediately ceased processing and informed the user to run with administrative rights.

Instead, the program just treated that as a non-event and moved on. This resulted in a misdiagnosis.

You can easily test this without these tools. Run ARO in LUA and run it again with "As Administrator" and compare the findings. If the program is functioning correctly, it should report identical error. In this version, they differ drastically.

In fact, if you go to the settings and de-select all settings except "ActiveX and COM" and run it. The chance is that you will get a 0 error when running in LUA and non-zero with administrator's rights. This is because when it opens HKCR it demands Read/Write even in scanning mode. This indicates a possible programming error! Perhaps it is an innocent victim of the ATL registry library problem.

As a result, the product is not functioning.

No comments:

Blog Archive