5 ms·

Microsoft reveals why Windows 11 keeps saying a file is in use after closing app

29 points by thunderbong 4mo ago

no-name-here 4mo ago
It feels like the article is repeating information from some other source, but I don’t see such a source linked? (also note that this site is not associated with Microsoft.)
- OptionOfT 4mo ago
  https://www.youtube.com/watch?v=DULHyCygDt4 https://www.youtube.com/watch?v=DULHyCygDt4 This is the video this article is based on. But you're right, source attribution is horrible in this article. And in every other article these days. It is full of URLs that link to other articles on THAT website, sometimes categories, often these links are auto-generated. Everything to keep you into their ecosystem, at the cost of quality of journalism.
snarfy 4mo ago
But they can't be bothered to tell which process is holding it, not even a damn PID. C'mon guys, bare minimum here, and this issue has been there for decades. It's great you added file locksmith to powertoys but that should be a built in OS feature for many, many years now.
- dmaginas 4mo ago
  Maybe the Restart Manager API (RmStartSession/RmRegisterResources/RmGetList) can return the list of processes that hlod a file open. Is available since Vista. The Shell UI just doesn't call it.
Someone1234 4mo ago
For most here, I don't think this article contains new information. The actual interesting discussion, to me, is why Microsoft won't show WHO is dangling the handle open when the user tries to interact with a file via Windows' UI. To understand that, we have to look at a BSOD change Microsoft made in Windows 8: In Windows 2K, XP, Vista, and 7 the BSOD would tell you exactly WHO was causing your BSOD (i.e. which module). Which was incredibly helpful, when you could see it was a e.g. Creative sound driver, or Nvidia graphics driver. Then in Windows 8/8.1 they went to the "sad face" simplified BSOD screen. From then on in order to see which module it originated in, you had to load the mini-dump into WinDbg (which almost no users would/could do). What I am saying is: Microsoft went out of their way to shield their partners (OEMs/hardware vendors) from criticism with that BSOD UI change. So it seems unlikely they'd make a change to the "File Locked" UI that would essentially do the same thing: Open up their partners to criticism for their [bad] software (e.g. anti-virus/anti-malware/corporate compliance/etc). Then tack on that Microsoft's own software may be some misbehaving software; and they'd essentially be telling on themselves. OneDrive in particular, I've seen in that list a lot (but I could write paragraphs on what a turd/abandonware OneDrive is).
- FormFollowsFunc 4mo ago
  That’s a reasonable explanation. It would be so easy for them to show the offending application rather than the user closing all applications and it’s still locked and then having to restart Windows.
