ImageUSB fails to write at offset ....

[aggielaw]

Good morning all. I have tried three dozen times to write a .bin file to a microSD card over the last couple days. I've used three different microSD cards, all Samsung 32GB Pro cards, two different Windows 7 computers and a Windows 10 computer. The only thing that changes is the location of the failure to write, which varies by card.

Background. The .bin file I am trying to write is a firmware update image provided by a manufacturer. The manufacturer's instructions specifically direct use of ImageUSB (see: http://docs.sotm-audio.com/doku.php?...n_sdcard_image). Although the procedure for formatting new SD cards is different in Win 7 than Win10, I ensured I started with a newly-formatted, FAT32, healthy simple volume. On the Win 10 computer I followed the manufacturer's instructions precisely. I also ensured the write file was extracted and not the compressed .gz file downloaded from the manufacturer's website. I am running ImageUSB as an administrator.

Issue. ImageUSB indicates a full write; however, the moment the write progress says 100% I then get an error in the messages at bottom that says "Failed to write to \\.\PhysicalDrive3 at offset 2879389696 (0xaba00000)." As I mentioned above the numbers following "offset" are different when I try a different card, but always the same error.

Any advice on what this error means and how to fix the problem is greatly appreciated!

Best,
hc

[Richard (PassMark)]

How large is the image?
Even with the write/verify failure, does the SD card still work?

There might also be additional information be additional information if you run ImageUSB in debug mode. To start debug mode add the "-d" command line parameter.

We are not affiliated with SOtM or have knowledge of what they used to create the original image. It seems from the link you provided, the are using a fairly old version of ImageUSB. We do not believe we broke backward capabilities with previous images created with ImageUSB, but you can try to see if an earlier version works.

https://www.osforensics.com/tools/write-usb-images.html

[aggielaw]

Thanks for your quick reply. The image size is 2.68GB. I will try both your recommendations when I get home this evening and report back. Thanks again!

[aggielaw]

I downloaded the old version and received the same error. So, I went to the store and bought a new USB card reader. It is the only thing that has been consistent across all my efforts to write this image. New card reader, same error, same location.

Edit: one other data point, and this occurs across all configurations I've used. After the write fails, Windows sees the drive as RAW instead of FAT32, and requires me to reformat the drive before I can do anything else with it.

Any ideas? Thanks for your continued efforts.

[David (PassMark)]

three different microSD cards, all Samsung 32GB Pro cards

Are you sure these aren't fake counterfeit cards, with much smaller capacity? Where did they come from?

Also you don't need to format the drive before using it with ImageUSB, as the formatting will be completely overwritten by the disk image.

[aggielaw]

I purchased all the cards through Amazon (here in the US), and at different times, so I would think it unlikely that they are all fake. Tonight I also tried a Samsung 32GB EVO card, and still get the same errors. Moments ago I tried partitioning the card at 14.9GB and 32k file allocation size to see if that would help, but I still receive the same error.

Edit: I've now run ImageUSB in debug mode, and found something interesting. ImageUSB detects 4 partitions on the SD card despite the fact I formatted the card as a simple volume with only 1 partition of the full size of the drive (post-formatted).

Does this information help you troubleshoot?

Thanks again.

[David (PassMark)]

Can you Email us the log file. Or attach it to the post.

[aggielaw]

Certainly, and apologies for not thinking to do it in the last post.

[David (PassMark)]

I am wondering if the card reader only allow full sectors to be written.

Image Size: 2,880,054,499 Bytes
Data written before error: 2,879,389,696 bytes
Data remaining: 664,803 byes.

Error 87 (from the log) means parameter is incorrect on the Microsoft WriteFile function.
Possible reasons for error 87 include.
1) The file size is too large (e.g. > 16TB in NTFS).
2) The device was opened in non-buffered mode and the write length isn't a multiple of the drive's sector size
3) The device was opened for asynchronous I/O, but WriteFile is then called without the OVERLAPPED structure.
4) A write was attempted when the volume hasn't been locked with winioctl-fsctl_lock_volume

But none of these really apply in this case. I am suspecting a problem with the card reader's device driver. Maybe we can try padding out the last write command to be a full sector, or padding the source file out to be a multiple of a full sector (e.g. append a bunch of zeros on the end).

[aggielaw]

I don't think I can alter the .img file. How would I pad out the last write command to be a full sector?

[Richard (PassMark)]

So...

... seems you missed a step in from their directions. When trying to replicate your problem, I notice the download is the same size of the file you mentioned in your previous post.

Did you not extract the contents of the .gz archive file? And just instead remove the .gz extension from their image download? This is likely be a problem. After extracting the contents of the file, it is close to 8GB in size and size on disk is a clean multiple of sector size.

[aggielaw]

Solved. Richard, I couldn't understand how you got the file to unpack to 8GB. On a whim, I tried unpacking the .img file, which I had already unpacked from the .gz file. It didn't work in WinZIP, which reported I had already unpacked the file. However, 7-ZIP unpacked the file to its full size. It stripped the resulting file of its extension, so I renamed the file with the .img extension and it ImageUSB wrote the file to a UFD with no issue.

I created a Youtube video explaining the issue and how I solved it at: https://youtu.be/ty_HN2gqJtQ

Thanks Richard and David for your help. I repped you in the comments of the video. I hope it brings you more customers.

[David (PassMark)]

Glad you sorted it out.
While writing the zipped up file was never going to work, it is a bit surprising that it failed with a write error. It really shouldn't be required that the file size be a multiple of the sector size. Still if it works now, we aren't going to 'fix' it.