Rufus deadlocks without mutex when VDS doesn't respond

[acuteaura]

I'm sure you know Virtual Disk Service dying or getting stuck deactivating happens on occasion again, and there's little you can do about it aside from rebooting.

Rufus could handle this case more gracefully, right now Rufus doesn't

1. acquire a mutex before querying VDS, letting you spawn as many unresponsive no-window instances as you want
2. have any timeout for VDS not responding

This is also the likely cause for #845.

[pbatard]

I'm sure you know Virtual Disk Service dying or getting stuck deactivating happens on occasion

Actually I don't. That'd the first time I hear of this. Do you have reputable sources on that? Or is this something you experienced on some specific machine?

Rufus could handle this case more gracefully

I wouldn't mind. But I also wouldn't mind seeing a log or DebugView output, that illustrates this. I guess I'll see what I can replicate by trying to forcefully kill VDS, but it looks to me like you did experience an issue, yet are not willing to provide a log that would allow to properly investigate, which is annoying.

As a developer, it's REALLY troublesome to try to fix "hear-say". I'd rather try to fix what I see happening through a log or (better) through something that I can replicate (which is also usually tied to having received a comprehensive log).

have any timeout for VDS not responding

Well, if it's really VDS not responding that's the issue, the DebugView output, which was also asked but which the person who reported #845 never provided, should be able to corroborate it. Otherwise, I have to take your word that it's allegedly a VDS issue, which I can't know for certain.

So, really, if you do experience the issue, as it seems you did, I would really appreciate a DebugView log before I go on a wild goose chase with VDS.

[acuteaura]

Do you have reputable sources on that? Or is this something you experienced on some specific machine?

I have it crash like once a month, but I also deal with uncommon storage devices (like an iodd ST400 and iSCSI) a lot.

Otherwise, I have to take your word that it's allegedly a VDS issue, which I can't know for certain.

VDS stuck in "Stopping" after crashed by above mentioned iodd device was a pretty strong indicator. diskmgmt wouldn't open either.

[pbatard]

Thanks for the log.

By the looks of it, it seems more like a loc file issue than anything related to VDS, because the next line you should see is something like:

[34512] loc file not found in current directory - embedded one will be used 

And then there should be bunch more lines related to localization parsing (which we do long before we invoke anything related to VDS, because, obviously, we want to be able to report stuff in a user's preferred language before we do anything else).

I could very much see a freezout occur if you have a malformed rufus.loc in the same directory where you have the executable, so could you please look for that.

VDS stuck in "Stopping" after crashed by above mentioned iodd device was a pretty strong indicator.

Yet, it looks to me like, even if we can envision that log output is delayed somehow, should get a heck of a lot more output before Rufus gets to a stage where it plays with VDS, so, right now, I'm actually not that convinced your issue actually has to do with VDS.

That doesn't mean I'm not going to look into hardening our VDS calls (I agree that adding a timeout, if we can, is probably a good idea), but the DebugView output doesn't really match what I'd expect if your issue was related to VDS...

[acuteaura]

I could very much see a freezout occur if you have a malformed rufus.loc in the same directory where you have the executable, so could you please look for that.

I first considered that winget might've given me a bad binary, so I did actually reproduce this from two executables, one in the Downloads folder and one in %localappdata%/Microsoft/WinGet/Packages/Rufus.Rufus_Microsoft.Winget.Source_8wekyb3d8bbwe. I don't see any adjacent files in either directory.

[cathoderaydude]

For what it's worth, I'm having the same symptom. No rufus.loc in the program folder. Same DebugView output (verbatim, except for userdir path), and when I checked I indeed found Virtual Disk service in "Stopping" state. Also found that Disk Management and diskpart hang on startup. Apparently vds.exe is a protected process that's very hard to kill, so I don't have a way to terminate and restart it to confirm that it's related.

However, I did set up Process Monitor and filter to rufus-4.6.exe, then launched the app. It performs about 1790 various system calls before stopping right after touching vds_ps.dll.

[pbatard]

I'm going to close this issue. I left it open in the hope of seeing VDS issues or something that would make me closer to have anything resembling the various issues that people seem to pin on VDS, but it's pretty clear that, in the absence of anything like that, I just don't have enough time to spend to take shots in the dark at trying to fix an issue that I have never seen happen on my end.

Now, if someone can provide a sure-fire "Do this, then do that, and if you do this you should see the issue" way of replicating the problem, I'll be happy to take another look at this, but considering that my time is far from being unlimited and that I have way too many other issues and improvements to spend it on, it just doesn't make "economical sense" (since I do have to allocate my time in the manner that is likely to bear the most fruit) to pursue this issue right now.