Remix.run Logo
Someone1234 4 hours 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).

RajT88 44 minutes ago | parent | next [-]

"Microsoft Reveals" articles on this site are clickbaity. All this information lives in public docs, and is well known in the industry.

It is cool that Microsoft is writing these blog posts for laypeople, though. And yes, kind of crazy that some of these rough edges in the OS have not been smoothed out yet.

arcfour 4 hours ago | parent | prev | next [-]

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 3 hours ago | parent | next [-]

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 2 hours ago | parent | prev [-]

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)?

FormFollowsFunc 4 hours ago | parent | prev | next [-]

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.

meandmycode 4 hours ago | parent | prev | next [-]

I believe it was removed actually because it's not a strong indicator of the real fault, there was an old article on this but could only find this more recent summary https://devblogs.microsoft.com/oldnewthing/20250121-00/?p=11...

3 hours ago | parent | prev [-]
[deleted]