1. plumsauce's Avatar
    edit: this post was originally automarked as spam so the ensuing edited version might not be as correct as it could be.

    The saga goes like this:

    After days of diagnosing usb driver problems I was finally able to goto version 3057 on a Passport. After I realised I was bricking it by using a Z30 autoloader. It went first try after downloading the correct Passport autoloader.

    Fine, ... go ahead and do the Classic next with the Z30 autoloader since the connection and cable were known good. No sense tempting fate by rebooting.

    As part of earlier trouble shooting of the driver problems, the source 7z had already been checked against the posted SHA-1 checksum

    Hours of fun ensue where the file cause a red blink with the pattern 10111011. Reboots solve nothing. Deliberate bricking as a preliminary solves nothing. New cable solves nothing. The entire flash procedure seems to go swimmingly until it reaches "security error on device" when the flash is run with -V4.

    In parallel a fresh copy is being downloaded from MEGA to a fast server and the file being transferred locally over RDP.

    The resulting 7z is exactly the same length. The extracted exe is again the same length to the byte.

    Copy it from one local laptop with the software archive directory to another local laptop which is the unit connected to the Classic.

    Do a byte for byte compare .... BINGO .... differences all over the place.

    Don't forget ... the first 7z was already compared to the published SHA-1 hash and passed. 7zip also happily reported no corruption.

    Well, first crack with the new copy and the Classic booted .... sigh.

    What could have happened in the chain ...

    - chrome likes to use multipart downloads. if it or the mega server don't splice it properly a problem can occur.

    - both laptops have compressed drives. maybe NTFS compression code has a latent bug somewhere ... unlikely as there would have been howls long ago

    If you can connect via usb but the autoload of the correct file is causing problems, consider downloading and trying again.

    I am thankful for the existence of the autoloaders, so this is only a suggestion, but I would consider publishing the SHA-1 hash of the .exe as a .txt file in the 7z file. That way, the hash is directly against the .exe and not the resulting 7z.

    Again, just a suggestion.
    01-24-18 05:20 AM
  2. Dunt Dunt Dunt's Avatar
    Good tip for any that are downloading via different file share options and that are running into problems....

    1) Make sure you are downloading the right Autoloader for your device.
    2) If it doesn't work the first time, download it again and try again.
    3) Still not working try from another source.... I always downloaded the files from BlackBerry and combined them to make my own. Update servers still hosting different versions?
    01-24-18 07:40 AM
  3. thurask's Avatar
    If you want to diagnose the exe file itself, open a terminal (cmd or PowerShell) and run "name_of_autoloader fileinfo". They come with an internal self-test mode, so if anything went wrong it should notify you.
    Dunt Dunt Dunt likes this.
    01-24-18 11:14 AM
  4. plumsauce's Avatar
    Thanks for that.

    I ran with the parameter fileinfo much earlier in the process as a means of diagnosing why the autoloader was not running at all. When I finally got it to run, I neglected to run it again with fileinfo for its intended purpose.
    01-28-18 09:21 PM
  5. plumsauce's Avatar
    FWIW ...

    It happened again because I left the wrong version of the autoloader on the laptop. This time I recognised the problem much faster.

    With both versions on the laptop, ran a file compare, and they were different.

    The screen output from running them with the fileinfo parameter is identical in every respect.

    I suspect that running the file with that parameter only reads some header information and does not really run a self test. Certainly, it should take longer if it is doing a hash on itself. Therefore if there is corruption beyond the header, it will still output that screen. Only if the file is corrupted in such a way as to interfere with the part of the executable that is reponsible for handling the fileinfo command will there be any indication of trouble.

    The proof would be in running the autoloader with fileinfo and watching the disk activity with filemon. A self check would require that every sector of the file is visited in sequential order. If that does not happen, it is not generating a hash against the file image.
    02-09-18 02:13 AM
  6. plumsauce's Avatar
    ps.

    running with fileinfo generates almost no cpu activity. if the autoloader were calculating a hash as a self check, at least one core would be expected to have significant cpu activity.
    02-09-18 02:17 AM

Similar Threads

  1. Replies: 5
    Last Post: 06-01-18, 02:44 PM
  2. Media player, file manager
    By DonNirmal in forum BlackBerry DTEK50
    Replies: 12
    Last Post: 04-25-18, 07:18 PM
  3. Shareit need in z10
    By Raj Sekhar in forum Android Apps (Amazon Store & APK Files)
    Replies: 2
    Last Post: 01-31-18, 11:28 AM
  4. Blackberry Keyone were to buy in Manila.
    By Jose Fores Po in forum BlackBerry KEYone
    Replies: 2
    Last Post: 01-25-18, 08:57 AM
  5. SMSC Center is not available in BBK1.
    By Vaibhavbabhale in forum Ask a Question
    Replies: 1
    Last Post: 01-23-18, 07:29 PM
LINK TO POST COPIED TO CLIPBOARD