- arcfour 4mo ago
  But the offending module is not necessarily the module listed in the BSOD. It could be a victim too, one that got its memory corrupted by someone else. That's one reason why they removed it, because it was causing end users to blame vendors/MS when they often had nothing to do with whatever the problem was.
  - Someone1234 4mo ago
    That edge case is certainly their official excuse. Ultimately to determine the underlying root-cause you'd still need to dig this same information out, and all they've done is moved the starting line behind several walls. In essence adding extra work, without solving this edge case/issue. Regardless of if the information is in the BSOD, Event Log, or only via WinDbg, understanding the information relies on the expertise of the person reviewing/contextualizing it. They've gone out of their way to make contextualizing it harder. For example, to determine if it is a direct failure or an associative failure (e.g. RAM failing causing different BSODs in unrelated modules), you want that context to be obvious. But without the module being in the Event Logs, you're now loading up half a dozen MiniDumps in WinDbg to find that same very key information - which people may miss or fail to do. What I am saying is: If we believe that excuse (which I don't), they've done absolutely nothing to address it and just made that same problem worse with their childish games.
  - mysterydip 4mo ago
    while not root cause, wouldn’t a module having corrupted memory still be an issue with either the OS (for not protecting it) or the module (for not sanitizing input)?
    - arcfour 4mo ago
petilon 4mo ago
On Linux if a file can't be edited because some process is holding it open you can just mv the file to /tmp and create a new file in its place. The process that has it open is unaffected because the handle is independent of the path. On Windows a file that is open in an application cannot be moved, plus it won't tell you which process has it open. Yes you can use some sysinternals tool but this is basic info that should be immediately available without installing some additional tools.
- 1718627440 4mo ago
  You can also just unlink it.
- 1718627440 4mo ago
  > because the handle is independent of the path. This makes me wonder, what happens [EDIT: on Windows] when a program uses a file, which more than a single hardlink points to, and you want to remove one of them. Does it matter, through which hardlink the file gets opened or are all the hardlinks prevented from being unlinked?
  - Chu4eeno 4mo ago
    On Linux you can delete all hardlinks to open files. What you can't do is modify a file that's executing (program or library), then you get ETXTBSY.
    - 1718627440 4mo ago
      My question was about Windows, yeah on Linux it obviously doesn't matter, because you can unlink it even if there is only a single hardlink. My bad, I should have written it. > What you can't do is modify a file that's executing (program or library), then you get ETXTBSY. Why can't you? Couldn't it do the same thing and just keep it in memory? Edit: Actually on my system, I can start a program, unlink it and keep using it just fine. I wonder what case you are referring to. ETXTBSY isn't even descriped in unlink(2), but it is in unlink(3posix): ETXTBSY - The entry to be unlinked is the last directory entry to a pure procedure (shared text) file that is being executed.
jFriedensreich 4mo ago
This issue was what had me give up on windows forever and its been around since forever. There are many situations when there is just no way to release files except restart. When the basics don't work nothing else even matters.
hjkl0 4mo ago
“Reveals” is a very strange choice here. Was it previously a secret that they now decided to share? Was it previously unknown and only now discovered? Really, it’s just an overly fluffy guide for using Sysinternals utilities to help fix the issue. With a heading that is criminally click-baity.
atermentis 4mo ago
[flagged]
Eddy_Viscosity2 4mo ago
On a possibly related issue, is this the same thing that cause the 'USB drive is still in use' message when you try to eject a USB drive even when every application is closed? If so, does anyone know a fix for it?
- 1718627440 4mo ago
  On a drive there is also the filesystem, which might not be finished with its work. When a program writes to the disk it gets buffered by the OS/filesystem driver first, so that the program can finish, before the data is actually on the disk. So there is no fix, because there is nothing to fix. If you remove the device before the OS tells you you can, you risk missing data or corruption.

29 points by thunderbong 4mo ago

It feels like the article is repeating information from some other source, but I don’t see such a source linked? (also note that this site is not associated with Microsoft.)

OptionOfT 4mo ago
https://www.youtube.com/watch?v=DULHyCygDt4 https://www.youtube.com/watch?v=DULHyCygDt4 This is the video this article is based on. But you're right, source attribution is horrible in this article. And in every other article these days. It is full of URLs that link to other articles on THAT website, sometimes categories, often these links are auto-generated. Everything to keep you into their ecosystem, at the cost of quality of journalism.

snarfy 4mo ago

But they can't be bothered to tell which process is holding it, not even a damn PID. C'mon guys, bare minimum here, and this issue has been there for decades. It's great you added file locksmith to powertoys but that should be a built in OS feature for many, many years now.

dmaginas 4mo ago
Maybe the Restart Manager API (RmStartSession/RmRegisterResources/RmGetList) can return the list of processes that hlod a file open. Is available since Vista. The Shell UI just doesn't call it.

Someone1234 4mo ago

For most here, I don't think this article contains new information. The actual interesting discussion, to me, is why Microsoft won't show WHO is dangling the handle open when the user tries to interact with a file via Windows' UI. To understand that, we have to look at a BSOD change Microsoft made in Windows 8: In Windows 2K, XP, Vista, and 7 the BSOD would tell you exactly WHO was causing your BSOD (i.e. which module). Which was incredibly helpful, when you could see it was a e.g. Creative sound driver, or Nvidia graphics driver. Then in Windows 8/8.1 they went to the "sad face" simplified BSOD screen. From then on in order to see which module it originated in, you had to load the mini-dump into WinDbg (which almost no users would/could do). What I am saying is: Microsoft went out of their way to shield their partners (OEMs/hardware vendors) from criticism with that BSOD UI change. So it seems unlikely they'd make a change to the "File Locked" UI that would essentially do the same thing: Open up their partners to criticism for their [bad] software (e.g. anti-virus/anti-malware/corporate compliance/etc). Then tack on that Microsoft's own software may be some misbehaving software; and they'd essentially be telling on themselves. OneDrive in particular, I've seen in that list a lot (but I could write paragraphs on what a turd/abandonware OneDrive is).

FormFollowsFunc 4mo ago
That’s a reasonable explanation. It would be so easy for them to show the offending application rather than the user closing all applications and it’s still locked and then having to restart Windows.
arcfour 4mo ago
But the offending module is not necessarily the module listed in the BSOD. It could be a victim too, one that got its memory corrupted by someone else. That's one reason why they removed it, because it was causing end users to blame vendors/MS when they often had nothing to do with whatever the problem was.
- Someone1234 4mo ago
  That edge case is certainly their official excuse. Ultimately to determine the underlying root-cause you'd still need to dig this same information out, and all they've done is moved the starting line behind several walls. In essence adding extra work, without solving this edge case/issue. Regardless of if the information is in the BSOD, Event Log, or only via WinDbg, understanding the information relies on the expertise of the person reviewing/contextualizing it. They've gone out of their way to make contextualizing it harder. For example, to determine if it is a direct failure or an associative failure (e.g. RAM failing causing different BSODs in unrelated modules), you want that context to be obvious. But without the module being in the Event Logs, you're now loading up half a dozen MiniDumps in WinDbg to find that same very key information - which people may miss or fail to do. What I am saying is: If we believe that excuse (which I don't), they've done absolutely nothing to address it and just made that same problem worse with their childish games.
- mysterydip 4mo ago
  while not root cause, wouldn’t a module having corrupted memory still be an issue with either the OS (for not protecting it) or the module (for not sanitizing input)?
  - arcfour 4mo ago

petilon 4mo ago

On Linux if a file can't be edited because some process is holding it open you can just mv the file to /tmp and create a new file in its place. The process that has it open is unaffected because the handle is independent of the path. On Windows a file that is open in an application cannot be moved, plus it won't tell you which process has it open. Yes you can use some sysinternals tool but this is basic info that should be immediately available without installing some additional tools.

1718627440 4mo ago
You can also just unlink it.
1718627440 4mo ago
> because the handle is independent of the path. This makes me wonder, what happens [EDIT: on Windows] when a program uses a file, which more than a single hardlink points to, and you want to remove one of them. Does it matter, through which hardlink the file gets opened or are all the hardlinks prevented from being unlinked?
- Chu4eeno 4mo ago
  On Linux you can delete all hardlinks to open files. What you can't do is modify a file that's executing (program or library), then you get ETXTBSY.
  - 1718627440 4mo ago
    My question was about Windows, yeah on Linux it obviously doesn't matter, because you can unlink it even if there is only a single hardlink. My bad, I should have written it. > What you can't do is modify a file that's executing (program or library), then you get ETXTBSY. Why can't you? Couldn't it do the same thing and just keep it in memory? Edit: Actually on my system, I can start a program, unlink it and keep using it just fine. I wonder what case you are referring to. ETXTBSY isn't even descriped in unlink(2), but it is in unlink(3posix): ETXTBSY - The entry to be unlinked is the last directory entry to a pure procedure (shared text) file that is being executed.

jFriedensreich 4mo ago

This issue was what had me give up on windows forever and its been around since forever. There are many situations when there is just no way to release files except restart. When the basics don't work nothing else even matters.

hjkl0 4mo ago

“Reveals” is a very strange choice here. Was it previously a secret that they now decided to share? Was it previously unknown and only now discovered? Really, it’s just an overly fluffy guide for using Sysinternals utilities to help fix the issue. With a heading that is criminally click-baity.

atermentis 4mo ago

[flagged]

Eddy_Viscosity2 4mo ago

On a possibly related issue, is this the same thing that cause the 'USB drive is still in use' message when you try to eject a USB drive even when every application is closed? If so, does anyone know a fix for it?

1718627440 4mo ago
On a drive there is also the filesystem, which might not be finished with its work. When a program writes to the disk it gets buffered by the OS/filesystem driver first, so that the program can finish, before the data is actually on the disk. So there is no fix, because there is nothing to fix. If you remove the device before the OS tells you you can, you risk missing data or corruption.