It is me. I owned your network long ago, and I'm messing with you.
More seriously... This is almost certainly background analysis, tagging, or thumbnail building. MC will list itself
what background tasks are currently active in the Reporter function. You can also check what handles to files MC has open relatively easily in
Process Explorer. Download and unzip Process Explorer and run it. Select Media Center's executable in the list of processes, and open the lower pane by going to
View > Lower Pane. Then choose to view Handles in the lower pane under
View > Lower Pane View > Handles. You can sort the open handles by clicking on the Name or Type columns.
It is also entirely possible that one of these background processes causes an Anti-Virus application to "interfere" and make MC hold the files open for far longer than is required to update the thumbnail cache (or whatever it is doing with the files in the background). If it is updating a thumbnail cache, then this operation can be triggered by simply
viewing the files within a list in MC, alongside perhaps a hundred others.
If you can see Media Center retaining a handle on an file for far longer than is required to update a thumbnail (and you've checked it isn't running background analysis or whatever), then it is worth uninstalling or disabling your Anti-Virus software to see if the issues go away.
When Jim et all tells users to "check their AV software" here, it is often
exactly this happening underneath the covers. MC tries to access a set of files for an operation which should take milliseconds, but then an AV application interferes and locks threads up with their (often buggy) "intercept system filesystem access calls" hooks (which ends up in a race condition that never solves itself). Basically, MC is trying to use the file, but the AV application won't let it until it can scan the file and declare it is clean, but their hooks don't always "catch" all system calls before MC is actually given a handle on the file by the OS (which doesn't care about the AV application's shenanigans). This means the AV application now
cannot scan the file until MC lets it go. It keeps trying and trying but can't get a "lock" on the file, but the code injected hooks they've put in your system also won't let the filesystem give MC access to the file. MC is just trying to access the file and doesn't know why it is taking so long. The OS never errors (as far as it is concerned, it gave MC the file it asked for), and MC is just told "wait" while the AV application tries over and over in vain to get an exclusive handle for the file. It is a classic race condition. In these cases, closing MC will release the handle, which allows the AV application's service to complete the scan, and then the file is freed up milliseconds later.
If this happens with a media file, it isn't the world's biggest deal unless it is happening to a ton of them, or you happen to be trying to play the file (which, since a foreground and not background task, will often "unstick" the race condition, as MC will error if it can't fill its buffer). But when it happens to a bunch of files, or interferes with MC's ability to access its own Library files or registry keys, then hell breaks loose.