MBR track gets partly overwritten by System Mechanic Pro under Win7

[thomabrown]

Running AiR-BOOT v.1.1.0 debug version (See ticket # 11), booting to Windows 7 with System Mechanic Pro V 12 from Iolo (​http://www.iolo.com)
overwrites part of AiR-BOOT's track 0 with what seems to be a copy of the MBR sector. This results in a failure on the next boot with:

• The configuration of AiR-BOOT is not intact anymore. Please boot via AiR-BOOT disc to restore AiR-BOOT. System halted. Please press RESET.

Just booting Win 7 with System Mechanic Pro will do this. It seems to happen before the appearance of the Win7 logon screen. If I restart Win 7 from the logon screen, the damage has already been done. If I uninstall SM Pro, the problem goes away. I have attached two image files produced with DFSee V 11.7. Comparing the "good" one that boots OK with the "bad" one that does not, the problem seems to be at offset x'7000'.

This system is running both eCS and Win7 from a Plextor PX-256M5Pro 256 GiB SATA SSD.

Can the AiR-BOOT environment be protected against this?

I think my chances of getting Iolo to fix their software are rather low. My preliminary report of the problem resulted in instruction for total removal of their software.

Thanks!

[thomabrown]

DFSee image of good track 0. Boots OK.

[thomabrown]

DFSee image of track 0 with damage at x'7000'. Won't boot.

[Ben Rietbroek]

Replying to thomabrown:

Running AiR-BOOT v.1.1.0 debug version (See ticket # 11), booting to Windows 7 with System Mechanic Pro V 12 from Iolo (​http://www.iolo.com)
overwrites part of AiR-BOOT's track 0 with what seems to be a copy of the MBR sector. This results in a failure on the next boot with:

• The configuration of AiR-BOOT is not intact anymore. Please boot via AiR-BOOT disc to restore AiR-BOOT. System halted. Please press RESET.

Just booting Win 7 with System Mechanic Pro will do this. It seems to happen before the appearance of the Win7 logon screen. If I restart Win 7 from the logon screen, the damage has already been done. If I uninstall SM Pro, the problem goes away. I have attached two image files produced with DFSee V 11.7. Comparing the "good" one that boots OK with the "bad" one that does not, the problem seems to be at offset x'7000'.

This system is running both eCS and Win7 from a Plextor PX-256M5Pro 256 GiB SATA SSD.

Can the AiR-BOOT environment be protected against this?

I think my chances of getting Iolo to fix their software are rather low. My preliminary report of the problem resulted in instruction for total removal of their software.

Thanks!

Hi T(h)om,

Yep, this software stores a copy of the MBR at location 0x7000.
This location is in the middle of AiR-BOOT's Internal Partition Table.
(Which is CRC-protected)

If this software has an option to disable making a backup of the MBR, enabling that
will probably fix the issue. AiR-BOOT also makes a copy of the MBR, so you don't
lose recovery possibilities.

If is does not have such an option, then the question is where they make the MBR backup.
It could be they modified the win7-loader in the PBR, in which case you can probably
disable it by restoring the original win7-loader.

To determine if they patched the win7-loader you can do the following:

• boot win7
• make a backup of track0 with winimage like you did for this ticket
• install the software

It could be that they already make a copy of the MBR at this point.
So make another image of track0 with winimage and see if location 0x7000
contains an MBR copy. If so, replace track0 with the image you made before
installing the software. This will restore AB.

• now reboot

AB should work because either it was untouched by the software or
you restored it with winimage.

• start win7 and when it is loading immediately press hard reset

So you need to time this reset to happen just after the win7-loader passed
control to the kernel loader.
If they patched the win7 loader, AB is now corrupted.

This means you can probably solve the issue by restoring the original win7-loader.
However, there is a possibility that this software checks for this and reinstalls it's patch.

If AB still works, they make the copy of the MBR at some other level, maybe a win7 service
you can disable.

You're lucky this software did not store the copy at the last sector of track0.
That would have overwritten the OS/2 Master LVM-record !
(Which can easily be repaired with the Disk Utility on the eCS CD-ROM)

Technically this issue can be fixed by having AB store it's MBR copy at the same
location. But that will break the 'well-known' location of AB's MBR copy which
is just below the master LVM-record. It also would require shuffling around AB's
internal structure, breaking compatibility with previous releases and needing the
installer to handle the change of the internal structure. So I will consider this
'compatibility enhancement' for future versions.

But there may be some other less intruding solutions.
That task is activated and back-grounded :-)

Thanks for the outstanding pre-analysis !
Saved me from getting this software and trying to replicate the issue.