The writer process ended unexpectedly.

Hi there,

Currently working with Etcher 1.5.70 on Windows 10 Family I can’t flash any SD card.

The result is always the same : “The writer process ended unexpectedly.”

He re is my logging output : log.log (9.5 KB)

Could you please help me with that ?

I already tried older Etcher versions, 3 different SD card, and even a second computer running Windows 10 Pro with the exact same result.

Thanks by advance.

Hey, are you running under an admin or normal user account? The flashing process needs to be able to elevate to admin privileges in order to write directly to the SD card

Definitely admin yes.

This thing is driving me crazy, I found countless posts about this issue and tryed everything with no success.

Hello, I imagine you might have already tried the solutions described in https://github.com/balena-io/etcher/issues?utf8=✓&q=is%3Aissue+is%3Aopen+The+writer+process+ended+unexpectedly if so, could you reproduce the error and send us the output from your devtools after the error has happened (to open the devtools console on windows simply press ctrl + shift + i)

Edit:
Sorry I didn’t notice you did already attach the logs in your initial message. Having a look at those, seems like the root issue is this diskpart error: Couldn't clean the drive, Command failed: diskpart We will keep looking into this and get back to you as soon as we figure out what may cause the error.

I manage to clean my SD cards with diskpart.

Tryed flashing with win32 disk manager and it worked perfectly.

Tryed again with etcher and it failed again.

Note that after failure my SD card isn’t recognized by my computer anymore.
Disk manager tells me the volume isn’t allocated anymore and I can fix it only with diskpart so far.

Hi, the SD card isn’t recognized by the computer anymore due to the nature of the image - the partition need to be made so that Windows can read them, otherwise you won’t see the target in the file explorer after flashing.
Does the image require special treatment (e.g. to make it bootable) to your knowledge? Some images need extra steps in order to function properly and for that reason, Etcher isn’t the best tool (yet :slight_smile: ) for those, as it just copies raw data 1:1 like dd does.
Also, on Windows we wait writing the first bytes of the image because we can’t get exclusive access to the target, which means Windows would try mounting it mid-flash, and it can cause some inconsistencies on the verification.
Did you try using the image you just flashed to check that it works even though the verification fails?

I wanted to comment I am having the same issue on my Win10 machine. I’m using balenaEtcher v1.5.70 on my windows machine which is running an Evaluation copy, Build 19536.rs_prelease.191211-1446.

Source: 2019-09-26-raspbian-buster-full
Target: 64GB SanDisk Extreme microSD (SDSQXA2-064G-GN6MA)

I get the same results as the OP. I have tried;

  • I checked the source file Hash (good)
  • Verified I am running as admin
  • I formatted the microSD to exFAT (Etcher when it starts wipes this)
  • I extracted the ISO from the Zipped file
  • Used a different USB adaptor
  • Rebooted my PC
  • Tried several other images (Fedora, BlackArch & Kali).
  • Used a USB drive rather than the SD card (Innostor USB 4.03 GB)

I gave up on Etcher and tried Rufus (v3.1.1320) and it seemed to work fine.

UPDATE
Problem Solved, at least in my case. I have Controlled Folder Access enabled. For some reason balenaEtcher was trying to write to a folder under My Documents (In my case this is D:). I authorized it to access that controlled folder and it was able to burn the file. I’m uninstalling the program for now, I don’t really like a program writing to My Documents without a good reason.

Hi @truzzi,

Welcome to the forum.

Tank you for posting this detailed information on the error and the update on how you fixed it. The reason balenaEtcher is writting to your Documents folder, is because it is storing its settings into a subfolder of your documents folder.

Best Regards,

Wouldn’t it be better if balenaEtcher wrote to it’s own folder? I’ve since removed the program but isn’t that somewhere under c:\Users\name\xxx?

Since balenaEtcher failed to complete, is there some file floating around somewhere in My Documents that needs to be removed?

Hi, if there are leftover files, they are likely to be in the folder C:\Users\<username>\AppData\Local\. That’s typically where electron apps store config files by default, and compatibility is the reason we kept that location.

A couple of things;

  1. I noticed that the removal process was not complete. I used the Apps & Features to select and remove balenaEtcher. However, I saw that it left behind:
    C:\Users<username>\AppData\Local\balena-etcher-updater\installer.exe

  2. Under protected folders, it says “Windows system folders are protected by default.” I wouldn’t expect C:\Users<username>\AppData\Local\ to fall under that grouping. In addition I am protecting;

  • D:\
  • C:\Users\Public\Documents
  • D:\My Pictures
  • C:\Users\Public\Videos
  • C:\Users<username>\Videos
  • D:\Music
  • C:\Users\Public\Music
  • C:\Users<username>\Favorites

So I don’t understand why Controlled Folders would stop balenaEtcher if it is only using the AppData folder(s). That is where it belongs.

While the cause isn’t clear, it is probably due to the fact that Etcher uses system resources to perform actions such as writing, which behave differently on the different OSes.
For example on Windows we circumvent the lack of exclusive access to targets by offsetting the first bytes written and writing them at last to prevent Windows mounting the image mid-flash.
Controlled folder access checks the applications against a “known list”, and every new version of Etcher unfortunately counts as a new application unless it’s updated via auto-updates (which we trigger ourselves for specific versions), which means it’ll be flagged as a threat more often than not even though it is not.

As for the leftover files, there’s not much we can do, it’s just how the installer works as of now. We’re still improving all the bits and pieces though, so it might be something we’ll try to revisit in the future