Forced disk unmount causes hung drive handle in Windows 10

[calston]

Not sure what extra information to provide but when the disk is automatically i mounted after writing in Windows 10, the drive letter handle isn’t removed. Re-connecting the USB card reader does recognize the drive but future ejects no longer work properly.

I tested this with two different SD card readers and had the same experience. The automatic ejection should probably have some toggle for if you want to edit files afterwards or whatever mechanism is being used does not seem to be safe. A sync could be triggered rather than an automatic ejection or whatever mechanism Rufus uses because that works fine for me

[lurch]

I wonder if this might be the same thing as #31 ?

[calston]

Sounds like it could be, except the only way I found to recover from the situation is a reboot.

[calston]

This does seem to work now in 1.3, I have no idea if anything changed.

I still think it would be better to make ejecting after write optional and letting people do this on their own terms.

[calston]

Actually, no. I'm still getting strange after effects of the forced ejection. Again I have a device letter that won't un-map from the drive. Usually it just took a few seconds for Explorer to refresh the drive list, but again on ejection the drive letter remains at least until the physical device is removed - but this makes it impossible to know if the ejection was successful.

This is a known issue in the mountutils library used balena-io-modules/mountutils#74

[maxnet]

Usually it just took a few seconds for Explorer

You did close Imager completely before starting explorer?
(while Imager is running we stop the ShellHWDetection Windows service, as it causes popups to appear on screen in which Windows offers the user to format the ext4 partition. Could be Explorer does like to have that service running.)

Could also be that something is still accessing the drive preventing proper unmount, like a virus scanner or the Windows indexer stuff (can run "net stop wsearch" from an admin command prompt before starting imager to see if the last one may be the problem).

[calston]

Since the issue persists long after raspberry pi imager is closed I doubt that's the issue. Explorer is the shell too, so having such a requirement to use this seems impractical, as is disabling search indexing to use it.

That said, looking at the code it appears although the ShellHWDetection service is stopped during a write, it is not started again in the same class instantiation. This could be a mistake.

[maxnet]

That said, looking at the code it appears although the ShellHWDetection service is stopped during a write, it is not started again
in the same class instantiation.

It is started again in the class destructor.
Which will get invoked when you close Imager:

rpi-imager/imagewriter.cpp

Lines 100 to 104 in 755d7dc

	ImageWriter::~ImageWriter()
	{
	#ifdef Q_OS_WIN
	QProcess *p = new QProcess(this);
	p->startDetached("net start ShellHWDetection");

Issue itself is not reproducible to me, so could be timing or other software specific.
I may have a look at what other service we may need to shutdown just during write. Right now it does create a "system volume information" folder on the card for me, which is an indication other services running do are still accessing the SD card and writing to it.

[tdewey-rpi]

Closing as stale. Please raise a new issue if you think this still applies.