BSOD on Windows 10 20.04 while attempting to eject a verified image write

balenaEtcher
1

I just upgraded Belenaetcher to the current version (v1.5.104) and used it to write a Pine64Pro image to an eMMC. The Pine64 USB stick was plugged into my USB3 hub. Everything went pretty much as expected, until the very end. It finished verifying then said it was ejecting the image, and then I got a BSOD.

It took some doing, but I figured out the minidump tool enough to get it to output the following:

Loading Dump File [r:\082520-13843-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff802`1be00000 PsLoadedModuleList = 0xfffff802`1ca2a2f0
Debug session time: Tue Aug 25 03:36:29.013 2020 (UTC - 4:00)
System Uptime: 13 days 13:10:41.506

... Lots of addresses and stuff elided...

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

FAT_FILE_SYSTEM (23)
    If you see FatExceptionFilter on the stack then the 2nd and 3rd
    parameters are the exception record and context record. Do a .cxr
    on the 3rd parameter and then kb to obtain a more informative stack
    trace.
Arguments:
Arg1: 00000000000e0121
Arg2: ffff908edb27c6e8
Arg3: ffff908edb27bf20
Arg4: fffff8021f14f403

Debugging Details:
------------------


BUGCHECK_CODE:  23

BUGCHECK_P1: e0121

BUGCHECK_P2: ffff908edb27c6e8

BUGCHECK_P3: ffff908edb27bf20

BUGCHECK_P4: fffff8021f14f403

PROCESS_NAME:  balenaEtcher.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

SYMBOL_NAME:  volmgr!VmpQueryUniqueIdInternal+37

MODULE_NAME: volmgr

IMAGE_NAME:  volmgr.sys

FAILURE_BUCKET_ID:  0x23_volmgr!VmpQueryUniqueIdInternal

FAILURE_ID_HASH:  {d0e2cbbb-f6c9-659f-dade-4145ab43ee0a}

Followup:     MachineOwner
---------

Finished dump check

Since nothing on my system is using FAT as far as I know, this was a slightly strange event to me… I’m guessing maybe the system was in the process of trying to make sense of the newly formatted eMMC filesystem when the eject occurred and it really wasn’t happy with the result…?

4

I should note that the image booted successfully, as expected, so I think the write and verify were fine.

6

Hello,
Thanks for providing the logs, can you confirm if disabling the “Eject on success” option in the settings lead to Windows not crashing?

8

Hello,
You should check you system memory with https://www.memtest86.com/ .
Do you have any ant-virus software running ?
Does it BSOD each time you flash ? Does it BSOD if you disable “Eject on success” in the settings ?

11

You may have missed the indication in the log: System Uptime: 13 days 13:10:41.506
This system is 100% rock solid… this is the first BSOD it’s had in years. The issue is not the system.

Every Windows installation has Windows Defender or whatever it is called now. This is all I use.

Hard to know, and I am unwilling to try again. I have other programs I can use to write my images that don’t crash my PC with a BSOD and I will not risk possible corruption to engage in any further testing.

15

Hi, we’re sorry for the trouble. Shall this happen again, we’ll be here!