Database fails to migrate with conv tools error 1115

Database fails to migrate with conv1011 tools error 1115
The database is inaccessible after the failed conversion
Prior to migration the database can be accessed and updated.
There are no indication of major corruption that would otherwise cause a conv migration to fail
Database was truncated with 102B utilities before migration
Codepage parameters (-cpinternal) used by the PROUTIL session running conv1011 are same as the original database

Database was previously conv89, conv910

Prior to migration the database can be:

• accessed single user (prowin32 -1)
• PROSERVE started accessed and updated
• PROBKUP online succeeds however restoring the backup hangs, while "(334) Prorest session end" is evident in the lg file
• PROUTIL truncate bi / truncate area
• DBTOOL and PROUTIL idxcheck run both offline and online (no major errors)
• PROUTIL idxbuild completes without error and only changes the PROBKUP offline behaviour which then hangs without GPF

Prior to migration the database:

• Offline PROBKUP cores:

• PROUTIL dbrpr fails with ** Database has the wrong version number. (db: 64, pro: 150). (44) 

The Database Version number in the Master Block is corrupt.

It's not clear how the Master Block stores 64 instead of 8342 (150 + blocksize). The reason that PROUTIL conv fails is that it checks the version number in the Master Block which is why it fails immediately with "Open failed".

The reason that other utilities were able to access this database prior conversion is:

The Database version number is stored in two different places: 

1. Header of each extent. 
2. Master Block.

When a process connects to the database, the version number in each extent is validated. 
On UNIX, the version number in the Master Block is also validated, however this function that does the version number validation is not available on Windows.

In this database, the version numbers in all extent headers were internally checked to be valid, the version number in the Master Block is not, somehow it is stored as 64 and should be 150 + blocksize = 8432.
 
Since the invalid number in the Master Block in not validated for most connections and the other extent version numbers are correct, users that connect to the database through the normal connections do not encounter the database version mismatch error. 

dbrpr and other process (like conv1011) check the Master Block and finding the wrong version number fail and thow an error.

Revert to the pre-conversion database backup and migrate to the required major version with Dump and Load procedures instead.