When Opus tries to read metadata of any .avi file on my system it never finishes, the file handle gets stuck as open and some side issue occur (all label icons are not rendered anymore, same for the metadata of any other video file). A restart of the process solves the issue.
Explorer has no problem with these files.
This issue has persisted after Windows 10 version upgrades, video driver updates, codec updates and codec settings changes to try and set Microsoft default codecs for AVI. This later change sort of improved things, as the issue would not occur simple upon navigating to a directory with AVI files as it did before, but renaming an AVI file is then enough to trigger the issue (in Explorer I can rename them fine and no issue happens).
I have Windows Media Player disabled with "Turn Windows features on or off", but early this year, when trying to solve this issue, I enabled it to try what it said on this FAQ and it did not make a difference.
If any dump file be analyzed, I would rather it be to investigate this problem instead of the help file problem, as this is a lot more annoying to me.
Let me know if you will take the case, so I can prepare and send some dumps. (Should they be taken before and after the problem is triggered or only after?)
If you can tell us steps that reproduce the problem then we can try doing the same. (If you have a second PC you can test with, it's worth checking if the same thing happens on that, as if it only happens on one PC, it probably won't happen for us either.)
The underlying issue is probably the AVI demuxer (Windows or third party) crashing when looking at a particular file, or a file in a particular state (e.g. half-downloaded files will crash a lot of bad demuxer components).
If you are able to send dumps now, please do still send one for the other issue. The two things may turn out related it something on your system is hooking into other processes and changing things in a way which caused both problems, even if they don't seem related.
I used FFmpeg to validate a test file and it did not raise any error. I am confident that the file is not the problem.
Opus does load correctly the metadata after a hard reset, but then a simple refresh triggers the issue. Have you seen a case like this before? (I did a search for "demuxer" and saw some of your replies, but I am not sure if the cases are that similar to this.)
The file may be valid according to FFmpeg but still trigger a problem in whichever demuxer is being used. It may not be the file as well, but we can't rule that out yet.
That sounds like the demuxer may be leaving the file locked after the first time it reads the metadata, so that subsequent attempts cannot re-open the file. Have you checked if that might be happening?
e.g. Try copying the file, exit Opus and restart, make sure the metadata is only read once, then try to delete the file. If it's locked against deletion then the problem appears to start with the first time the file is examined.
Strange. At least as far as Opus is concerned, reading the metadata is the same each time. If the file itself isn't changing, and isn't being locked, then the result should be the same the first and second times.
Of course, the demuxer could be doing something strange that we don't/can't know about, or something else on the system may be causing problems.
The dump shows that msvfw32.dll (Microsoft Video for Windows, part of the OS) is locked up waiting for something to be released by another thread while trying to open the AVI file.
It's definitely possible that both issues are caused by the same underlying problem, since the Help viewer issue is also caused by a thread waiting for something to be released by another. (I've followed up on that in the thread for that problem.)
It's also possible they're two separate problems, and it could be that the DLL is waiting on something that the earlier call into the very same DLL left locked. If that is the case, it's probably just a bug in the DLL which we can't do much about, other than try to work out if particular files cause it to do that.
I also wonder about the general state of this machine as the system DLLs have very strange dates, which is unusual at least. Windows 10 System DLLs are usually dated in the last few years, but yours have dates ranging from the 1970s through to the distant future of 2105. Maybe something just messed up the dates in that folder, but it's quite strange, and could affect OS patching. (I am not sure if OS patching relies on the dates or not. It may just use the versions.)
I checked the dates on the files and they appear fine. I took the dump with Process Hacker, not with Windows' Process Manager. Maybe that is the source of the different dates? Other than that, only a very nasty rootkit could fake the dates for me, I guess.
