Process/thread sometimes never exits even when forcibly terminated

[arukateru]

Process/thread sometimes never exits even when forcibly terminated

[arukateru]

Just had this same problem with different USB drive and different program. After some research it seems you simply cannot exit a process that has pending I/O in Win32 so I don't think this is fixable. Though, I'm not sure why they would have pending IO to begin with ? Maybe I'm just unlucky and have two trashy USB drives? I would close this issue but idk, maybe there is some way to fix it, I am not an advanced programmer

[JonnyTech]

Seems to only be a problem in the latest version.
Log
Rufus x86 v3.18.1877

FYI the latest version is v4.4

[arukateru]

After buying a brand new USB drive and trying a different burning program, I tried again and got a similar issue, the program just completely froze part way through, becoming unterminatable and stuck on "exiting" until I forcibly removed the drive...this time it crashed and so I decided to look in the event log and I see that my event log is FULL of this error: Application popup: Windows - Delayed Write Failed : Exception Processing Message 0xc0000222 - Unexpected parameters. The crash reason is that the application "stopped responding to Windows". Doing some research, it seems that a lot of programs don't have any way to handle this error, and I think that's why Rufus and other programs crash. I don't know why it would be happening with a brand new, name-brand flash drive. Perhaps my installation image is corrupt. Anyways, I guess that my issue more specifically now would be: handling of delayed write fail error should be implemented into Rufus to improve stability and user experience

[pbatard]

Just had this same problem with different USB drive and different program.

Which confirms that this is not a Rufus specific issue.

handling of delayed write fail error should be implemented into Rufus to improve stability and user experience

Rufus handles errors that are reported by the system APIs. Even when using Overlapped, there's no such thing as issuing a WriteFile(), getting a success code from Windows, and distrusting that success code to read (from where?!?) a different code after some ill-defined interval.

At any rate, I'll be happy to accept a patch if you want to send one. If not, and considering that you are the only person to report this issue, which you seem to encounter with multiple applications and which therefore would tend to hint not at an application problem but at an issue with your computer that you should really look into, I'm just going to ignore what seems to be a purely environmental issue on your side.

Especially, if an application like Rufus appears to get stuck whereas nobody else appear to experience a similar issue, you clearly have an I/O problem that you want to fix.