UCyborg Posted May 25, 2017 Posted May 25, 2017 You need a mouse with at least 4 buttons for this to work. Mouse buttons 4 and 5 usually function as back/forward buttons. Navigate to any folder, start renaming a file/folder, right click on the text box to open the context menu, then press mouse button 4 (back). If there is a previous folder to go to, Explorer will crash. Any application that uses its standard open/save dialog can be crashed this way as well. That's right, you can crash one of the core Windows components by simply "pressing the wrong buttons". And the bug isn't present in Vista! And somehow, nobody noticed at MS or maybe even worse, thought it wasn't worth the hassle to fix. 3
bphlpt Posted May 26, 2017 Posted May 26, 2017 The above action does NOT crash Explorer for my Windows 7 x64, so I cannot replicate this issue. Cheers and Regards
greenhillmaniac Posted May 26, 2017 Posted May 26, 2017 Can confirm it crashes my Explorer on Windows 8.1 x64... Amazing how such a small thing can trigger a crash. I saw your post on Reddit. Let's hope this gets patched.
UCyborg Posted May 26, 2017 Author Posted May 26, 2017 (edited) What's the good place to report these things without it being ignored? There are two issues when it comes to cooperation of legacy DirectDraw apps with the Desktop Window Manager, one is specific to Windows 8.1 (and I guess 8 too) There's this delay when you switch away from fullscreen app if the desktop runs at the same resolution and refresh rate as the app, it waits 3 seconds for the event that is never signaled. The Windows 8 specific issue is that if maximized windowed mode is disabled to allow real fullscreen, most ddraw calls just error out if you have the desktop extended through multiple monitors. The first issue could theoretically be patched at runtime, but this whole thing with patching Microsoft's DLLs to better support those ancient apps is getting old, as if the certain apps themselves don't have enough bugs. Anyway, back to topic, I'm pretty sure they must have gotten some of the crash reports for this particular bug in the past. I doubt I was the first one who came across it, I do remember seeing the crash with explorerframe.dll as the faulting module in the past, the only difference is, I brushed it off as random crash and wasn't paying attention about reproduction. 11 hours ago, bphlpt said: The above action does NOT crash Explorer for my Windows 7 x64, so I cannot replicate this issue. Someone over Reddit said he had that mouse button mapped to Alt + left arrow combination, in which case the keypress cancels the context menu so it doesn't crash afterwards. It's also possible that the issue surfaced up later with some update. 54 minutes ago, greenhillmaniac said: Amazing how such a small thing can trigger a crash. Indeed, and then you see how rushed Windows 10 is, which is a good recipe for the issues to clutter up. Instead of the next OS being better than the old one, it looks like they all have their own quirks. Weren't there times when we agreed the new system is better in most, if not all aspects than the old one? Edited May 26, 2017 by UCyborg 1
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now