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.

Who creates the ASPNET account in XP?

I have been using a couple of XP VM for development and suddenly I have to develop some ASP.Net. The VMs did not have IIS installed and only has .Net Framework 2 SP2, 3.0, and 3.5 as well as VS2008.

After installing the IIS, I was having trouble to launch some ASP.Net application. Upon some investigation, ASPNET, the default account for IIS 5.1 in XP, was not there!

So who was responsible for creating it?

It turns that one needs to install .Net Framework 1.1 to create that account irrespective if IIS 5.1 is installed or not. What distracted me was the presence of v1.1.4322 sub-directory in the Framework as it turned out it was placed there when I installed .Net Framework 2.0 SP1.

It is not the same as running the installation script for .Net Framework 1.1.