AVI files locked and can't be deleted (Logitech webcam codec)

Help & Support
1

I know this has come up on the forum several times and doesn't seem to have led to any conclusions, so I decided to try to dig deep into it.

Fairly frequently, when I try to move or delete video files in DOpus, a file lock prevents me from doing it. I came up with what is (for me) a reproducible test case.

  1. Create 2 folders, c:\Dir1 and c:\Dir2.
  2. Copy several AVI files into them.
  3. Exit DOpus, restart.
  4. Enter each of the folders and try to delete the files.

In one of the folders I'm not able to delete the first file - sometimes the first folder, sometimes the second folder. In the other I can. It seems to be the folder where the blue rotating circle ("Querying file and folder information") rotates for a long time. If I change folders and return, even though the blue circle is gone, the lock remains.

Doing the same sequence in Explorer does not cause a file lock.

Most unlocking software (UnlockIT, IOBit Unlocker and LockHunter, but not Unlocker) in this scenario can see the file lock, and successfully unlock it. However, in normal use scenarios (which I can't reproduce right now), only LockHunter can see the locks (it always detects two) and cannot unlock the file.

If several files are present, it's always the one that's the first AVI alphabetically. Renaming non-AVIs as .avi does not cause them to be locked. Renaming AVIs as another video type, such as MP4, does not stop them being locked. Renaming AVIs as non-video types, such as TXT, DOES stop them being locked.

Deactivating my (Kaspersky) anti-virus made no difference.

Shell extensions in the registry seem to make no difference, which is unsurprising, since they're based on specific file extensions.

All this occurs in any view - detail, list, thumbnail...

I tried removing the "Video Codec" column to see if that was the culprit, but it always comes back when I go back to the folder, even if I save the folder layout. If there's a way to stop that column appearing, it would be a good additional test to do.

2

I should also say that I checked the codecs of the affected files with GSpot. I found:

XviD ISO MPEG-4: Codec installed
Indeo 5.x: Codec not installed
DivX 6.0.3 Fusion (ThermonuclearFusion): Codec installed
XviD 1.0.3: Codec installed
DivX 3 Low-Motion: Codec installed
DivX 5.1.0: Codec installed
S-Mpeg 4 version 3: Codec installed
XviD 1.1.0 Beta 2: Codec installed

3

It could be the codecs, and the splitters (aka demuxers) are equally important (if not more so, depending on what's being extracted from the files). Both types of DLLs are not part of Opus itself, and have a long history of being buggy if you have the wrong version of the wrong DLL installed.

If one of them crashes, or just doesn't close the file it opened, then it could leave the file locked until the process is exited.

Recent versions of Explorer tend to move this stuff into a separate process to avoid the problem (since they can't really fix third party DLLs either). That's something we're looking at. But, ultimately, the issue will be in one of those DLLs.

You can use Process Monitor's stack trace feature to find out which DLLs are involved when a file is being opened and read, which may point you to the problem DLL. There are also tools you can drop a video file on and get a list of DLLs which it will be passed to, although the names of them escape me at the moment.

4

Ok I'll look at Process Monitor and see if I find anything.

I also found an old post on the Old New Thing (archived because Microsoft deleted all the comments), where Raymond Chen talks about something called "oplocks".

http://bytepointer.com/resources/old_new_thing/20120907_208_the_case_of_the_asynchronous_copy_and_delete.htm

5

I have a Process Monitor log. I can't see any DLLs that aren't either Windows-related or DOpus-related. I do note that, for the file that ends up being undeletable, there are more CreateFile calls than CloseFile calls. Might that not leave open handles and prevent deletion? I have the PML log if it will help.

6

Send us the log and details of which file to filter on and we'll take a look.

7

Here's the PML file of the undeletable AVI. It's already filtered so it only shows the events for that file.

Dir1 avi.rar (633.5 KB)

8

Can you send it again without pre-filtering? While we want to initially focus on the file being loaded, once we find those events we may need to see what else is being loaded (e.g. codec/splitter DLLs).

9

Do you want no filter at all? All the events in the system? That could be rather large.

10

All filesystem events. The other types shouldn't matter, although registry is sometimes useful as well.

PML logs tend to compress very well.

You can send the files via cloud storage or WeTransfer or similar. That's probably best anyway, in case there's anything private in the file paths.

11

Apologies for the delay. I just got around to creating a new PML log, without filtering. It captures copying the video from Dir1 to Dir2, restarting DOpus, attempting to delete the video from Dir1 (successful) and from Dir2 (fails due to file lock).
VideoFileLock.rar (12.9 MB)

12

It looks like C:\Windows\System32\lvcod64.dll may be the crashing component.

This looks like a splitter/codec DLL which is part of Logitech's webcam software, and it's being tried when Opus asks for information on the AVI file. It looks like it may be crashing and taking out the thread which is running the query, which is in turn leaving file handles open, but it doesn't take out the whole process.

There are reports of the same DLL crashing other software:

Renaming the DLL is said to stop it causing problems, although that may also mean something else breaks.

(This is all somewhat guesswork, based on the log events and which DLLs were being loaded at the time of different operations on different threads, but the fact it has also crashed other software means there's a good chance it is the issue here.)

1 Like
13

OK let me have a look and see if that cures it. I really don't use that webcam, so it isn't needed.
Thanks!

14

That does indeed seem to have fixed it. So why doesn't the same happen in Explorer? Is Explorer ignoring this codec, or simply not trying to obtain the same info?

15

Why some badly written codec crashes in one process and not in another isn't something could say without the source code to the codec. If you want to take it up with someone, take it up with Logitech who wrote the bad code. Seems it's been crashing a lot of different software, so it's hardly just Opus.