Why does explorer tell me the file was opened by the wrong program?
(or why Windows Audio is holding an Event Log file open)
Today’s blog post will be about the “File in use” dialog. You may have encountered this dialog when trying to delete a file that you happened to have already open. In Windows Vista, all you got was “this file is open in another program”. Not very useful, since you then get to figure out which program is holding the file open. In Windows 7 the system will attempt to give you more information by providing the program name, exe name, or…something else…
You can get one of four dialogs:
- “File is open in <program name>”. This is the most common case. Windows tells you exactly which program has locked the file. You can then switch to that program – assuming there is only one copy of that program and it’s running in your session (another user on the same machine could be holding the file open, or if the file is on a network share, it could even be another user!). Then you close it and retry the operation.
- “File is open in <exe name>”. You may get this dialog if the program that is holding the file open is running elevated. Since explorer.exe usually does not run elevated, it cannot read some information it needs to determine the display name of the program, so it gives you the name of the executable file.
- “File is open in another program”. You get this when you try to delete a folder that contains a file that is currently open. This isn’t extremely useful since it doesn’t tell you a) which file is open, or b) which program is holding it open
- “File is open in <service name>”
This one is the most interesting dialog. Why would the Windows Audio service be holding an event log file open?! Madness!
Well, it turns out that there’s only so much Windows can know about who has a file open. The file was really open by the Event Log service, which by default, runs in the same svchost.exe instance as Windows Audio. You can verify this by running “tasklist /svc” in a command prompt:
So how does this work? at the crux of the issue is Restart Manager, a set of APIs that let applications (esp. setup apps/install wizards) query about which program has a certain file in use that they’re trying to update/write to. It also provides APIs to tell those apps to shutdown and restart (the latter requires cooperation on the app’s part to be able to save its state and load this state upon restart). Restart manager however, doesn’t know too much about which part of a svchost instance called CreateFile. All it knows is that a certain svchost instance did it, and so it returns all the names for services running in that svchost instance.
So, that’s why Windows Audio gets blamed for Event Log holding a file open.